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

[John Ralls]

On May 14, 2014, at 1:10 AM, Geert Janssens <janssens-geert at telenet.be> wrote:

> On Tuesday 13 May 2014 21:35:58 John Ralls wrote:
>> On May 13, 2014, at 9:01 PM, Mike Alexander <mta at umich.edu> wrote:
>>> --On May 13, 2014 9:17:58 PM +0100 Colin Law <clanlaw at gmail.com> 
> wrote:
>>>>> 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.
>>> 
>>> That's what I do.  I rebase my branches onto master each time it is
>>> updated.  This seems to work well and keeps the tree much simpler.
>> That's the SVN way. We discussed this back in March [1] and decided
>> that we're not going to do that anymore. If you want to revisit that
>> you need a better argument than "that's the way I've always done it",
>> considering that the Git community at large doesn't seem to consider
>> it a "best practice".
>> 
> It seems to me the git community is not against rebasing private 
> branches before pushing them to a public repository (provided their 
> branch point was never pushed earlier). Whether we should mandate this 
> for gnucash is debatable.

Is that what Mike meant? I thought he meant that he rebases his work branch on master every time he pulls master, so that any merges back to master are always fast-forwards.

It’s an interesting idea nevertheless. It might help with the switching-yard look you get in gitk.

> 
> I have seen suggestions to prefer short-lived topic branches. So I'm 
> going to think out loud here. If a topic asks for a long term topic 
> branch, perhaps the topic is not well chosen or could be split in 
> smaller sub topics which each go on their own branch.
> 
> This is in the direction of what Mike proposed in his first reply on 
> this thread. Once merged to master, rebase the topic branch on master 
> (which after the merge should be a noop code wise) and continue from 
> there. That would reset the ladder generation at that point while you 
> continue to work on the branch. Still thinking out loud...
> 
> With regards to the "ladder" structure that follows from frequent merges 
> it looks different in gitk depending on which branch is checked out. If 
> maint is checked out the ladder consists of two parallel lines with some 
> interconnects.
> 
> However if master is checked out the structure looks more like a railway 
> merger which is much harder to read. I have added examples of both 
> views.
> 
> I have no experience with other git tree visualizers so perhaps this is 
> just a flaw in the way gitk works. Anyone else have experience with 
> other tools ? Do they give better or worse results ?

I think many of them re-use the code in gitk, and so have the same problem. Atlassian’s SourceTree, which I’ve mentioned before, doesn’t seem to suffer from that problem so much:



Here’s the view with master checked out, a bit further down the so you can see the merge of private-kvp and the beginnings of my c++-build branch:



Unfortunately SourceTree isn’t available for Linux, only for MSWin and OSX.

Regards,
John Ralls