On May 14, 2014, at 1:10 AM, Geert Janssens <janssens-ge...@telenet.be> wrote:
> On Tuesday 13 May 2014 21:35:58 John Ralls wrote: >> On May 13, 2014, at 9:01 PM, Mike Alexander <m...@umich.edu> wrote: >>> --On May 13, 2014 9:17:58 PM +0100 Colin Law <clan...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
