git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: bug?: stgit creates (unneccessary?) conflicts when pulling

From
CLChuck Lever <cel@citi.umich.edu>
Date
Mar 1, 2006, 17:39 UTC
Message-ID
<4405DC41.8020700@citi.umich.edu>
In-Reply-To
<b0943d9e0602281445w7160d915y@mail.gmail.com>
Catalin Marinas wrote:
Show 17 quoted lines
> On 27/02/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> 
>>An idea (untested, I don't even know whether it's feasible) would be to
>>check which patches were merged by reverse-applying them starting with
>>the last. In this situation, all the merged patches should just revert
>>their changes. You only need to do a git-diff between the bottom and the
>>top of the patch and git-apply the output (maybe without even modifying
>>the tree). If this operation succeeds, the patch was integrated and you
>>don't even need to push it.
> 
> 
> I attached another patch that should work properly. It also pushes
> empty patches on the stack if they were merged upstream (a 'stg clean'
> is required to remove them). This is useful for the push --undo
> command if you are not happy with the result.
> 
> I'll try this patch for a bit more before pushing into the repository.

i think this is a cool idea. but it seems still to require a bit of convention on the part of the maintainer.

if maintainer X takes a patch "a" from developer Y, but modifies patch "a" before committing it, then your nifty automated mechanism will still have trouble merging developer Y's stack when Y pulls again.

the convention might be that maintainers who accept patches will always accept exactly what was sent, and then immediately apply another commit that addresses any issues they have with the original commit. this is also a good idea so that the history contains the exact attribution of each change.

begin:vcard fn:Chuck Lever n:Lever;Charles org:Network Appliance, Incorporated;Open Source NFS Client Development adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA email;internet:cel@citi.umich.edu title:Member of Technical Staff tel;work:+1 734 763-4415 tel;fax:+1 734 763 4434 tel;home:+1 734 668-1089 x-mozilla-html:FALSE url:http://troy.citi.umich.edu/u/cel/ version:2.1 end:vcard

Previous: Catalin MarinasNext: Catalin Marinas
Message 7 of 22 in “bug?: stgit creates (unneccessary?) conflicts when pulling”
  1. Karl HasselströmFeb 27, 2006
  2. Sam VilainFeb 27, 2006
  3. Catalin MarinasFeb 27, 2006
  4. Catalin MarinasFeb 28, 2006
  5. Catalin MarinasFeb 28, 2006
  6. Catalin MarinasFeb 28, 2006
  7. Chuck LeverMar 1, 2006
  8. Catalin MarinasMar 1, 2006
  9. Karl HasselströmMar 3, 2006
  10. Catalin MarinasMar 3, 2006
  11. Karl HasselströmMar 3, 2006
  12. Catalin MarinasMar 3, 2006
  13. Shawn PearceFeb 27, 2006
  14. Catalin MarinasMar 1, 2006
  15. Shawn PearceMar 1, 2006
  16. Catalin MarinasMar 1, 2006
  17. Shawn PearceMar 1, 2006
  18. Catalin MarinasMar 9, 2006
  19. Junio C HamanoMar 9, 2006
  20. Catalin MarinasMar 10, 2006
  21. Junio C HamanoMar 11, 2006
  22. Shawn PearceMar 10, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.