Re: [PATCH] difftool: add support for an extended revision syntax

[David Aguilar <davvid@gmail.com>]

On Mon, Mar 23, 2009 at 4:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
> David Aguilar <davvid@gmail.com> writes:
>
>> Keep in mind that the syntax that this patch added does not have file~3
>> = HEAD~3.  file~3 means finding file as it existed 3 changes-to-file
>> ago, which is != to HEAD~3 if file did not change in the last 3 commits.
>
> If your motive is to introduce inconsistency to the UI by adding this kind
> of new notation _only to difftool_, I have to reconsider moving it out of
> contrib/ area.


I totally agree that this patch was half-baked, not fully defined,
and should be dropped.  I hope that doesn't influence
your decision for the rest of the patches that came before it.

The notion of "3 commits ago" is ambiguous in a merge-heavy work flow
and using ~ would only confuse things, so I'll see if we can find a better
way to do it, but it shouldn't happen in difftool (if it happens at all).


>
> While I do not fundamentally oppose to add convenient notations for useful
> concepts, you need to start at making sure if this "three changes ago" is
> a well defined concept to begin with.
>
> And it is not a well defined concept in a merge-heavy environment, unless
> you define what you mean by "three changes ago".
>
> If you consider this history:
>
>  ---Y---o---X---M---o mainline = HEAD
>               /
>   ---A---B---C topic
>
> where A, B, C and X, Y are the only commits that touched the file you are
> interested in, how do you define 3-changes-ago?
>
> Maybe X was just a totally uninteresting typofix to a comment, while A, B
> and C were adding a very interesting new feature.  Don't forget that M
> also changes the file from either of its parents (X or C).  Does M count
> as the last change?  Or does it not count because it is just a mechanical
> unconflicting merge?  Which one of X or C is the penultimate change?  The
> one with an earlier committer timestamp?  Tiebreaking with timestamps is
> known to be flawed in the presense of clock skew.
>
> For the consistency of the UI, "starting at HEAD, following first-parent
> ancestry, find N-th commit that touches the path, ignoring all the side
> branches" MUST be the semantics of a notation that uses tilde followed by
> number (so file~3 must mean Y in the above picture), because HEAD~3 is
> defined as "three parents ago, only following the first parent ancestry".
> Anything else will invite user confusion.
>
> But I do not think it is necessarily useful to follow only the first
> parent ancestry to find "three-changes ago" (if such a concept exists).
> If you want a notation that means something else, such as X (because
> chronologically the commits that touched the file are M, C and X in the
> ideal world that everybody has well synchronized clock), you shouldn't use
> tilde-number notation but use something else.
>

Understood and thanks for the help,

-- 
    David