Aaron J. Seigo wrote: > Open questions / topics for further discovery: > > * documenting best practices for keeping a topic branch in sync with > master, keeping in mind that later a merge from the topic branch to master > needs to be done and the git history sould be kept as clean as possible
As one of the people asked to describe my idea of the workflow (which should focus on rebasing, not merging) I put write up here: http://community.kde.org/20110213_GitWorkflowAgenda/StevesIdea http://thread.gmane.org/gmane.comp.kde.scm-interest/2007 The emphasis is on creating a 'nice' stream of commits which it is possible to review (if applicable) and which apply against the target branch. This way a reviewer (or archeologist looking for the source ofg a bug) doesn't have to analyse commits in the branch which are workarounds for bugs in master, find the merge from master and the removal of the workaround, analyse the master branch in the same timeframe to see what needed to be merged in etc etc. The topic branch is an addition to the master branch. It should be relevant against the current master and 'clean' and nice. Happy and good. No useless merges. There should be no recommendation in documentation to 'merge a topic branch into master'. The recommendation should be to rebase instead. This is my recommendation. There has been some discussion on the scm interest list, but I wouldn't call it concensus at this point. Stefan Majewsky wrote: > As far as I'm concerned, the only problem with such branch moves is > the potentially epic number of commit notification mails. If so, the > email hook should check if the push generates a new branch, and send > only one mail then, like "100 commits have been pushed into the new > branch foobar; see >>here<< for a complete log vs. master and >>here<< > for the diff". The idea in the irc meeting was to not enable notifications and other such hooks on the topic branches, but only on release branches. That means there's only notification when master gets updated to include the branch. That means you get a 100 commits becoming relevant within 10 seconds instead of over the course of the 3 months or whatever that they were written. I fail to see why that would be a big deal. Reading the kde commits mailing list is actually easier because I can skip a large amount of commits that I'm not interested in at once. All the best, Steve.