guberm / tortoisegit

Automatically exported from code.google.com/p/tortoisegit
0 stars 0 forks source link

Support cherry-picking merge revisions #1899

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

Create a merge revision and try to cherry pick it on another branch.

What is the expected output? What do you see instead?

 The cherry pick operation proceeds but the git subcall eventually fails since the --parent-number option is not supplied. I would appreciate a way to be able to cherry pick at least a single merge revisions.

What version of TortoiseGit and msysgit are you using? On
what operating system?

TortoiseGit 1.8.4 on Windows 7.

Please provide any additional information below.

I have no straightforward answer as to how to design the UI for that. But I 
think restricting this feature to single merge revisions would be helpful 
already. The reason is you often cherry-pick merges to backport the result of a 
feature/bugfix branch to another branch. Also, I do not know how the command 
line reacts if passed multiple merge and a --parent-number option.

Original issue reported on code.google.com by patr...@mezard.eu on 5 Sep 2013 at 6:58

GoogleCodeExporter commented 9 years ago

Original comment by sstrickr...@googlemail.com on 13 Nov 2013 at 9:20

GoogleCodeExporter commented 9 years ago
Hi,
We are also highly interested in this functionality.

The Log's option "Cherry Pick this Commit" seems to open a rebase dialog, with 
the Branch combo-box disabled. It tried to cherry-pick on the branch one is 
working on, which of course fails. Fixing this functionality would be immense 
help for us.

Thanks for all you great work!

Original comment by sol...@gmail.com on 14 Nov 2013 at 3:59

GoogleCodeExporter commented 9 years ago
Sorry, forgot to mention - we are using version 1.8.6.

Original comment by sol...@gmail.com on 14 Nov 2013 at 4:02

GoogleCodeExporter commented 9 years ago
FYI:

git cherry-pick <commit> -m1
git cherry-pick <commit> -m2
(git cherry-pick <commit> -m3 ?)

(ref: https://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html)

See attached files for example.

Original comment by yuelinho...@gmail.com on 15 Nov 2013 at 3:52

Attachments:

GoogleCodeExporter commented 9 years ago
In the example, found these:
The commit 1bf1d53 which created by -m1 is different from merged commit 9bd6a3f.
The commit 6117b03 whick created by -m2 is different from merged commit 
9bd6a3f, too.

I guess both them are not wanted.
So...
Apply -m1 first.
Apply -m2 second. (06-CherryPickTwice.png)
Combine them. (07-combine.png, 08-finally.png)
(If original merged-commit is created through resolving conflict operation, the 
combine operation may be do resolve again. Oh~)

Other ways: (may save resolve conflict operation and keep Author/Date data)
1. git cherry-pick master -m1 (TGit not support it yet)
2. Right click on "master" in Log dialog and do "Compare with working tree".
3. Select all and do "Revert to revision 9bd6a3f" in Changed Files dialog.
4. do Commit with Amend.

More, wish TGit do "one click" to do this. ^_^

Or, support -m in Cherry Pick dialog. :) (09-CherryPick.png and 
10-CherryPick.png)

Original comment by yuelinho...@gmail.com on 15 Nov 2013 at 7:30

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by ch3co...@gmail.com on 15 Nov 2013 at 1:24