* Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote: > Hi Ingo, > > On Wed, 2008-08-13 at 10:58 +0200, Ingo Molnar wrote: > > what's your current workflow, what causes the sha1's for commits to > > change frequently? Do you work with patches (i.e. it's not really a Git > > workflow at all and you regenerate the git tree all the time you export > > it from your patch queue), or do you perhaps git-rebase often to clean > > up patches? > > No, I don't work with patches. A lot of the churn comes from the fact > that I have been dropping and re-applying SLUB defrag patches from > Christoph lately. I keep them in a topic branch and pull them for my > 'for-next' branch that appears in linux-next. > > The basic workflow for me is as follows: > > - Whenever someone sends me a patch, I apply it to my 'testing' > branch, do a little bit testing there and if everything seems fine, > I pull the branch to my 'for-next' branch. > > - After few days, I pull (or cherry pick) the patches to 'for-linus' > branch and ask Linus to pull. Whenever he pulls, I usually rebase > all of my branches to Linus' master. > > - For development, I maintain topic branches that are _not_ > append-only (such as SLUB defrag and kmemtrace). Whenever something > changes there I do a git-reset --hard on 'for-next' and re-pull the > topic branches there. > > - Also, I usually rebase my whole tree after an -rc release or two > just to keep my tree in-sync with mainline. That usually doesn't > affect my patches at all. > > So AFAICT most of the changes to SHA1s are due to me doing development > in the topic branches and recreating the 'for-next' branch. seems pretty sane to me. We use something quite similar in -tip, with the distinction that after a very short initial period [a few days at most] we try to keep development branches append-only as well. There are 5 main advantages of doing that: - trust: the end result, despite being a slighly bit messy, is easier to trust. The commits are in true historic order, development activities and timeline is easy to review. - integration: creating the next branch is just a matter of doing an incremental git-merge. - guaranteed no-brains preservation of information: no patch is lost ever in a pure append-only flow. Doing a git-reset --hard anytime always risks the loss of patches - and even if only history is lost, that is valuable too most of the time. Whenever i do it i have to use additional safeguards against the loss of patches. - bisection quality: statistically, the newest commits tend to have the most bugs. By doing delta patches - even if the end result is a higher patch count - makes the risky portion of a stream of append-only changes drastically smaller. [this assumes that there is an adequate QA effort and that commits do not just sit there unused: that the topic branch is tested well enough and is exposed to others via linux-next, etc.] - other contributors: derived work (people basing trees off topic branches) do not get sha1's pulled from under their feet. Back/forth merging is easy. Having history of development in a tree (as long as it's not totally insane history) is beneficial in general. btw., when you send something to Linus and he pulls, generally you dont have to rebase/reset to 'clean up the house' - as long as you dont cherry-pick into the release branch. A "git-merge linus/master" will fast-forward your topic branch and will turn it into a pure upstream-based branch. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
