Is there functionality to allow something akin to
a
git cherry-pick --since <commit>
or maybe syntax similar to git cherry where the upstream, head,
and limit can be specified. Or the .. syntax would work.
Here's my use case:
Two branches, 'A' and 'B'.
'A' is the master branch.
'B' was forked some time ago and is in bug fix only mode.
Much of 'A' and 'B' are still the same, but there have been
some intrusive changes made to 'A' that should not go into 'B'.
This is also why I can't just pull from 'B'. rebase may work,
but then of course all of the commit id's change.
When changes are made in 'B' I currently cherry-pick each commit
into 'A' (where possible). This can be tedious when there are many
commits. I can use git cherry to show me which commits should be
cherry-picked, it would be nice if I could cherry-pick a range of
commits.
I am not subscribed to the list so please cc me. I hope this is ok,
if not let me know and I will subscribe. I am only a casual read of
the list.
-brandon
From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:06
Brandon Casey [off-list ref] writes:
Is there functionality to allow something akin to
a
git cherry-pick --since <commit>
or maybe syntax similar to git cherry where the upstream, head,
and limit can be specified. Or the .. syntax would work.
Here's my use case:
Two branches, 'A' and 'B'.
'A' is the master branch.
'B' was forked some time ago and is in bug fix only mode.
Much of 'A' and 'B' are still the same, but there have been
some intrusive changes made to 'A' that should not go into 'B'.
You forgot to say "My objective is to make sure all the good
fixes in B are forward ported to A" but I am assuming that is
the case.
This is also why I can't just pull from 'B'. rebase may work,
but then of course all of the commit id's change.
I do not understand why you cannot merge 'B' into 'A'. From the
commit ancestry perspective, merging is exactly the right thing
to do if your goal is to forward port all fixes in B to A.
Is there functionality to allow something akin to
a
git cherry-pick --since <commit>
or maybe syntax similar to git cherry where the upstream, head,
and limit can be specified. Or the .. syntax would work.
Here's my use case:
Two branches, 'A' and 'B'.
'A' is the master branch.
'B' was forked some time ago and is in bug fix only mode.
Much of 'A' and 'B' are still the same, but there have been
some intrusive changes made to 'A' that should not go into 'B'.
You forgot to say "My objective is to make sure all the good
fixes in B are forward ported to A" but I am assuming that is
the case.
Yes, that is the case, but the flow is both ways. Other developers
may implement fixes in 'A', which must be backported to 'B'. They
don't care about 'B'.
quoted
This is also why I can't just pull from 'B'. rebase may work,
but then of course all of the commit id's change.
I do not understand why you cannot merge 'B' into 'A'. From the
commit ancestry perspective, merging is exactly the right thing
to do if your goal is to forward port all fixes in B to A.
I thought I recalled having problems with a different tree and a
similar situation, where a merge did not do what I expected. I'll
have to take a look at that one again and post a scenario if I
find one.
I just tried a pull from 'B' into 'A' with this tree, and it worked.
The need to cherry-pick from 'A' into 'B' still exists though. The
work around using format-patch that Alex suggested does work. Being
able to cherry-pick a range in a more direct way seems like it would
be useful though.
-brandon
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
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
quoted
quoted
quoted
quoted
quoted
quoted
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.
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
Greetings,
Babak Sayyid Hosseini
--
View this message in context: http://www.nabble.com/cherry-pick---since---tp10105685p24512201.html
Sent from the git mailing list archive at Nabble.com.
From: Michael J Gruber <hidden> Date: 2016-06-15 22:47:03
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
quoted
quoted
quoted
quoted
quoted
quoted
quoted
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
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:47:04
On Thu, 16 Jul 2009, bshOriginal wrote:
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
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
What's happening here is that the first commit you're keeping adds an edit
to a version of the file which has the first edit as well, and that first
edit is right next to the second edit, and so it's reasonably likely that
the second edit has to be done differently in order to not require the
first edit.
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
quoted
quoted
quoted
quoted
quoted
quoted
quoted
test edit 2: a - b:fluidsolver.cpp
}
This is the merge conflict output for the case where you're applying a
change which is based on a version with some of the final code already
there to a base that doesn't have that code. It's not a necessary
conflict, but it is a likely conflict (that is, there's a unique logical
guess as to the right resolution, but there's also a good change that the
resulting code doesn't work). Of course, if the edits actually overlap, it
becomes a necessary conflict.
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.
Except when it generates broken code like a charm...
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
The main issue is the:
git ??? --continue
that you use after you resolve any conflicts. The existing components need
to be reorganized in order to support doing the correct later steps when a
multi-step operation supplied by a higher layer was previously suspended
for user assistance in the middle.
-Daniel
*This .sig left intentionally blank*
On Thu, Jul 16, 2009 at 2:44 PM, Michael J Gruber [off-list ref]
wrote:
Babak S. H. venit, vidit, dixit 16.07.2009 14:16:
>>> Hello Micheal,
>>> thank you for the response... I will try to answer inline as I
read...
>>>> 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.
>>> What a pity. I pasted the text out of the editor (vi | Font: lucida
>>> console 8) in the web form.
>>> Anyway I attach my original posting in a file to this email. I hope
you
>>> can open that undistorted.
>>Yep, it's fine.
>>>> I assume that above, a is the first additional commit of B1
which
>>>> branches off o.
>>> Correct.
>>>>> 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.)
>>> Please let's try not to start a belief war. Every version control
>>> systems has its quirks and we just
>>> try to figure out what the problem in the above described scenario
is.
>>Agreed. (Which is why I started the next paragraph with "Seriously,".)
>>>> 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.
>>>>
>>> Subversion does preserve individual commit messages.
>>> Try to pass the --use-merge-history parameter to svn log.
>> I have to admit that I've ever used svn 1.4x. I do belief though that
>> even 1.5 makes a single commit in that situation and reconstructs the
>> merge history from the metadata.
Maybe. But it works and you can additionally inspect diffs between
revisions.
>>>>> 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".
> Yes applying a patch is an alternative.
> But don't you think git needs to provide a more user friendly
interface
> for range merges?
>> Sometimes it's only a matter of workflow. Have you tried the
suggestion
>> above?
Yes, many ways lead to Rome..
Personally, I think most companies and open source coders are currently
bound to subversion
and are keen to start off with a more sophisticated version control system
as e.g. git, mercurial or darcs. As they are already pretty familiar with
subversion,
I think it is clever to follow established and accepted workflows in case
those workflows are really
equivalent. This enhances the acceptability and is a pro for git in a direct
comparison to the
mentioned alternative distributed version control systems.
I tried out the patch alternative and apart from the fact that
one of the patches could not be directly applied and as a result we again
faced the
same merge conflict, everything worked out the way it ought to.
>> In general, in git it's preferable to have merges of feature branches
>> rather than cherry picks. So you would rebase the feature branch
first
>> (rebase -i to remove A) and then merge the result to master. Have you
>> tried whether you get conflicts that way? It's really one rebase -i
and
>> one merge.
No I must admit that I did not try that one out, but I believe it is pretty
much the same
thing I did. I branched from revision D dropping out revision E.
Then I rebased in a way that everything above revision A was merge relevant
cropping A.
==> A CROP B - C - D CROP E
> If you want to use a patch approach then "git format-patch|git am" and
> "git cherry" are your options. Currently, git cherry-pick accepts only
a
> single commit, but if you want to pick the range B through D that
would
> be B^..D in git lingo, so
> git rev-list --reverse --topo-order B^..D | while read rev
> do
> git cherry-pick $rev || break
> done
The above lines look correct to me.
But again, if git really wants to be the next king version control system,
it has
to be more user friendly. You and me are comfortable with the command line.
There are a lot of GUI users though, that are overstrained with all that.
I hope git implements a few more top level functions to simplify specific
operations
as it seems to be a really nice VCS.
Have a nicce day.
Babak Sayyid Hosseini
> should do the job (untested!).
> Cheers,
> Michael
--
Regards.
Babak Sayyid Hosseini
--
View this message in context: http://www.nabble.com/cherry-pick---since---tp10105685p24530703.html
Sent from the git mailing list archive at Nabble.com.