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

Re: Git range merge (cherry-pick a range)

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Jul 16, 2009, 11:36 UTC
Message-ID
<4A5F10A6.80003@drmicha.warpmail.net>
In-Reply-To
<24512201.post@talk.nabble.com>
bshOriginal venit, vidit, dixit 16.07.2009 10:11:
Show 14 quoted lines
> 
> Playing around with GIT, we encountered the following strange situation for
> which we would
> like to have an answer:
> 
> Scenario
> ========
> 
> We want to merge the range B to D from branch B1 to master
> 
> Master:       o-
>                   \
> Branch B1:      A-B-C-D-E
> 

Did you use a monospaced font when composing this e-mail? All graphs come out disconnect/distorted when reading your e-mail with a monospaced font.

I assume that above, a is the first additional commit of B1 which branches off o.

Show 100 quoted lines
> 
> Commit B:
> ---------
> FluidSolver::FluidSolver(int argc, char* argv[]) {
>     init(argc, argv);
>     // test edit 1: a + b
> }
> 
> Commit C:
> --------
> FluidSolver::FluidSolver(int argc, char* argv[]) {
>     init(argc, argv);
>     // test edit 1: a + b
>     // test edit 2: a - b
> }
> 
> Commit D:
> --------
> FluidSolver::FluidSolver(int argc, char* argv[]) {
>     init(argc, argv);
>     // test edit 1: a + b
>     // test edit 2: a - b
>     // test edit 3: a * b
> }
> 
> Commit E:
> --------
> FluidSolver::FluidSolver(int argc, char* argv[]) {
>     init(argc, argv);
>     // test edit 1: a + b
>     // test edit 2: a - b
>     // test edit 3: a * b
>     // test edit 4: a / b
> }
> 
> 
> Range merge (the GIT way):
> =========================
> 
> 1) Switch to Branch B1
> 
> 2) Create a temporary branch which does not contain anything beyond commit D
> 
>    $ git checkout -b volatileBranch D
> 
>     Master:                 o-
>                                 \
>     Branch B1:                A-B-C-D-E
>                                                 \
>     Branch volatileBranch:              (A)-(B)-(C)-(D)
> 
> 3) Rebase volatile branch to master from commit (B) to master's HEAD
>    git rebase --onto master (A) 
> 
> 
>     Branch volatileBranch:   (B)-(C)-(D)
>                                      /
>     Master:                      o-
>                                      \
>     Branch B1:                   A-B-C-D-E
>                                        
> 
> Rebasing output:
> ----------------
> 
> First, rewinding head to replay your work on top of it...
> Applying: test edit 2: a - b
> error: patch failed: fluidsolver.cpp:28
> error: fluidsolver.cpp: patch does not apply
> Using index info to reconstruct a base tree...
> Falling back to patching base and 3-way merge...
> Auto-merging fluidsolver.cpp
> CONFLICT (content): Merge conflict in fluidsolver.cpp
> Failed to merge in the changes.
> Patch failed at 0001 test edit 2: a - b
> 
> 
> When you have resolved this problem run "git rebase --continue".
> If you would prefer to skip this patch, instead run "git rebase --skip".
> To restore the original branch and stop rebasing run "git rebase --abort".
> 
> 
> Conflicts:
> ----------
> FluidSolver::FluidSolver(int argc, char* argv[]) {
>     init(argc, argv);
> <<<<<<< HEAD:fluidsolver.cpp
> =======
>     // test edit 1: a + b
>     // test edit 2: a - b
>>>>>>>> test edit 2: a - b:fluidsolver.cpp
> }
> 
> 
> After manually resolving the conflict and continuing the rebasing 
> with git rebase --continue, we are finally finished.
> 
> Since we only had updates in branch 1, it is astonishing that we get a
> conflict at all.
> Same situation works like a charme in subversion.

Ahem, how could /anything/ work like a charm in subversion? (I've been using it myself.)

Seriously, if, in subversion, you merge -rA:D onto master then subversion only computes the diff between A and D and applies it to master. You an do this in git as well, of course, but that's not a merge and does not preserve individual commit messages.

Show 14 quoted lines
> We would be happy to get an explanation for this merge bahaviour, since 
> many edits in large projects could as a matter of principle result a lot of
> merge conflicts
> which all have to be treated manually.
> 
> We believe that GIT's interface for range merges needs to get more user
> friendly.
> Since steps 1) - 3) use already developed components of GIT, there should be
> a layer above 'em
> which performs a range merge by internally calling 1) - 3).
> 
> Example: git cherry-pick $from_branch@startCommitHash
> $to_branch@endCommitHash 
> 

If I read you graphs correctly you could just as well fast-forward master to D (using reset or merge) and then "rebase -i" in order to remove A.

Alternatively, you can use "git format-patch --stdout revrange | git am".
Michael
Previous: bshOriginalNext: Daniel Barkalow
Message 9 of 12 in “cherry-pick --since ?”
  1. Brandon CaseyApr 20, 2007
  2. Alex RiesenApr 20, 2007
  3. David KågedalApr 22, 2007
  4. Junio C HamanoApr 20, 2007
  5. Brandon CaseyApr 23, 2007
  6. Junio C HamanoApr 23, 2007
  7. Brandon CaseyApr 23, 2007
  8. Git range merge (cherry-pick a range)bshOriginal, Jul 16, 2009
  9. Michael J GruberJul 16, 2009
  10. Daniel BarkalowJul 16, 2009
  11. bshOriginalJul 17, 2009
  12. Michael J GruberJul 16, 2009

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.