|
 |
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:
>>
....
>
>
> Nothing funky, and its all in my branch feature/extended-mesh, forked
> fresh from official master branch
>
> See if you want to pull it anywhere:
>
> https://github.com/LeForgeron/povray/tree/feature/extended-mesh
>
> The first commit is the patch,
>
> The second commit is the merge into hgpovray38 (and you do not need it)
I've not got your experience with code control, so perhaps asking a
stupid question.
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 have my own 'povr' equivalent to 'hgpovray38' but I've been keeping
all my branches un-merged so as to both be able to periodically re-base
them to 'povray' master updates, but also so on merge I get only a
branch's specific changes.
This allows me - and anyone else - to pull github published fixes and
features into personal versions of povray. Usually with little or no
effort beyond doing the pull from github ahead of a build. If later, I
decide to exclude some feature, it's just a matter of not pulling it for
the next 'povr' build.
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.
Probably, there is some way to pull the commit previous to the merge
specifically - if I know to do it. However, what happens six months or
two years from now when that branch's code has not been kept current to
povray's master, but rather kept current with some other version of
povray? I believe it becomes more and more difficult for others to make
routine use of such fix and feature branches.
I'm asking for mostly selfish reasons. There are often patches by you,
by Christoph with uberpov or others I want in my own routinely built
working version. I don't want to switch to uberpov or hgpovray to use
particular fixes and features. I want what I want all in my povr! This
is only easy if branches are kept apart from any larger build over time
and reasonably current to the povray master branch(1).
Bill P.
(1) - I understand that sometimes changes is such that keeping a branch
apart gets difficult or impossible. But where it can be done, thinking
it helpful.
Post a reply to this message
|
|
|
|
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:
>>>
> ....
>>
>>
>> Nothing funky, and its all in my branch feature/extended-mesh, forked
>> fresh from official master branch
>>
>> See if you want to pull it anywhere:
>>
>> https://github.com/LeForgeron/povray/tree/feature/extended-mesh
>>
>> The first commit is the patch,
>>
>> The second commit is the merge into hgpovray38 (and you do not need it)
>
> I've not got your experience with code control, so perhaps asking a
> stupid question.
>
Rule#1 : I suck at using git & github.
> 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.
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.
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 have my own 'povr' equivalent to 'hgpovray38' but I've been keeping
> all my branches un-merged so as to both be able to periodically re-base
> them to 'povray' master updates, but also so on merge I get only a
> branch's specific changes.
>
> This allows me - and anyone else - to pull github published fixes and
> features into personal versions of povray. Usually with little or no
> effort beyond doing the pull from github ahead of a build. If later, I
> decide to exclude some feature, it's just a matter of not pulling it for
> the next 'povr' build.
>
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.
I have been proven wrong on the latter, and I have no interest for the
former.
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.
> 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.
>
> Probably, there is some way to pull the commit previous to the merge
> specifically - if I know to do it. However, what happens six months or
> two years from now when that branch's code has not been kept current to
> povray's master, but rather kept current with some other version of
> povray? I believe it becomes more and more difficult for others to make
> routine use of such fix and feature branches.
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.
>
> I'm asking for mostly selfish reasons. There are often patches by you,
> by Christoph with uberpov or others I want in my own routinely built
> working version. I don't want to switch to uberpov or hgpovray to use
> particular fixes and features. I want what I want all in my povr! This
> is only easy if branches are kept apart from any larger build over time
> and reasonably current to the povray master branch(1).
Good luck. I just want to keep hgpovray38 a bit ahead of master, tuned
to my desires and idea.
>
> Bill P.
>
> (1) - I understand that sometimes changes is such that keeping a branch
> apart gets difficult or impossible. But where it can be done, thinking
> it helpful.
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 ?).
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.
Post a reply to this message
|
|
