Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > I don't generally do "git blame" very much at all, and I've found that any > time I do it (even historically - when I've used bk annotate and even > CVS), I have invariably _always_ wanted to go back in history to see the > blame of the *previous* version (because the commit that gets blamed > initially is simply not interesting, and is just whitespace cleanups or > whatever!). Incidentally I added a small patch to underlying git-blame to let you ignore whitespace changes so that you can blame through them. I do not think I merged it to 'master' yet, but it is trivial and look obviously safe and correct. > So I think git-gui isn't quite there yet, but I think it's getting pretty > close. It would need > > - the afore-mentioned bug fixed (I _think_ it is a bug, but maybe you had > some other reason for having two separate columns of commits per line), > so that you can literally click on the *previous* version of a line and > say "I don't care about this commit, I want to see the previous one". I think the two columns are for "who _placed_ these lines in the final image" vs "where these lines originally came into the history". The former is with -C, and the latter is without. An option to re-blame starting from the parent commit of what is currently blamed (i.e. "peel" one level) would certainly be interesting but I do not think git-gui has it (yet). Of course it has a not-so-interesting corner case of deciding which parent to follow for a merge, but a merge commit is blamed only for lines that are either evil or conflict fixups, so in practice there is not much to be gained from peeling a merge. - 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
