0

In a team where 2 developers were working on different things, but both were using develop as the integration branch (working with gitflow) it turned out to be one developer's job is incomplete (but this job was not programmed for the current release) and the other is complete (this one is programmed for the current release).

Now, I'm trying to cherry pick every commit of the developer whose changes were programmed for the current release, but they are A LOT. My first thought was to cherry pick the commit of the pull request he submitted, but the parent for the cherry pick parameter is confusing, and it also brings some conflicts.

I'm not sure whether fixing these conflicts caused by cherry-picking the merge commit itself are worth it, or should I just cherry-pick one by one?

sean e
  • 11,792
  • 3
  • 44
  • 56
Christopher Francisco
  • 15,672
  • 28
  • 94
  • 206
  • It's usually a mistake to cherry-pick many commits like this (it sets you up for future misery), *or* to cherry-pick a merge (same effect). In any case a *pull request* just means "I, developer D, have stuff for you". As the integrator, you should have D *re-base* (with `git rebase`) his stuff—his commits—into a situation that makes it easy and correct for you to simply `git merge` the result the way *you* want it done. It's usually wiser to get *him* to rebase and fix conflicts, since he *wrote* the stuff and probably has a better idea *how* to fix conflicts. – torek Mar 22 '17 at 22:12
  • This is probably a better approach. I'm sure we'd need to adjust the git workflow in order to handle things like this(?). At least, how would it go if you have an already unstable develop branch, but your release is comming up soon? – Christopher Francisco Mar 23 '17 at 13:00
  • We have actually had that (at a previous $job) and what we did was create a branch just for the release and mass-pick. It was a nightmare, especially because we trouble getting people to use good one-line commit subjects too, making it very hard to know *which* commits to mass-pick. – torek Mar 23 '17 at 13:06
  • 2
    Isn't `git rebase` just a bunch of mass cherry picking tool? – BenKoshy Apr 28 '20 at 01:13
  • @BKSpurgeon it is! And in `--interactive` mode you get to mess with the script! And with great power comes great responsibility (and danger)! Checkout [my solution to this problem](https://stackoverflow.com/a/61411955/8910547), in particular my annotations of the interactive script (todo file). – Inigo Apr 28 '20 at 01:36

1 Answers1

0

Write a 1-liner to get all "missing" revisions from the developer you want and cherry-pick them one by one (perhaps report and drop the ones that generate a conflict).

Roughly something like this (lots of details left out, for sure):

git log --pretty=%h whatever-conditions-to-get-list-of-revisions | while read revision; do git cherry-pick $revision; if [ $? -ne 0 ]; then echo "Revision $revision failed to be cherry picked.... stopping"; break; fi; done

eftshift0
  • 26,375
  • 3
  • 36
  • 60