Re: Patch (apply) vs. Pull

[Catalin Marinas <catalin.marinas@gmail.com>]

Have a look at StGIT for this, it might help.

Junio C Hamano <junkio@cox.net> wrote:
> FYI, here is what I have been doing:
>
>  (1) Start from Linus HEAD.
>
>  (2) Repeat develop-and-commit cycle.

Gather the related commits into an StGIT patch. It's actually easier
to only update a set of existing patches, similar to the quilt way.

stg new patch1
modify...
stg commit
modify...
stg commit

stg push/pop/new

etc.

>  (3) Run "git format-patch" (not in Linus tree) to generate
>      patches.

stg export. The problem with this one is that it doesn't preserve any
of the commit information but it can be adapted (though I'm not sure
it is worth since the patch won't be that readable).

>  (4) Send them out and wait to see which one sticks.
>
>  (5) Pull from Linus.
>
>  (6) Throw away my HEAD, making Linus HEAD my HEAD, while
>      preserving changes I have made since I forked from him.  I
>      use "jit-rewind" for this.

stg pop -a. This will remove all your changes grouped in stgit
patches. The HEAD is now Linus' old HEAD. Pull/merge will advance the
HEAD to Linus' latest HEAD.

>  (7) Examine patches that Linus rejected, and apply ones that I
>      still consider good, making one commit per patch.  I use
>      "jit-patch" and "jit-commit -m" for this.

stg push -a. This step will do a diff3 between the current HEAD and
the top of the patch as the two branches, and the bottom of the patch
as an ancestor.

If the patch was merged unmodified, stgit detects this and warns you
that the patch is now empty (it detects it even if a file contains
other modifications apart from yours). If you modified it in the
meantime or the Linus modified it when merged (or some other third
party patch modifies yours), you will get a conflict you can resolve.

>  (8) Go back to step 2.

-- 
Catalin