On 07/31/2018 01:34 PM, Le_Forgeron wrote:
> Le 31/07/2018 à 15:20, William F Pokorny a écrit :
>> On 07/31/2018 04:39 AM, Le Forgeron wrote:
>>> Le 31/07/2018 à 04:32, dick balaska a écrit :
>>>> On 07/30/2018 07:46 PM, Bald Eagle wrote:
> Rule#1 : I suck at using git & github.
:-) I feel I do too, though I've gotten a little better over time. I
use Mercurial for my non-POV-Ray stuff, but there I'm not working
alongside others so it's easier overall.
>> Is there a reason you are not keeping your patches as independent
>> branches periodically re-based to master instead of merging them back
>> into hgpovray as posted on github?
> I do not intend to waste time to rebase.
It does take time when there is change in the master which collides with
my branch changes otherwise not much. Suppose because I want to stay up
with master periodically doing the re-basing is easier than waiting a
long while and then trying to handling all colliding changes at once.
> In previous 3.7, I tried to make a corrected master and a proper
> hgpovray based on that master... additions were forked from hgpovray
> before merging back into it. It failed when master started to get
> refactored so heavily that it would need a complete rewrite of
> everything in hgpovray.
Understand. I'm with Christoph in his view gradual re-factoring is the
practical path to POV-Ray 4.0. Nothing to do in these situations except
do the work to recode to the refactoring. I've been bouncing back into
older versions often this year with the solver work. I like the
refactoring that got done - the code structure is cleaner.
A while back now Christoph encouraged me to create a pull request
against uberpov for one of my set of changes. Unfortunately, my changes
collided with re-factoring specific to uberpov. It was a lot of work to
get compiling and at the end of it I only ran a few sanity tests - not
the days and days of testing I'd done for my 'real' branch off POV-Ray
The experience left me asking, how much value is something ported over
to uberpov in such a way... I don't run that tool day to day and just no
time to do duplicate the testing. I've certainly got no interest in
testing everything twice. Happens the branch and pull request never got
merged and I'm glad. Suppose people had tried it there but I'd screwed
up the port in a way my few sanity test didn't catch. Reality is most
folks on seeing a quick junk result will not give feedback - they'll
just think the code is junk! My C++ code sometimes is I suppose... :-)
The whole episode left me aiming to keep up with POV-Ray master and
> This time, I have reduced my target: only one branch to keep alive,
> I forked it from official master, and intend to pull from it again when
> it moves (in a running state ! previously some commits in 3.7 get to a
> non-working state, at least with some compilers).
> Evolutions to integrate into hgpovray38 are forked from official master,
> to ease, should it please power that be, an incorporation into official
> code. (but I do not expect all of them to please, e.g. I have removed
> the tiny rotation of text from hgpovray38, but it would be a long fight
> I won't engage to ever get a removal of one line.)
> Once done, I commit evolution on its own branch, push it on github and
> yesterday havoc happened: I asked github a pull request to hgpovray and
> it found a conflict, resolving the problem on website, it added a second
> commit on the branch, then finished the pull on hgpovray38.
I just push to and pull from github. I do all my merging, re-basing and
so on locally. If I know merges might be messy or I'm not quite sure
what I'm doing I make sure I have a copy of my starting repository
directory somewhere - might be the one on github works. If things go
wrong, I delete the messed up directory in total, copy from the copy and
> This assumes either preventive works, with no novelty, to check and
> rebase every branches, without even warranting that the multiple
> branches are compatible (or rather auto-mergeable), or that the
> framework did not evolve so much as needing a total rewrite.
Agree. Sometimes I find myself with work to do to get back with the
master branch. I try not to have multiple personal branches that
overlap, but rather combine such overlaps in one stand alone branch
relative to master - so as not to create my own collisions.
> Moreover, you have a "would-be-great-software-if-you-can-fusion"
> solution, where I want a solution that I can use right now. The
> difference between a modular vehicle you can change a lot of options,
> but that you store as parts in your garage, and a ready to go vehicle in
> my garage. Of course your garage is nice, but I'm too old for nice
> modular everywhere, I just want a working vehicle without troubles
> discovered during last minute assembly.
Agree & understand.
>> If I do the usual:
>> git pull https://github.com/LeForgeron/povray.git feature/extended-mesh
>> and that branch has been merged into hgpovray, I believe I'll get all of
>> the hgpovray updates at the point of the merge.
> I have created a new branch feature/extended-mesh-proper to expose the
> single commit of interest.
I see it. An option for me would be to grab branches now and do the
re-basing myself over time - but then I've taken on that work and I'm
out of luck if you fix or improve something in the code at a later time.
> If povray's master get updated, I will adapt in, and only in,
> hgpovray38. Maybe an intermediate branch will appeared for the fix, but
> it will only focus on the new commits from master and their impacts on
> the result found in hgpovray38.
> I do not aim at maintaining the intermediates branches.
> Good luck. I just want to keep hgpovray38 a bit ahead of master, tuned
> to my desires and idea.
My aim for my own povr too.
> But I never got any feedback on my changes (fix or extensions) during
> hgpovray (3.7), so I rather find maintaining them useless (call that
> motivation ?).
I'd say I've given a little on the ovus and lemon, but generally agree.
Part of the problem is folks like me don't have much interest in jumping
to an otherwise back dated version of POV-Ray to use a feature or to
give feedback when any updates will be in a branch I'm not using daily.
If you keep hgpovray38 up with master this changes to the better - but I
still dislike jumping to a version which doesn't have my personal toys
I ported your lemon object from hgpovray (3.7) partly to learn about the
shape code, but as much because I wanted to make use of it in my
personal povr version. Creating the pull request to get it into POV-Ray
proper came later and mostly because I thought "why not" I now have the
lemon code branch in hand which will merge cleanly into the current
> Before git, patches of povray were often available as diff from official
> release, git makes it easier, but I doubt older patches would have been
> ported to new versions if new versions came out as fast as commits naw.
> I guess everyone dreams of superpatch and megapatch, but that's a story
> from another time. Megapatch was a great work, but it seems a hell to
> integrate the various proposals.
Agree. Suppose no magic in the end and it's just hard no matter the
path. I appreciate the detailed response. Thanks.
Post a reply to this message