Re: Patch (apply) vs. Pull

Daniel Barkalow [off-list ref] wrote:

On Mon, 20 Jun 2005, Darrin Thompson wrote:

quoted

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