git workflow draft

[Stephen Kelly]

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.