Junio C Hamano <gitster@xxxxxxxxx> writes:
> 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".
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.
Thanks.
--
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