Patrice Clement wrote: > We should strive for keeping a clean and linear history.
I agree with you. > Cherry-picking is not my go-to solution as far as I'm concerned. > It requires a bit of setup and is clearly tedious: you must know > in advance the full SHA-1 of commit(s) you want to cherry-pick. git cherry-pick master..pr1234 # picks all commits on pr1234 not on master This is essentially a "manual" rebase of pr1234 onto master. Demo time. Preparations: $ git config --global alias.la 'log --oneline --graph --decorate --all' $ export PAGER=cat Assume the following repo: $ git la * ccbc288 (HEAD, master) d * d33a95b b | * 3e5b52e (pr1234) c | * 6491f93 b2 |/ * 2dfcb95 a $ git cherry-pick master..pr1234 would apply b2 and c onto master: $ git cherry-pick master..pr1234 [master 305532b] b2 1 file changed, 1 insertion(+) create mode 100644 b2 [master d18f1ac] c 1 file changed, 1 insertion(+) create mode 100644 c $ git la * d18f1ac (HEAD, master) c * 305532b b2 * ccbc288 d * d33a95b b | * 3e5b52e (pr1234) c | * 6491f93 b2 |/ * 2dfcb95 a $ If the pr1234 branch has some value once b2 and c are in master then this is a good way to do it, the main drawback IMO that it leaves a repetitive and redundant pr1234 branch behind. Another way would be to simply rebase the pr1234 branch. Disclaimer: I don't know GitHub processes and assumptions, so rebase might suck for this. If noone cares about the PR branches once they have been merged/closed (I got that impression from your mail) then rebase may be a good choice. $ git la * ccbc288 (HEAD, master) d * d33a95b b | * 3e5b52e (pr1234) c | * 6491f93 b2 |/ * 2dfcb95 a $ git rebase master pr1234 First, rewinding head to replay your work on top of it... Applying: b2 Applying: c $ git la * 92417d4 (HEAD, pr1234) c * 385ca8c b2 * ccbc288 (master) d * d33a95b b * 2dfcb95 a $ At this point, pr1234 can be fast-forward merged into master: $ git checkout master Switched to branch 'master' $ git merge --ff-only pr1234 Updating ccbc288..0565e44 Fast-forward b2 | 1 + c | 1 + 2 files changed, 2 insertions(+) create mode 100644 b2 create mode 100644 c $ git la * 0565e44 (HEAD, pr1234, master) c * 0dbfdf8 b2 * ccbc288 d * d33a95b b * 2dfcb95 a $ > You may or may not know about it but a PR can be fetched as a git > am-compatible patch. .. > https://github.com/gentoo/gentoo/pull/1234.patch Didn't know - that's pretty handy! > $ cd /home/patrice/gentoo > $ pram 1234 Nice work! I might have made a git pr alias instead, but pram seems way more flexible than that would be. Finally, while I do agree with you, the one and only reason IMO to live with merge commits is that they implicitly preserve the branching point. For source code that can be useful, but for ebuilds less so. //Peter
