-1

Working in Visual Studio Mac on a Xamarin.forms project.

So:

  • I had a bug with something called DeviceTokens in my "development" branch
  • I went back and found a commit that didn't have the bug
  • I made a branch from it called "doesNotHaveDeviceTokenBug"
  • I fixed the bug & the project runs just fine... from that branch

So now I want to merge the fixes back into my other branch, right?

So I switch back to "development" and I do this:

enter image description here

..and then this:

enter image description here

...and I get a warning about conflicts:

enter image description here

...and I resolve them all using "theirs", because that's what I want, right?

enter image description here

...and then here's the thing...

...now my project won't run.

If I switch back to the "doesNotHaveDeviceTokenBug" branch, the project still works great.

But when I'm in"development", I get a ton of errors.

...I don't get it. I fixed a bug, and now I want to merge that fix back into its original branch--isn't that the whole point of this thing??

What am I doing wrong?

Le Mot Juiced
  • 3,761
  • 1
  • 26
  • 46

1 Answers1

2

I use SourceTree on Mac a lot, and I'm very fond of it, but I would never in a million years merge "blind" like that. When you merge doesNotHave... into development and you get a merge conflict, stop and look at the file(s) that are conflicted and resolve the conflict(s) yourself directly in those files. Your last screen shot shows the conflicted files with their conflict markers; you just edit those directly with your favorite text editor, and when you're all done, you mark them resolved and let the merge continue.

So I would suggest doing a hard reset of development back to c2c8c50c and doing the merge again, and this time, look at what's happening during the conflict and make sure it all makes sense to you as you resolve it.

Also, you seem to think that a merge with a conflict resolved by the theirs strategy is going to be identical to theirs. In other words, you are saying: hey, this tested out fine on doesNotHave... before the merge, so it should test out fine on development after the merge.

But there is a lot more to a merge than that. Both sides of the merge can make contributions. So no matter how you resolve the conflicts within particular files, you may still be combining your contributions on doesNotHave... with contributions from develop that don't play well together.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • ...that makes sense, and I suppose I guessed it was something like that, but how do I do what I want to do, which is basically make 'development' exactly like 'doesNotHave..'? – Le Mot Juiced Oct 07 '21 at 17:12
  • Well if you really wanted `development` to be _exactly_ like `doesNotHave...` you would just make `doesNotHave` _be_ `development`. For example, you could do an `ours` merge of `development` into `doesNotHave` and then hard reset `development` to `doesNotHave`. (That would work because an `ours` merge is not a merge; it just changes the parent topology but ignores all contributions from the incoming branch.) But that sounds like a really bad idea. Doesn't `development` have a life of its own? Of course if `development` does _not_ have a life of its own you can do anything you darned well want. – matt Oct 07 '21 at 17:17
  • By the way you might want to read my essay https://www.biteinteractive.com/understanding-git-merge/ - it explains what merge is, plus what you're trying to do might be better handled on the command line (Sourcetree can't do everything). – matt Oct 07 '21 at 17:29