From: Michael J Gruber <git@drmicha•warpmail.net>
To: bshOriginal <mindplayintricks@gmx•de>
Cc: git@vger•kernel.org
Subject: Re: Git range merge (cherry-pick a range)
Date: Thu, 16 Jul 2009 13:36:06 +0200 [thread overview]
Message-ID: <4A5F10A6.80003@drmicha.warpmail.net> (raw)
In-Reply-To: <24512201.post@talk.nabble.com>
bshOriginal venit, vidit, dixit 16.07.2009 10:11:
>
> 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.
>
> 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.
> 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
next prev parent reply other threads:[~2009-07-16 11:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-20 16:20 cherry-pick --since ? Brandon Casey
2007-04-20 18:55 ` Alex Riesen
2007-04-22 12:06 ` David Kågedal
2007-04-20 23:05 ` Junio C Hamano
2007-04-23 17:52 ` Brandon Casey
2007-04-23 19:32 ` Junio C Hamano
2007-04-23 23:18 ` Brandon Casey
2009-07-16 8:11 ` Git range merge (cherry-pick a range) bshOriginal
2009-07-16 11:36 ` Michael J Gruber [this message]
[not found] ` <6efe9a9b0907160516o75641919wd1eecf5229aea895@mail.gmail.com>
2009-07-16 12:44 ` Michael J Gruber
2009-07-16 16:27 ` Daniel Barkalow
2009-07-17 8:41 ` bshOriginal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A5F10A6.80003@drmicha.warpmail.net \
--to=git@drmicha$(echo .)warpmail.net \
--cc=git@vger$(echo .)kernel.org \
--cc=mindplayintricks@gmx$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox