0

Note: in thinking about this and looking over the git flow description again, I think I'm actually doing git flow wrong (making feature branches off of master instead of dev). Doesn't change my question, but before everyone starts jumping in to point out that I'm doing it wrong ;)

I am following something akin to git flow, where I have code in a foo-release branch off of master that I want to merge into my foo-dev branch off of a dedicated (and shared with other developers) dev branch used for testing.

I can't just git merge foo-release into my foo-dev because master has a bunch of unrelated commits that aren't in dev (I think this shouldn't be the case according to git flow, but for now it is), and those other commits would come with it if I tried to create a github PR after that (see here)

I thought I'd found the answer in git cherry-pick main...foo-release, which just takes the commits native to my release branch and applies them to my dev branch.

But then say I merge my foo-dev into dev, deploy, find a problem, and then fix it in foo-release (in git flow you make all code changes in the release branch).

Now when I run git cherry-pick main...foo-release, some commits have already been applied, so in cherry-pick they are empty patches so it stops to complain about each one. If I run git cherry-pick --continue for each of those it seems to work ok, but that's really annoying.

What I want is something that cherry-picks a range, auto-skipping empties, and --allow-empty and --keep-redundant-commits don't seem to be it. Is there any way to do this?

usernamenumber
  • 149
  • 1
  • 8
  • Based on the title alone, one solution is to `git rebase` instead. – Code-Apprentice Sep 21 '22 at 18:47
  • "I can't just git merge foo-release into my foo-dev because master has a bunch of unrelated commits that aren't in dev (I think this shouldn't be the case according to git flow" Yes, that is true. I suggest you resolve this as soon as is practical for your project. In general, master should only have commits not in develepment when you have to deploy an emergency hot fix. And then that hot fix should also be merged into dev. I usually do this by merging master into dev. – Code-Apprentice Sep 21 '22 at 18:49
  • You can't make `git cherry-pick` do that, but you *can* feed `git cherry-pick` a list of pre-selected commits from `git rev-list` the same way the old interactive rebase script did, so as to avoid the ones that will definitely *become* empty during cherry-picking. See `git rev-list --right-only --cherry-pick` in the `git rev-list` documentation. – torek Sep 22 '22 at 10:41

1 Answers1

0

I suggest doing git rebase instead of git cherry-pick. It provides some options that are more flexible. And it automatically throws away any empty commits.

Code-Apprentice
  • 81,660
  • 23
  • 145
  • 268
  • I love rebasing and use it whenever I can, but I don't think it applies here, with separate foo-release and foo-dev branches. If I was working from a single branch, it's true that I could do `git rebase dev` from my foo-release branch, but I'm essentially trying to "copy" commits from foo-release to foo-dev. I have not found a way to make rebase do that, but if you know one I'd love to hear it! – usernamenumber Sep 21 '22 at 18:55
  • @usernamenumber That's a good point. You could create a new branch for the rebase, something like `git checkout -b rebase-branch foo-release && git rebase foo-dev && git chekout foo-dev && git merge rebase-branch` which is a little awkward. – Code-Apprentice Sep 21 '22 at 19:15
  • @usernamenumber with that said, is there a reason you can't merge master back into dev? It would make this much simpler. – Code-Apprentice Sep 21 '22 at 19:16