| 1 |
Patrice Clement wrote: |
| 2 |
> We should strive for keeping a clean and linear history. |
| 3 |
|
| 4 |
I agree with you. |
| 5 |
|
| 6 |
|
| 7 |
> Cherry-picking is not my go-to solution as far as I'm concerned. |
| 8 |
> It requires a bit of setup and is clearly tedious: you must know |
| 9 |
> in advance the full SHA-1 of commit(s) you want to cherry-pick. |
| 10 |
|
| 11 |
git cherry-pick master..pr1234 # picks all commits on pr1234 not on master |
| 12 |
|
| 13 |
This is essentially a "manual" rebase of pr1234 onto master. |
| 14 |
|
| 15 |
Demo time. Preparations: |
| 16 |
|
| 17 |
$ git config --global alias.la 'log --oneline --graph --decorate --all' |
| 18 |
$ export PAGER=cat |
| 19 |
|
| 20 |
|
| 21 |
Assume the following repo: |
| 22 |
$ git la |
| 23 |
* ccbc288 (HEAD, master) d |
| 24 |
* d33a95b b |
| 25 |
| * 3e5b52e (pr1234) c |
| 26 |
| * 6491f93 b2 |
| 27 |
|/ |
| 28 |
* 2dfcb95 a |
| 29 |
$ |
| 30 |
|
| 31 |
git cherry-pick master..pr1234 would apply b2 and c onto master: |
| 32 |
|
| 33 |
$ git cherry-pick master..pr1234 |
| 34 |
[master 305532b] b2 |
| 35 |
1 file changed, 1 insertion(+) |
| 36 |
create mode 100644 b2 |
| 37 |
[master d18f1ac] c |
| 38 |
1 file changed, 1 insertion(+) |
| 39 |
create mode 100644 c |
| 40 |
$ git la |
| 41 |
* d18f1ac (HEAD, master) c |
| 42 |
* 305532b b2 |
| 43 |
* ccbc288 d |
| 44 |
* d33a95b b |
| 45 |
| * 3e5b52e (pr1234) c |
| 46 |
| * 6491f93 b2 |
| 47 |
|/ |
| 48 |
* 2dfcb95 a |
| 49 |
$ |
| 50 |
|
| 51 |
If the pr1234 branch has some value once b2 and c are in master then |
| 52 |
this is a good way to do it, the main drawback IMO that it leaves a |
| 53 |
repetitive and redundant pr1234 branch behind. |
| 54 |
|
| 55 |
|
| 56 |
Another way would be to simply rebase the pr1234 branch. Disclaimer: I |
| 57 |
don't know GitHub processes and assumptions, so rebase might suck for this. |
| 58 |
|
| 59 |
If noone cares about the PR branches once they have been merged/closed |
| 60 |
(I got that impression from your mail) then rebase may be a good choice. |
| 61 |
|
| 62 |
$ git la |
| 63 |
* ccbc288 (HEAD, master) d |
| 64 |
* d33a95b b |
| 65 |
| * 3e5b52e (pr1234) c |
| 66 |
| * 6491f93 b2 |
| 67 |
|/ |
| 68 |
* 2dfcb95 a |
| 69 |
$ git rebase master pr1234 |
| 70 |
First, rewinding head to replay your work on top of it... |
| 71 |
Applying: b2 |
| 72 |
Applying: c |
| 73 |
$ git la |
| 74 |
* 92417d4 (HEAD, pr1234) c |
| 75 |
* 385ca8c b2 |
| 76 |
* ccbc288 (master) d |
| 77 |
* d33a95b b |
| 78 |
* 2dfcb95 a |
| 79 |
$ |
| 80 |
|
| 81 |
At this point, pr1234 can be fast-forward merged into master: |
| 82 |
|
| 83 |
$ git checkout master |
| 84 |
Switched to branch 'master' |
| 85 |
$ git merge --ff-only pr1234 |
| 86 |
Updating ccbc288..0565e44 |
| 87 |
Fast-forward |
| 88 |
b2 | 1 + |
| 89 |
c | 1 + |
| 90 |
2 files changed, 2 insertions(+) |
| 91 |
create mode 100644 b2 |
| 92 |
create mode 100644 c |
| 93 |
$ git la |
| 94 |
* 0565e44 (HEAD, pr1234, master) c |
| 95 |
* 0dbfdf8 b2 |
| 96 |
* ccbc288 d |
| 97 |
* d33a95b b |
| 98 |
* 2dfcb95 a |
| 99 |
$ |
| 100 |
|
| 101 |
|
| 102 |
> You may or may not know about it but a PR can be fetched as a git |
| 103 |
> am-compatible patch. |
| 104 |
.. |
| 105 |
> https://github.com/gentoo/gentoo/pull/1234.patch |
| 106 |
|
| 107 |
Didn't know - that's pretty handy! |
| 108 |
|
| 109 |
|
| 110 |
> $ cd /home/patrice/gentoo |
| 111 |
> $ pram 1234 |
| 112 |
|
| 113 |
Nice work! I might have made a git pr alias instead, but pram seems |
| 114 |
way more flexible than that would be. |
| 115 |
|
| 116 |
|
| 117 |
Finally, while I do agree with you, the one and only reason IMO to |
| 118 |
live with merge commits is that they implicitly preserve the branching |
| 119 |
point. For source code that can be useful, but for ebuilds less so. |
| 120 |
|
| 121 |
|
| 122 |
//Peter |
Archives