Re: linux-next: manual merge of the kmemcheck tree

[Pekka Enberg <penberg@cs.helsinki.fi>]

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.

		Pekka