1

How does git-blame blame a line that is coming from 2 different revisions on 2 branches that were merged?

Context

I'm working with git-svn and I'm sick of seeing lines on blame that only point to a "merge" revision where there was no, say, real merge performed. I want to see what would happen if I hacked the revision with commit-tree so that I can force the merge to be a real merge (let's not consider git-svn's peculiarities for the time being and let's consider this a pure git problem). I tried blaming a file to see if now git is able to see where the line is really coming from (after having the "real" parent now included thanks to commit-tree) but I still get the same output as if there was no merge of the other branch.

Thanks in advance.

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • If the *merged file* has contributions from both side of the merge, you're kind of stuck, as `git blame` picks one parent and goes that way (only). I don't deal with git-svn so I'm not sure what's going on there. – torek May 30 '17 at 15:58
  • Hmm..... what would happen if I tried "skipping" all the revisions that were used to "solve the merge"? Let me try to see if that gets me closer to my goal. – eftshift0 May 30 '17 at 16:03
  • Yeap... that worked miracles. The thing is that I would "wipe" (from my git repo) the revisions that were used for conflict resolution on svn (and I'll have to rewrite git-svn history... which is kind of tricky.... fortunately I already have some experience on this regard https://github.com/eantoranz/git_svn_rewrite). Could create a revision where I state that it covers conflict resolution of branch X on revision range Y:Z just in case. Have to think over if it's worth it. – eftshift0 May 30 '17 at 16:13

0 Answers0