From: Bo Yang <struggleyb.nku@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, trast@student.ethz.ch
Subject: Re: [PATCH 1/2] Add a basic idea section for git-blame.
Date: Thu, 8 Apr 2010 22:11:55 -0700 [thread overview]
Message-ID: <x2z41f08ee11004082211g6ae76f38ic1ee65e508b16343@mail.gmail.com> (raw)
In-Reply-To: <7vmxxe74s2.fsf@alter.siamese.dyndns.org>
Hi Junio,
On Thu, Apr 8, 2010 at 1:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
> The name of the game is not "take blame by looking at the diff to see what
> we introduced"; it is "avoid taking blame at all cost, by looking at the
> diff to see what we might have inherited from our parents".
>
> A description closer to the truth would be:
>
> - Look at output of "git diff <rev>^$n <rev>" for each parent ($n runs
> from 1 to number of parents);
>
> - Ignore all +/- lines. The context ' ' lines and lines outside of diff
> hunks are known to have been inherited from $n-th parent and they are
> not our fault. We can happily pass blame for these lines to our
> parent.
>
> - Do the above for all the parents. We (grudgingly) take blame for lines
> that we failed to find corresponding lines in our parents.
>
> The -M option affects what happens between the second and the third step.
> We try to see if the lines that we did not pass blame to <rev>^$n might
> have come from <rev>^$n by running diff between the remainder and the blob
> in <rev>^$n *again*. This lets us catch code movement within the blob,
> hence the name of the option -M.
I think here, not only the code movement, but also the copies will be found too.
Please correct me if I am wrong here. :-)
> The -C option affects the choice of the blob in <rev>^$n. Usually, we
> internally run an equivalent of "git diff -M <rev>^$n <rev>" to notice
> that the file F that we are analyzing used to be called F' in $n-th
> parent, and run the diff against it, but -C allows us to check with paths
> other than that, and additional -C enlarges the search space. This is to
> notice code movement (with a single -C) or copies (with more -Cs) across
> paths.
>
> For illustrated description, read the classic:
>
> http://thread.gmane.org/gmane.comp.version-control.git/28826
Thanks a lot for providing this reference. It really helps me too much
to understand how blame works. I will try to re-read the whole code
according the description here. ;-)
Regards!
Bo
prev parent reply other threads:[~2010-04-09 5:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-08 6:51 [PATCH 0/2] Document update for 'git-blame' '-M' and '-C' option Bo Yang
2010-04-08 6:51 ` [PATCH 1/2] Add a basic idea section for git-blame Bo Yang
2010-04-08 6:51 ` [PATCH 2/2] Change the description of '-M' and '-C' option Bo Yang
2010-04-08 8:00 ` [PATCH 1/2] Add a basic idea section for git-blame Junio C Hamano
2010-04-08 16:27 ` Thomas Rast
2010-04-08 16:51 ` Junio C Hamano
2010-04-09 5:11 ` Bo Yang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=x2z41f08ee11004082211g6ae76f38ic1ee65e508b16343@mail.gmail.com \
--to=struggleyb.nku@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=trast@student.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).