Re: Patch (apply) vs. Pull

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

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.

> 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