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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed Jun 22 20:20:49 2005
This archive was generated by hypermail 2.1.8 : 2005-06-22 20:20:51 EST