1

I am wondering if there any tools for providing a more verbose file history, especially with regard to merges where our changes are kept. This problem is best explained with an example.

Let's say I made a conflicting change on master and a feature branch:

git checkout master
<made some change to file.txt>
git commit -a -m "Change on master"
git checkout -b feature
<made conflicting change to file.txt>
git commit -a -m "Change on feature"

If I merge feature into master and keep my changes using git checkout --ours file.txt I get different results for file.txt than if I were to merge master into feature (and then merge feature into master to fast forward master). (I understand merging --ours effectively could have also been done inadvertently with mergetool.)

Using git log -p in both these scenarios, the merge commits do not report any change in file.txt, but its contents are different between the scenarios. Now file.txt's change history has been obfuscated and it has become difficult to know which version is in master. I can run git log -- file.txt, but this solution doesn't scale and requires you already know what files were part of the bad merge.

If someone makes the wrong merge decision, if becomes difficult to track down which files were kept the same. Otherwise, if a merge made changes to a file, it is easy to see this.

slythfox
  • 545
  • 6
  • 12

1 Answers1

1

If the conflicts are getting resolved, they're just getting resolved incorrectly (per your comments on this answer), one way to see the differences in file.txt between two branches is with git diff:

git diff master feature -- file.txt

If you issue git diff master feature without any file specification, you'll see all the differences in all the repo's files. Creative applications of git diff will allow you to isolate nearly any changes you'd like.

Otherwise your best bet might be the merge commit itself. By default the commit message will output a conflicts section, which I'd advise against deleting.

Christopher
  • 42,720
  • 11
  • 81
  • 99
  • If someone else uses `git mergetool` and opts to keeps their local changes for each conflict, the result is the same. I used `git checkout --ours ` to replicate (and better describe) the problematic behavior. – slythfox Sep 05 '12 at 22:17
  • @Slythfox Changed my answer pretty much completely. Didn't realize you were using that command to repro it. – Christopher Sep 05 '12 at 22:30
  • I haven't had the chance to play with this yet. Previously, I found the bad merge commit, re-merged, and then used [git ls-files -u](http://stackoverflow.com/questions/3065650/whats-the-simplest-way-to-git-a-list-of-conflicted-files) to get a list of conflicting files, and compared it against the bad merge to get an idea of what files were conflicted but kept as "ours." It seems to work, kinda. I also played with `git checkout --patch ` to get an idea of what changed between the bad merge and a known good commit, which seems like the same idea as `git diff`. – slythfox Sep 07 '12 at 15:15
  • @Slythfox It's more or less the same idea, yeah. – Christopher Sep 07 '12 at 18:21