All of lore.kernel.org
 help / color / mirror / Atom feed
From: Barret Rhoden <brho@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "René Scharfe" <l.s.r@web.de>,
	git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"David Kastrup" <dak@gnu.org>, "Jeff King" <peff@peff.net>,
	"Jeff Smith" <whydoubt@gmail.com>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Stefan Beller" <stefanbeller@gmail.com>
Subject: Re: [PATCH v2 2/3] blame: add the ability to ignore commits and their changes
Date: Tue, 22 Jan 2019 14:35:00 -0500	[thread overview]
Message-ID: <20190122143500.397abc8e@gnomeregan.cam.corp.google.com> (raw)
In-Reply-To: <xmqqlg3ch85x.fsf@gitster-ct.c.googlers.com>

On 2019-01-22 at 10:14 Junio C Hamano <gitster@pobox.com> wrote:
> René Scharfe <l.s.r@web.de> writes:
> 
> > Am 17.01.2019 um 21:29 schrieb Barret Rhoden:  
> >> The blame_entry will get passed up the tree until we find a commit that
> >> has a diff chunk that affects those lines.  If an ignored commit added
> >> more lines than it removed, the blame will fall on a commit that made a
> >> change nearby.  There is no general solution here, just a best-effort
> >> approach.  For a trivial example, consider ignoring this commit:
> >>
> >> Z: "Adding Lines"
> >>  foo
> >> +No commit
> >> +ever touched
> >> +these lines
> >>  bar  
> >
> > Wouldn't it make more sense to assign such lines to unknown, perhaps
> > represented by an all-zero commit ID, instead of blaming a semi-random
> > bystander?  
> 
> I share the sentiment.
> 
> Isn't it, however, showing a bigger problem in the "feature"?
> 
> Your "a change that adds lines without removing any" is an obvious
> case where these added lines have no corresponding lines in the
> preimage, but most of the time it is unclear what line corresponds
> to what previous line.  If a commit being "ignored" brought a change
> like this:
> 
>      1
>     -four
>     -three
>     +3
>     +4
>      5
> 
> did "+3" come from "-three"?
> 
> Or did "+4" (read: "added '4'") come from "-three" (read: "removed
> 'three'")?  Did it come from "-four"?  Or was it genuinely added by
> that ignored commit?  Your suggestion deals with the case where we
> decide that "+4" had no corresponding lines in the preimage (and
> paint it as "no blame can be assigned").  But when we decide that
> "+4" came from "-four" or "-three", we continue drilling down from
> that ignored commit and assign the blame to either the commit that
> introduced "four" or the commit that introduced "three", which would
> obviously give us different result.  Worse yet, if a reader expected
> us to consider "+4" came from "-four" at that ignored commit, but
> the algorithm decided that "+4" corresponded to "-three", when we
> show the commit that eventually gets blamed for that line that has
> "4" has no "four" (it has "three"), which I suspect would confuse
> the reader of the output.
> 
> So... I dunno.

I guess if you swap the lines as well as change them, then we're not
going to be able to detect that.  Just to be clear, if you did this:

Commit A:
---------
 other_stuff
+one
 other_stuff

Commit B:
---------
 other_stuff
 one
+two
 other_stuff

Commit C:
---------
 other_stuff
-one
-two
+1
+2
 other_stuff

And ignore commit C, my change will properly identify commit A and B,
e.g.:

OTHER_HASH Author Date 11) other_stuff
*A_HASH    Author Date 12) 1
*B_HASH    Author Date 13) 2
OTHER_HASH Author Date 14) other_stuff

But if you swapped the lines in addition to change names to numbers:

Commit C-swap:
--------------
 other_stuff
-one
-two
+2
+1
 other_stuff

Then it won't have the semantic knowledge that "one" == "1".  If a user
is ignoring a commit, we don't have an oracle that knows exactly what
that commit did to determine what commit the user wants blamed.  The
current change attempts to find the last commit that touched a line.

Barret


  reply	other threads:[~2019-01-22 19:35 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-07 21:30 [PATCH] blame: add the ability to ignore commits Barret Rhoden
2019-01-07 23:13 ` Junio C Hamano
2019-01-08 16:27   ` Barret Rhoden
2019-01-08 18:26     ` Junio C Hamano
2019-01-09 20:48       ` Barret Rhoden
2019-01-10 22:29         ` Junio C Hamano
2019-01-14 15:19           ` Barret Rhoden
2019-01-14 17:45             ` Junio C Hamano
2019-01-14 18:26               ` Randall S. Becker
2019-01-14 19:03                 ` Barret Rhoden
2019-01-15  6:08                 ` Junio C Hamano
2019-01-09 21:21       ` Stefan Beller
2019-01-08 13:12 ` Ævar Arnfjörð Bjarmason
2019-01-08 16:41   ` Barret Rhoden
2019-01-08 18:04     ` Barret Rhoden
2019-01-17 20:29 ` [PATCH v2 0/3] " Barret Rhoden
2019-01-17 20:29   ` [PATCH v2 1/3] Move init_skiplist() outside of fsck Barret Rhoden
2019-01-18  9:25     ` Johannes Schindelin
2019-01-18  9:45     ` Ævar Arnfjörð Bjarmason
2019-01-18 17:36       ` Junio C Hamano
2019-01-18 20:59         ` Johannes Schindelin
2019-01-18 21:30           ` Jeff King
2019-01-18 22:26             ` Ævar Arnfjörð Bjarmason
2019-01-22  7:12               ` Jeff King
2019-01-22  9:46                 ` Ævar Arnfjörð Bjarmason
2019-01-22 17:54                   ` Junio C Hamano
2019-01-22 18:28                   ` Jeff King
2019-01-17 20:29   ` [PATCH v2 2/3] blame: add the ability to ignore commits and their changes Barret Rhoden
2019-01-18  9:47     ` Johannes Schindelin
2019-01-18 17:33       ` Barret Rhoden
2019-01-20 18:19     ` René Scharfe
2019-01-22 15:26       ` Barret Rhoden
2019-01-22 18:14       ` Junio C Hamano
2019-01-22 19:35         ` Barret Rhoden [this message]
2019-01-23 19:26           ` Junio C Hamano
2019-02-01 20:37             ` Barret Rhoden
2019-01-17 20:29   ` [PATCH v2 3/3] blame: add a config option to mark ignored lines Barret Rhoden
2019-01-18 10:03     ` Johannes Schindelin
2019-01-18  9:52   ` [PATCH v2 0/3] blame: add the ability to ignore commits Ævar Arnfjörð Bjarmason

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=20190122143500.397abc8e@gnomeregan.cam.corp.google.com \
    --to=brho@google.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=dak@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=l.s.r@web.de \
    --cc=peff@peff.net \
    --cc=stefanbeller@gmail.com \
    --cc=whydoubt@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.