chirin <takonatto@xxxxxxxxx> writes: > From what I understand, your scenario is exactly what I expect. Which is why > when I asked around my colleagues, no one was able to explain why I'm having > this issue. > > As per your scenario: > > # A changes hello.txt > > # Going into B (who has not done anything to hello.txt) > git pull --> merge conflict on hello.txt > > git commit > git pull --> OK This is quite different from what Dov showed as "the right way to report". Dob's recipe begins from absolutely empty state and creates three repositories involved with exact sequence and anybody can reproduce how it is supposed to work (or break). It was written in such a way that you can try to follow the sequence to see if you see a behaviour that is different from Dob expects (in which case your machine, filesystem or the Git binary you installed might be the culprit). Have you tried it? Compared to that, your version above does not say anything about what the state of A, B and the repository A and B interact with were in before the problem started, so even if Dob wanted to help you by trying to reproduce your situation, there is not enough information to do so. >> In this sequence, which fulfills the scenario that you described, >> there are no conflicts. So I suggest that you try to change the >> command sequence to illustrate what you don't understand and ask >> again. Exactly. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html