Re: git pull on Linux/ACPI release tree

From: Catalin Marinas <catalin.marinas@arm.com>
Date: Jan 8, 2006, 08:16 UTC
Message-ID: <tnx64os3xri.fsf@arm.com>
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B3005A13489@hdsmsx401.amr.corp.intel.com>

"Brown, Len" wrote:

Show 8 quoted lines

>>I _really_ wish you wouldn't have those automatic merges.
>>
>>Why do you do them? They add nothing but ugly and unnecessary 
>>history, and in this pull, I think almost exactly half of the
>>commits were just these empty merges.
>
> Is it possible for it git, like bk, to simply ignore merge commits
> in its summary output?

As Junio suggested, you can have a look at StGIT (http://www.procode.org/stgit/) for a different workflow. There is a tutorial both on the web and in the doc/ directory but, anyway, it is pretty similar to Quilt only that the patches are GIT commits.

In principle, you keep all the patches in a stack whose base is the HEAD of Linus' kernel. You can indefinitely modify/push/pop the patches and, once you are happy with the state of the stack, ask Linus to pull using standard GIT commands (or mail them with 'stg mail'). You can afterwards pull the latest changes from Linus using 'stg pull'. This operation pops the patches you have, advances the base of the stack (so no "merge" message) and pushes your patches back. Since pushing is done with a three-way merge, it detects whether there are any upstream modifications to your patches (if not, all the patches should become empty and safely removed from the stack).

You can also have a branch for upstream merges only and you can easily cherry-pick patches or commits from other branches. This is quite useful if you want to continue the work on your development branch until Linus merges your patches.

-- 
Catalin