Re: git pull on Linux/ACPI release tree

From: Junio C Hamano <junkio@cox.net>
Date: Jan 8, 2006, 08:44 UTC
Message-ID: <7virsv3y8k.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060108.001651.02992220.davem@davemloft.net>

"David S. Miller" <davem@davemloft.net> writes:

Show 5 quoted lines

> I know a lot of people react to this kind of usage with "what's the
> point of the source control system if you're just messing with patches
> in and out of the tree all the time" But as a subsystem maintainer,
> you deal with a lot of changes and it's important to get a pristine
> clean history when you push things to Linus.

I suppose another possibility of rebasing the topic branches every now and then amounts to almost the same thing; I think your way is safer just in case something goes wrong. Maybe Catalin can give us a short tutorial on StGIT here?

Show 7 quoted lines

> #!/bin/sh
> (cd $1; git format-patch --mbox origin) || exit 1
> for i in $1/*.txt
> do
>    sed 's/\[PATCH\] //' <$i >tmp.patch
>    git-applymbox -k tmp.patch || exit 1
> done

With "git format-patch --mbox -k origin", you would not need the sed command.

Or doing it inside a single repository:

   #!/bin/sh 
   git branch -f anchor ;# mark the current head
   git reset --hard linus ;# rewind to linus head
   # extract them, and apply them -- I suspect origin and linus
   # are the same
   git format-patch --stdout -k origin anchor | git am -k -3

To check the results, since the patch you fed to "am" as a whole should be fairly close to the difference between the linus head and your resulting HEAD, parhaps:

   git diff $(git merge-base origin anchor) anchor |
       git apply --stat --summary >status.1
   git diff linus HEAD | git apply --stat --summary >status.2
   diff -u status.1 status.2

If you do not like the result, you can "git reset --hard anchor" to come back to where you started.

* format-patch --stdout implies --mbox.

* -3 to "am" is optional and as a matter of taste.  If you want
  to resolve conflicts by hand to be sure, running "am" without
  it may be preferable.  Otherwise when a patch does not cleanly
  apply it would construct an appropriate merge base tree on the
  fly and runs a 3-way merge.