0

My code locally:

    disableCaching()
    setupGoogleMaps()

Change from remote:

    disableCaching()
    FirebaseApp.configure()
    initializeNotificationService()
    setupGoogleMaps()

For me, it seems obvious that two lines have been added above setupGoogleMaps()

But why does git prompt me to fix this conflict manually?

enter image description here

Is there a tool that can fix those easy conflicts automatically?

I already tried the magic icon for resolving simple conflicts but this is not working in this case.

enter image description here

I was able to reproduce it with this repo:

https://github.com/tolotrasamuel/easy-conflict

  1. git checkout featurebranch

  2. git pull origin/master

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437
TSR
  • 17,242
  • 27
  • 93
  • 197
  • What's the conflicting part like? – ElpieKay Jun 06 '22 at 14:27
  • The problem isn't solving your particular easy case properly, it's identifying when something that looks like your easy case can't be solved that way. It's better to let humans make the judgment calls. – jthill Jun 06 '22 at 15:42

1 Answers1

1

Is there a tool that can fix those easy conflicts automatically?

Not really, no. The reason Git is turning to you for help is exactly that "automatically" performing the merge isn't working.

The reasons why Git needs help here when you think it shouldn't, is that Git is taking more than one line into account in deciding where the hunks are. You compare

disableCaching()
setupGoogleMaps()

With

disableCaching()
FirebaseApp.configure()
initializeNotificationService()
setupGoogleMaps()

And you say "it seems obvious that two lines have been added". But:

  • Those are different and equally weighted contributions to the merge; i.e., it is not the case that the second one is laid on top of the first, but rather that both of them have to be laid somehow on top of what was originally present, which was just the line disableCaching.

  • To Git, the single pair of lines in the first code counts as just one hunk — and, seen that way, it is clear different from the same hunk in the second code.

My advice in this situation would be:

  1. Don't look for a "tool". Just resolve the conflict and move on. And

  2. Don't use a GUI for this, just jump in and edit the conflicted text file by hand. I think you'll find that's a lot easier. And it's easier to understand, too.

Here's what we get using the diff3 mode:

setupInstabug()
setupAppCenter()
<<<<<<< HEAD
disableCaching()
setupGoogleMaps()
||||||| a19174f
disableCaching()
=======
disableCaching()
FirebaseApp.configure()
initializeNotificationService()
setupGoogleMaps()
>>>>>>> origin/master

The bit in the middle is what we originally had, namely, just the line disableCaching. Okay, so one branch, yours, wants to put

setupGoogleMaps()

after that. The other branch, master, wants to put

FirebaseApp.configure()
initializeNotificationService()
setupGoogleMaps()

And you're saying, fine, so why not just do both?

But to Git, there is no "both": those are two completely different things that might be added after your line, because disableCaching is a unit together with the following line. It doesn't see this the way you do. It's saying, "Which did you want: the one line, or the three lines?" So since you know what's meant — namely, the three lines — simply edit the file to say so:

setupInstabug()
setupAppCenter()
disableCaching()
FirebaseApp.configure()
initializeNotificationService()
setupGoogleMaps()

Now say git add . and then git merge --continue and you're all set.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • Turns out someone has merged their feature branch using squash merge, this created a recursive conflicts as shown in master branch. Solution was to tell the team to use Merge no fast forward https://stackoverflow.com/questions/11797904/git-merge-squash-and-recurring-conflicts – TSR Jun 06 '22 at 16:28
  • "Tell the team" is dangerous. A spoken contract is not worth the paper it's printed on. GitHub lets you enforce _rules_ about these things. – matt Jun 06 '22 at 16:31
  • That would have been ideal, unfortunately, Github nor Azure does have a feature to limit merge type base on source branch, it can only be ruled out based on destination branch [epicMerged/*] -> [develop] [Rule: Merge no fast forward Only] [hotFixMerged/*] -> [develop] [Rule: Merge no fast forward Only] [developRebase/*] -> epic/*] [Rule: Merge no fast forward Only] [feature/* , fix/*] -> [epic/*, release/*, develop] [Rule: Squash Only] – TSR Jun 06 '22 at 16:42
  • Darn! Yeah, I'm used to working in a world where the rule in GitHub is enforced across the board, i.e. there is only one button option available. – matt Jun 06 '22 at 16:45