"private-kvp" merge reverted other changes since November.

Colin Law clanlaw at gmail.com
Tue May 13 16:17:58 EDT 2014


On 13 May 2014 21:09, John Ralls <jralls at ceridwen.us> wrote:
>
> On May 13, 2014, at 10:39 AM, Mike Alexander <mta at umich.edu> wrote:
>
>> On May 13, 2014, at 11:47 AM, John Ralls <jralls at ceridwen.us> wrote:
>>>
>>> Yeah, it would be silly to merge after every commit. One strategy might be to frequently merge from master and then revert the merge if there are no conflicts. ISTM that relying on rerere in the face of ongoing development on both branches risks replaying what was the right answer with last week's code but isn't with this week's, so if there are conflicts resolved in the merge it stays so that new code builds on the resolved result rather than continuing to diverge.
>>>
>>> I think merges into master should happen for every module (e.g. gncguid, gncdate) so that conflicts coming into master are limited to a single subject. That should make it a bit easier for the person doing the merge to keep track of which way to resolve the conflicts.
>>>
>>> That will still produce a ladder appearance in gitk and friends. I don't find that objectionable, but apparently some people do.
>>
>> I agree that merging master into topic branches frequently is a good idea.  I have a long running branch where I do all my real work and merge master into it often.  This seems to work well.  I've also created more short lived topic branches and used them like this.
>>
>> In the other direction, I think that once a topic branch is merged to master it should be abandoned (unless it is used to fix bugs in the stuff that was just merged).  A new topic branch should be created for subsequent changes, even if they are related to the changes that were just merged (such as the same changes to a different part of the code).  I'm not sure if this is what you're suggesting or not, but it would seem to avoid a ladder appearance (if I know what you mean by that).
>
> It’s not. I see no reason to abandon a branch just because it’s merged into master, and if you really have a long-running branch where you do all of your work, neither do you. It won’t avoid the ladder look, either. There will just be a bunch of shortish branches instead of one long one.

If you want to work in that way I suggest having a look at git rebase.
 Rather than merging the branch into master this effectively moves the
base of the branch along to the current master and makes the tree look
much simpler.

Colin



More information about the gnucash-devel mailing list