Re: git pull on Linux/ACPI release tree

From: "Brown, Len" <len.brown@intel.com>
Date: Sun, 8 Jan 2006 02:47:30 -0500

What I do is simply build a new fresh tree if I feel the urge to sync with the top of Linus's tree. I use the script below which I call "git suck". It just sucks the patches out of one tree and sticks them into another tree. You go:

bash$ cd new-2.6 bash$ git suck ../foo-2.6

It preserves everything except the dates, and it's so incredibly cheap and fast with GIT.

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.

In fact, I do this so much that Linus's tree HEAD often equals my origin when he pulls.

Merges really suck and I also hate it when the tree gets cluttered up with them, and Linus is right, ACPI is the worst offender here.

Yes, we can grep the merges out of the shortlog or whatever, but that merging crap is still physically in the tree.

Just don't do it. Merge into a private branch for testing if you don't want to rebuild trees like I do, but push the clean tree to Linus.

#!/bin/sh
#
# Usage: git suck path-to-tree
#
# Pull all patches relative to 'origin' from the tree specified
# and apply them to the current directory tree, keeping all changelog
# and authorship information identical.  It will update the dates
# of the changes of course.
(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