Re: [PATCH] blame: Allow to blame paths freshly added to the index

From: Mike Hommey <mh@glandium.org>
Date: Jul 15, 2016, 23:16 UTC
Message-ID: <20160715231656.iztvtftk5ttrzeow@glandium.org>
In-Reply-To: <xmqqr3auli2x.fsf@gitster.mtv.corp.google.com>

Show 5 quoted lines

> I suspect that this would be useful without copy detection.  If you
> "git mv fileA fileB" (optionally followed by "edit fileB"), fileB
> would not be in HEAD but you should be able to trace the lineage of
> the lines in it back through the renaming event, and this change
> also allows that use case, no?

It should, but that'd be copy/move detection, wouldn't it? :)

Show 28 quoted lines

> > I suspect that the above change needs to be updated further if the
> > user wants to run "blame path" during a conflicted renaming merge,
> > i.e.
> >
> >  0. Before two histories diverged, there was old_path.
> >  1. Our side updated contents of that file and kept it at old_path.
> >  2. Their side updated contents of that file and moved it to path.
> >  3. "git merge" notcied the rename, created three stages at "path",
> >     with the result of conflicted content-level merge in the working
> >     tree at "path".
> >  4. The user edits "path" and resolves the conflict, but wants to
> >     double check before running "git add path".
> >  5. "git blame path"
> >
> > Perhaps something like this should suffice:
> >
> >     pos = cache_name_pos(path, strlen(path));
> >     if (0 <= pos)
> >     	; /* ok */
> >     else if (!strcmp(active_cache[-1 - pos]->name), path)
> >         ; /* ok -- just unmerged */
> >     else
> >     	die("no such path in HEAD");
> 
> I do not think the "conflicted renaming merge" example would not be
> a problem in practice iff "git merge" was used, because the fake
> working tree commit would look at both our tree and their tree, and
> find "path" in theirs inside the loop above this "die".

More than that, it seems that's a case that already works without the patch (it doesn't complain that "no such path in HEAD", although it only identifies the "theirs" part of the merge conflict when blaming the file straight out of the merge failure, but that'd be a separate issue.

> But the user can be in the same conflicted rename situation with
> "git am -3" or cherry-pick, and in these cases there won't be extra
> parent commits for the fake work tree commit, hence the conclusion
> does not change.

Indeed, with cherry-pick, the "no such path in HEAD" error is happening with the patch.

Mike