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

[Geert Janssens]

On Wednesday 14 May 2014 07:39:17 John Ralls wrote:
> 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.
> 
Interesting. Did you close and re-open SourceTree after you switched to 
master ?

On gitk that seems to make a difference. If master is the active branch 
when I open gitk I get the switching-yard. However if maint is the 
active branch I get a much cleaner ladder like SourceTree shows. And 
that clean ladder remains if I then swith the master within gitk.

Meanwhile I have also tried qgit but it behaves exactly the same. Both 
tools appear to get their input from git log and are probably pretty 
dumb in how to parse that.

Perhaps I should report this as a bug or enahncement request in gitk...

Geert

> Regards,
> John Ralls