2

We had a branch a. Someone needed to improve functionality B they were planning on working on by using a function from a. So they branched out from a with branch b. Then, someone wanted to improve specific functionality in a to get a qualitative boost in performance of B so they branched out from b and created c.

My question is, what's the best way to get all the changes specifically add in c and put them in a without any changes from b. Should you use Cherry Pick in cases like this? Is there a superior way to accomplish this? Could this result in a messy error in git?

AturSams
  • 7,568
  • 18
  • 64
  • 98

1 Answers1

1

One cleaner way would be to branch c from a, not b.
And then merge c to a and rebase b on top of a
(or rebase b on top of c, while c isn't yet merged on a).

If you branch c from b and cherry-pick, you might have issues later on when you will merge b (which might include c enhancement) to a.
That is because cherry-picking can introduce duplicate commits and/or functional dependencies.
You generally cherry-pick from one branch to another when you know you will never merge that "one branch" anyway.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Can we still make `c` branch from `a`? This is what we want. `c` was branched from `b` for lazy convenience, to test if `b` is improved by `c`, it was easier to have `b` as a father for a git novice. – AturSams Oct 15 '15 at 07:13
  • @zehelvion you can rebase c --onto b without any issue (http://stackoverflow.com/a/23647453/6309) – VonC Oct 15 '15 at 07:16
  • @zehelvion other example of rebase --onto: http://stackoverflow.com/a/2369516/6309. And then push --force – VonC Oct 15 '15 at 07:21
  • Someone said that rebasing is dangerous if the branch is already shared with other people. Does this mean it should be avoided? In our case, the branch is shared (on the origin). – AturSams Oct 15 '15 at 07:26
  • @zehelvion yes, it should be avoided. Or well communicated, in order for others to reset (after a fetch) their branch to the new SHA1 shared on origin. – VonC Oct 15 '15 at 07:28
  • What if we copy the changed file(s) from `c` onto `a` and simply disregard `c` from now on... Is there any relatively clean way to do that? – AturSams Oct 15 '15 at 07:31
  • @zehelvion *Then* cherry-picking would be perfectly acceptable: you can cherry-pick a range of commits: http://stackoverflow.com/a/1994491/6309 – VonC Oct 15 '15 at 08:07
  • The problem with commits is that they may include tiny changes that affect unrelated files. – AturSams Oct 15 '15 at 08:19
  • @zehelvion indeed, that is the functional dependencies issue I was referring to in http://stackoverflow.com/questions/881092/how-to-merge-a-specific-commit-in-git/881112#881112. – VonC Oct 15 '15 at 08:21