2

I have a curious situation which I can resolve in other methods but I wanted to push my knowledge of git a little further.

I think a diagram is in order. It looks crazy but I think it's not actually that bad. I used square brackets to indicate the current branches.

                   upstream
                     /   \
                   /      \
                 /         \
      starting point        |
        /      \         upstream
   my OSX       \         change (1)
   config        \          \
      |       my linux       \
    worked    config     more stuff
     on A        |        upstream (2)
      |\________ |            |
      |         \|            |
      |        Merge         /|
      |  (OSX into Linux)   /  \
      |          |         /    \
   changed    worked      /     |
   OSX conf    on B      /      |
      | ________/|   ___/    [upstream]
      |/         |  /
      |          | /
      |      Merge (upstream
   Merge B     into Linux)
  into OSX        |
    [OSX]      worked
                on C
                  |
               worked
                on D
               [Linux]

So basically what we have here are 7 pieces of "work" that I have conceptually placed into various commits in this chart. The units of work marked A thru D are actual "work" that I want to use git merging to propagate through both of my [OSX] and [Linux] work branches.

However I want to keep my config file differences (in my real world situation these include a few easy changes in the makefile, but you can also imagine this being a large set of configuration file differences) local to their own branches.

Okay so the problem that I have right now is I want to merge C and D into [OSX]. However, due to reasons (without loss of generality), the upstream changes (marked 1 and 2) I actually want to keep out of [OS X].

I want to establish a workflow where I can arbitrarily switch between my branches (say I work on Linux at my office and on OS X at the coffeeshop because SSH is too spotty in the coffeeshop). One perfectly adequate solution would have been to, say, cherry-pick C and D into [OSX], but I think it is possible to configure everything such that I can actually just merge [Linux] into [OSX] without bringing in the upstream stuff that I want to keep out.

I figured out how to do this too. I can go ahead and do this merge, then do git revert (which actually is functionally just inverse cherry picking) on upstream changes (1) and (2), then at this point I am free to go forward.

So I am almost happy with this. I think that what would be even more powerful is if I could somehow "pin" the upstream at the "upstream" commit so that it automatically does not merge in (1) and (2). This way it would free me from having to perform a potentially large number of cherry picks or reverts.

Is this possible?

Steven Lu
  • 41,389
  • 58
  • 210
  • 364
  • I am not sure to understand all, but `git rebase` will do it no ? something like `git rebase --onto OSX upstream Linux` – Ôrel Mar 03 '15 at 15:40
  • You should be able to merge or cherry pick a specific range of commits. You could also use `git rebase -i` and remove the commits you don't want in your current branch. – Nick McCurdy Mar 03 '15 at 16:00
  • hmm, maybe `git merge -i`? Is that a thing i can do? – Steven Lu Mar 03 '15 at 17:27
  • Git rebase interactive will probably produce a better end result and also be a fairly streamlined workflow what with the editor allowing for manually marking a range of commits to exclude. [this](http://stackoverflow.com/a/10935340/340947) is probably what an "interactive" merge would look like. – Steven Lu Mar 04 '15 at 00:45
  • BTW, `git rebase -i` did not go very smoothly, i had conflicts :( Also, there is the problem where after the rebase the source branch actually gets moved. I don't want that. I do really need to perform a merge. – Steven Lu Mar 04 '15 at 13:05

0 Answers0