1

I have few files which I would like to "invalidate" in my dev_branch lets call it branch "A" so once merging with another dev_branch lets call it branch "B" I get a merge conflict. Those few files I mention have been previously edited in that other dev_branch called B.

Here is what I tried so far:

I removed the files from index cache of my branch "A" and added them back again.

git checkout -b feature/A origin/feature/A
git -rm -r --cached "myFolder"
git commit -am "removed the files"
cd "myFolder"
git add .
git commit -am "added back the files"

So far the branch A is two commits away from master and branch B just one with edited files and now I tried to merge but still not getting the merge conflict

git merge origin/feature/B

why cant I cause merge conflict? both have commits not in master branch how do I force a merge conflict without individually changing each files content?

  • We can't see where origin/feature/b was started nor what files were modified there. But try this so you can get your merge conflict to show up... right after you do your last commit from your instructions: **git checkout -b just-a-test HEAD~2**, now edit one of the files inside myFolder, **git commit -am "Modified a file inside myFolder"; git merge feature/A**. You should get a tree conflict at this point (a branch modified a file, the other deleted the same file). – eftshift0 May 28 '18 at 15:24
  • @eftshift0 would you please provide me with an example where I might understand your approach better because just by reading the command I dont think I can follow your approach –  May 30 '18 at 13:33

1 Answers1

0

In order to get a conflict in any one particular file, you need to have Git:

  1. compute the merge base commit, as it does for most merges;
  2. find that this commit is an ancestor of both branch-tip commits;
  3. find that one particular file in the merge base differs from that same file in both tip commits;
  4. and last, find that combining those changes results in a conflict.

For more about the first three, see any of many previous questions. I have a long form answer here that goes into details of merge strategies, as well as discussing the normal process of finding the merge base given the default kind of merge. For much more about point 4, see when exactly does a git merge conflict arise.

(The contents of your index / staging-area at the time you run git merge are not relevant to this particular process, except that git merge normally requires that the index be "clean", i.e., match the current commit, to start.)

You can also get what I call a high level conflict, as eftshift0 notes in a comment. For this to occur, the merge base version of the file can be:

  • missing: this is an "add/add" conflict
  • have a different name than in one of the two tip commits, and be missing in the other tip commit: this is a "rename/delete" conflict
  • have different content in base vs one tip, and be deleted in the other tip: this is a "modify/delete conflict"
  • have three different names in the three commits: this is a "rename/rename" conflict

(I think that covers all possible cases).

torek
  • 448,244
  • 59
  • 642
  • 775
  • Hi and thanks for your answer, please provide me an example I cant follow your approaches. –  May 30 '18 at 13:36
  • It's easy to create a conflict *if you control all three commits*. In your situation, it sounds like you control *only one of the commits*. This means you need knowledge about what's in the *other two* commits in order to create a conflict. Moreover, in your original question you asked about creating conflicts "without individually changing each files content", and unfortunately for your desires, **you can't**. You *must* change some file's content in some way in order to get a conflict in that file. That's a necessary condition, though it's not sufficient on its own either. – torek May 30 '18 at 16:54
  • thanks alot I get your point and yes I do know what is in other commits. I guess I'll have to change the content of each file individually. –  Jun 04 '18 at 06:27