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.
