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

[Geert Janssens]

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.

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 ?

Geert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: maint checkout.png
Type: image/png
Size: 135058 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20140514/b2ecd363/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: master checkout.png
Type: image/png
Size: 128180 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20140514/b2ecd363/attachment-0003.png>