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

Re: Patch (apply) vs. Pull

From
CMCatalin Marinas <catalin.marinas@gmail.com>
Date
Jun 22, 2005, 17:04 UTC
Message-ID
<tnx1x6u9vbk.fsf@arm.com>
In-Reply-To
<7vbr61j631.fsf@assigned-by-dhcp.cox.net>
Have a look at StGIT for this, it might help.
Junio C Hamano <junkio@cox.net> wrote:
Show 5 quoted lines
> FYI, here is what I have been doing:
>
>  (1) Start from Linus HEAD.
>
>  (2) Repeat develop-and-commit cycle.

Gather the related commits into an StGIT patch. It's actually easier to only update a set of existing patches, similar to the quilt way.

stg new patch1 modify... stg commit modify... stg commit

stg push/pop/new
etc.
>  (3) Run "git format-patch" (not in Linus tree) to generate
>      patches.

stg export. The problem with this one is that it doesn't preserve any of the commit information but it can be adapted (though I'm not sure it is worth since the patch won't be that readable).

Show 7 quoted lines
>  (4) Send them out and wait to see which one sticks.
>
>  (5) Pull from Linus.
>
>  (6) Throw away my HEAD, making Linus HEAD my HEAD, while
>      preserving changes I have made since I forked from him.  I
>      use "jit-rewind" for this.

stg pop -a. This will remove all your changes grouped in stgit patches. The HEAD is now Linus' old HEAD. Pull/merge will advance the HEAD to Linus' latest HEAD.

>  (7) Examine patches that Linus rejected, and apply ones that I
>      still consider good, making one commit per patch.  I use
>      "jit-patch" and "jit-commit -m" for this.

stg push -a. This step will do a diff3 between the current HEAD and the top of the patch as the two branches, and the bottom of the patch as an ancestor.

If the patch was merged unmodified, stgit detects this and warns you that the patch is now empty (it detects it even if a file contains other modifications apart from yours). If you modified it in the meantime or the Linus modified it when merged (or some other third party patch modifies yours), you will get a conflict you can resolve.

>  (8) Go back to step 2.
-- 
Catalin
Previous: Junio C Hamano
Message 33 of 33 in “Patch (apply) vs. Pull”
  1. Darrin ThompsonJun 20, 2005
  2. Junio C HamanoJun 20, 2005
  3. Darrin ThompsonJun 20, 2005
  4. Daniel BarkalowJun 21, 2005
  5. Junio C HamanoJun 22, 2005
  6. Catalin MarinasJun 22, 2005
  7. Linus TorvaldsJun 21, 2005
  8. Junio C HamanoJun 22, 2005
  9. Linus TorvaldsJun 22, 2005
  10. Daniel BarkalowJun 22, 2005
  11. Linus TorvaldsJun 22, 2005
  12. Daniel BarkalowJun 22, 2005
  13. Linus TorvaldsJun 22, 2005
  14. Daniel BarkalowJun 23, 2005
  15. Linus TorvaldsJun 23, 2005
  16. Daniel BarkalowJun 23, 2005
  17. Linus TorvaldsJun 23, 2005
  18. Daniel BarkalowJun 23, 2005
  19. Linus TorvaldsJun 23, 2005
  20. Daniel BarkalowJun 23, 2005
  21. Linus TorvaldsJun 23, 2005
  22. Linus TorvaldsJun 23, 2005
  23. Catalin MarinasJun 23, 2005
  24. Daniel BarkalowJun 23, 2005
  25. Catalin MarinasJun 24, 2005
  26. Martin LanghoffJun 23, 2005
  27. Darrin ThompsonJun 22, 2005
  28. Martin LanghoffJun 23, 2005
  29. 0/3 Rebasing for "individual developer" usageJunio C Hamano, Jun 23, 2005
  30. 1/3 git-commit-script: get commit message from an existing one.Junio C Hamano, Jun 23, 2005
  31. 2/3 git-cherry: find commits not merged upstream.Junio C Hamano, Jun 23, 2005
  32. 3/3 git-rebase-script: rebase local commits to new upstream head.Junio C Hamano, Jun 23, 2005
  33. Catalin MarinasJun 22, 2005

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.