Stefano Lattarini skrev 2011-11-10 12:30: > On Thursday 10 November 2011, Peter Rosin wrote: >> Stefano Lattarini skrev 2011-11-10 11:02: >>> In the meantime, removing some already-merged and now inactive branches >>> (e.g., `prove' and `remove-deansification') might simplify the situation >>> a bit. Will do shortly. >> >> This is not at all my concern. >> > OK. But I think removing those branches is a good move regardless (they > have always be thought as temporary topic branches, so no need to keep > them around now that they've been happily merged).
Sure. >>>> Is it >>>> really desired to merge back maint and master into the work branches >>>> with such extreme frenzy? >>>> >>> I'd say yes, to avoid potential future bigger conflicts when merging. >>> >>> Such conflicts are bound to be more difficult to resolve, firstly >>> because they will be bigger, and secondly (and most importantly) >>> because the will involve much more changes done in a wider temporal >>> interval -- changes whose details or exact reason we might even have >>> forgotten in the meantime! >> >> Just have a look at the attached picture (if the ml doesn't eat it) and >> try to convince me that you like what you see. >> > I don't; that's why I only visulize a set of *related* branches at once, > not all of them at the same time (for example, visualizing `master' and > `maint' and `testsuite-work' at the same time is not confusing (since > `maint' is merged into `master', which is merged into `testsuite-work'). > OTOH, there is no clear relationship between `maint' and `branch-1.11' > (except for the fact that they share maint as a common "baseline"), so > trying to visulize them at once is bound to end in a mess; and notice > that this happened also *before* I started to introduce my umpteenth > topic branches. That doesn't help if you visualize some branch that contains all those merges. I had troubles following where a change was made, and was fooled by several merges before locating the correct commit. And sorry for blaming "your" work branches for the state of branch-1.11 which is where the big merge frenzy occurs. >> That nest will not go away by removing branches. >> > While I don't consider the current situation as a problem, I agree it is > suboptimal in some aspects; so, if you have suggestions about how it > could be improved, I'm all ears :-) I'm just not happy with how the commit graph looks (at least as shown by gitk). I don't really know what to do about it, and I realize that the topic branches are not the sole culprits, sorry for pointing the finger at you... Some ideas though: Don't have work type branches in the main repo. It's certainly possible to set up a repo for each topic instead of a new branch. Then you can throw away "bad" work much easier, and you are freer to rebase the work if it turns out it takes a long time to complete and/or has a lot of undesired merge-backs. Rebasing can be done for work branches in the main repo as well, but IMO it doesn't feel as bad to rebase in a separate work repo. Don't merge maint into branch-1.11/master four times a week unless there are *really* good reasons, each time. Try a throwaway merge and check for conflicts. If there are none, it is certainly possible to leave the merging for later. Or, release from master more often, then the maint-maze problem will be a non-problem :-) Cheers, Peter
