On Thu, Jan 21, 2016 at 6:29 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclo...@gmail.com> writes:
>
>> For simplicity, the note of commit A implies rename correction between
>> A^ and A. If parents are manipulated (e.g. "git log --reflog") then
>> the rename output may surprise people.
>
> I do not think "git log --reflog" attempts to show changes to bring
> the tree of @{2} into the shape of @{1}, even though for traversal
> purposes it pretends as if @{1}'s parent is @{2}. So I am not sure
> what you are trying to say in the above sentence.
Hazy memory about hierarchy manipulation by reflog, maybe I'm wrong.
> A path limited "git log -- path1/ path2/..." also manipulates the
> commit->parents for traversal purposes, but I think the patch is
> still produced against the true parents (there is a call to
> get_saved_parents() in log_tree_diff() that shows the change for a
> given commit), and in that context, commit A that has notes about
> the change to bring the tree of commit A^ to its tree still makes
> sense.
>
> I'd be more worried about "git log -m -p"--the diff against the
> second and subsequent parents would not want to use the notes that
> describes the change between the first parent and the resulting
> merge.
I "fix" this by providing the tools and let the user go wild. The line
"A => B" says rename A to B for a diff between any source or target.
But they can also say rename A to B only if diff source is X, or diff
target is Y, or both. The syntax I'm having for that is something like
this
.source X # X can be anything that resolves to a tree SHA-1 with get_sha1()
.target Y
A => B
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
