git workflow draft

[Stephen Kelly]

Johannes Sixt wrote:

> Am 2/16/2011 22:10, schrieb Stephen Kelly:
>> 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.
> 
> Now I get it: The reason why you are advocating a rebase based workflow is
> because the goal should be a series of self-contained, easy-to-review,
> tested(!) commits.

Correct.

> 
> That is, when someone (an individual or a group of collaborators) produces
> a new feature, the result should be a (not too long) series of "clean"
> commits. 

Correct.

> To achieve this, it is necessary to use git-rebase in order to
> fold, split, and rearrange the commits. This sort of rebasing should
> happen after a group of collaborators has produced a potentially messy
> history with merges and fixups of earlier commits, and before the feature
> nears publication to a wider audience. (You mentioned an example elsewhere
> in this thread.)

Correct.

> 
> So far, we are in the same boat, absolutely.
> 
> HOWEVER:
> 
> When you develop a new feature, it is a very important choice on which
> version of the software you base it on. I am advocating to base a feature
> on a well-known, stable state. If you choose to base the feature on
> "today's master", you are actually building a house on moving grounds. How
> can you be sure that your product will be stable?
> 
> The corollary is that a new topic should be based on a project state that
> is no younger than necessary (to have all prerequisites that you need), so
> that you can be sure that it was already tested by a as many people as
> possible. Ideally, today, every feature targeted for 4.7 should be based
> on the 4.6.0 release tag, whenever possible.
> 

That sounds like a workflow that is far too different from existing 
workflows that KDE people use currently. It just won't be picked up. People 
run master and develop against master. That's not going to change.

Additionally, you've made all history highly parallel instead of linear. 
That makes trying to look into the history completely useless. Imagine 
Alice, Bob, Charlie and Dave all wrote a feature which was interrelated to 
the others enough that three of them had merge conflicts to solve. Now 
imagine I have to go back in history to figure out what's going on. The 
actual commits people made are valueless because they might have had to be 
rewritten in a merge. So instead I have to look at the merges *and* all the 
branches to try to figure out which branch won every conflict and what was 
going on in the branch. 

After a rebase no one else has to analyse a merge conflict and look at 
certain commits while mentally ignoring them because they know the commit is 
made irrelevant by a merge.

> Choose a starting point
> that is convenient; but DO NOT CHANGE IT once you have done serious
> development, because a change (aka rebase) basically invalidates all your
> tests.

This is silly. When you merge in your workflow you have to re-run all tests 
anyway.

I think this thread has run its course. Hopefully some people have learned 
something about whether they should merge or rebase their topics.