On Thursday 10 November 2011, Peter Rosin wrote: > > 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. > The problem with this approach (as well as with the similar one of keeping a "separate hierarchy" of "rebasable" topic branches, say `experimental/name-of-topic') is that, for long-lived branches (think e.g., of `testsuite-work', or of the former `test-protocols'), continuous rebasing became unwieldy and unacceptably maintainance-intensive, while one-time rebasing (say, just before before merging) is too brittle, and will leave a vision of the project history that might be a huge big lie (unless you re-review and re-test each single commit).
> Don't merge maint into branch-1.11/master four times a week unless > there are *really* good reasons, each time. > I think following this suggestion is unfeasible, since ideally *each* commit in `maint' should have a good reason to be merged into `master' ASAP. That's because, ideally, commits that go into `maint' should be only bug-fixes or, at most, minor feature additions (and intended to remain in place in future automake versions as well); so you want them into `master' as well, and as soon as possible, unless you resign to have either spurious failures in the testsuite (in case the commits from `maint' have fixed testsuite bugs) or testsuite runs that are less faithful to the reality of the project status (in case the commits from `maint' have fixed real bug(s) that weren't exposed by the pre-existing testsuite coverage). > Try a throwaway merge and check for conflicts. If there are none, > it is certainly possible to leave the merging for later. > OTOH, this could be feasible and useful for branches other than master (looking at the history, I now wish I hadn't been so agressive in merging `maint' back into `java-work' and `python-work'). Probably, having a script that can automatize this check would help in making it more accepted and widespread. Any taker? ;-) > Or, release from master more often, then > the maint-maze problem will be a non-problem :-) > Hmm... Honestly I don't see how that would fix the current issues. Regards, Stefano
