git practice exercise ( merging two branch and dealing with conflict)

Question

I have to clone this repo : https://github.com/glo2003/H21-tp1-git and integrate both branches which are :

refactor/structure and fix/ingredients to the main branch

Main currently looks like this :

Framboise
Banane
Champignon

refactor/structure has a new folder called listes with the file liste.txt in it ( so the file structure is listes\listes.txt) :

- Framboise
- Banane
- Champignon

fix/ingredients :

Framboise
Banane
Pommes

The end result wanted is this one (so champignon is replaced by Pommes and the list has a new format with the ' - ' also the folder structure will be listes\listes.txt

- Framboise
- Banane
- Pommes

What i tried :

git clone https://github.com/glo2003/H21-tp1-git.git

git merge fix/ingredients

git merge refactor/structure

And i did git status to check to situation :

It looks like a listes.txt got deleted but not sure.

From there i wanted to fix the conflict, with vi listes.txt or vi listes\listes.txt but i don't see any Head tag for the conflict so i am a bit confused ? What am i doing wrong. Thanks a lot.

Answer 1

This is a file level conflict, not a textual conflict. To fix it, you manipulate the index: you say git add to preserve a file and git rm to remove a file. Then say git commit to make it so.

For example, if you like what the restructure branch did, you can say

$ git rm liste.txt
$ git add listes/liste.txt
$ git commit -m"finish merge"

But then you have also accepted the contents of that file. If you wanted the contents to match main, you'd need to copy what's in the top level liste.txt into what's in listes/liste.txt before doing those file level things.

---

In the comments, you've basically said you wish this were a text-level conflict so you could resolve it at text level. To make that so, you need to:

1. Abort the merge.

2. Rearrange the file structure on main to match the file structure on the branch, and add and commit.

3. Now perform the merge, specifying it this way:

    git merge -Srecursive -Xno-renames refactor/structure
   

This will give you the moved liste.txt as a text conflict that you can proceed to resolve in vi or whatever.

So, here's how I solved it, from the start:

$ git clone git@github.com:glo2003/H21-tp1-git.git
$ cd H21-tp1-git/
# create local branches
$ git checkout fix/ingredients
$ git checkout refactor/structure
$ git checkout main
$ git merge fix/ingredients
$ git merge refactor/structure
# file-level conflict, abort
$ git merge --abort
# mimic "theirs" file structure, and merge
$ mkdir listes
$ git mv liste.txt listes/liste.txt
$ git add .
$ git merge -Srecursive -Xno-renames refactor/structure
# now we have the text level conflict you wanted, as we can see:
$ cat listes/liste.txt
<<<<<<< HEAD
Framboise
Banane
Pommes
=======
- Framboise
- Banane
- Champignon
>>>>>>> refactor/structure

Answer 2

When you run git merge, git:

1. Finds some common / shared starting-point. This is another commit, somewhere in history, from which both "you" (the person running git merge) and "they" (whoever produced the commit you're merging) started.

2. Compares the entire contents of the merge base to your current commit. These are "your changes". In your case, you changed an existing file, liste.txt.

3. Compares the entire contents of the merge base to their commit. These are "their changes". In their case, they removed an existing file, liste.txt, and created an entirely different file, listes/listes.txt.

4. Combines—or attempts to combine—these two sets of changes.

Conflicts occur when the changes cannot be combined automatically using the simple rules that Git has built in. Here, the two changes that cannot be combined are:

• you modified some file;
• they removed that file entirely.

Git calls this a "modify/delete conflict".

Now, you claim that they renamed liste.txt to listes/listes.txt. On what basis do you make this claim? If the file contents of listes/listes.txt were exactly the same as the file contents of the former, now-deleted liste.txt, I might agree with you—and so might Git. If your basis for this claim is that liste.txt and listes.txt are sufficiently similar, well, I don't see that off-hand. Git doesn't see it either. Once you point out that if we replace line 3 and make medium-small changes to lines 1 and 2, this degree of changing would alter the contents of liste.txt to match those in the new file listes/listes.txt, then I might agree—and so might Git.

In the end, what Git does with this, to decide whether some file was renamed, is to compute what Git calls a similarity index. If the similarity index of the old file and the new file is high enough—meets or exceeds a 50%-similar threshold—Git will declare that the file was renamed, rather than deleting the left-side file (liste.txt) and creating an entirely new and different right-side file (listes/listes.txt).

You can control this rename similarity threshold, using -X find-renames=number. You can also, as in matt's answer, disable rename detection entirely, using -X no-renames. That's useful if Git is mis-classifying something as a rename when it shouldn't—but if there are some renames that Git should find, you'll have to deal with them yourself.

In general, Git's similarity detection works pretty well on large files. The reason it works so poorly on your sample file is that your sample file is tiny, and too many lines are too different.