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 
master.

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 
nothing else.

> This time, I have reduced my target: only one branch to keep alive,
> hgpovray38.
> 
> 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 
try again.

> 
> 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.
> 

OK. Understand.

> 
> 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 
inbuilt too.

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 
master.

> 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.

Bill P.

Post a reply to this message