Re: Patch (apply) vs. Pull

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Jun 22, 2005, 09:56 UTC
Message-ID: <tnxvf46btpt.fsf@arm.com>
In-Reply-To: <Pine.LNX.4.21.0506211337400.30848-100000@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> wrote:

> On Mon, 20 Jun 2005, Darrin Thompson wrote:
>> Would it make sense to come up with a way to make an emailed series of
>> patches represent a series of commits? Could patches still be
>> cherrypicked?

While you could cherry-pick a changeset generated by a commit (i.e. the diff between the commit's tree and its parent), I found this not to always be convenient. For example, a fix might need more than one commit but there is no way to know how they relate and which changesets to cherry-pick, unless somebody tells you exactly.

Show 5 quoted lines

> Commits are fundamentally resistant to cherrypicking, because they give
> the state of the tree rather than expressing changes in that
> state. Long-term, I think that something like StGIT should be integrated
> into the system and deal with generating the HEAD you get after getting
> patches in.

With StGIT, you can gather many related commits into a patch. This patch (i.e. a series of related commits) could be pulled into your tree and pushed onto your stack of patches. StGIT should also allow one to upgrade the pulled patch and re-applied onto the stack.

Thanks to Daniel's suggestion for multiple heads support, StGIT will (in a future release) support pulling changes from a remote tree together with the patch series information. After this is done, applying patches from different branch (head) would be quite simple.

One problem is patch dependency tracking (i.e. you cannot push a patch onto the stack if it expects a certain patch to be already applied). Darcs does this by checking whether two patches can be commuted. I have to think a bit more about how StGIT could handle this.

-- 
Catalin