On Wed, Aug 17, 2011 at 3:53 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Currently, we use @{...} for:
>
> - Negative integers are "-N branch-switching ago" (only without any ref
> on the left);
> - Non-negative integers "The tip of the named ref before it was changed N
> times";
> - An approxidate that is case insensitive; or
> - "u" and "upstream".
[snip]
> The only remotely semi-plausible enhancement I could think of is perhaps
> to allow @{/regexp} to find a reflog entry that matches the given pattern,
> and in such a use case we would certainly want to take the pattern in a
> case sensitive way. This change closes the door to that, and that is the
> only downside I can think of right now.
I'm reasonably convinced by this argument as a refutation of the
consistency argument I proposed above. Given that the date format will
always be insensitive, and any enhancements added would probably want
to be case-sensitive (I can think of a few other things I'd "like",
but which are pretty silly: @{merge-base <commits>*}, @{octopus-base
<commits>*}); this syntax is always going to be inconsistent.
Additionally, as pointed out elsewhere in the thread, the most-similar
existing syntax (^{tree}) is already case-sensitive.
Given all of the above, I think that allowing @{upstream} to be
case-insensitive is certainly wrong, as it's slightly confusing and
not very useful.
Given that @{upstream} should be case-sensitive, it would be bizarre
to allow @{U} as a synonym, so I think I'm convinced that this is not
worth it, despite the convenience it brings.
On Thu, Aug 18, 2011 at 2:31 AM, Michael J Gruber
<git@xxxxxxxxxxxxxxxxxxxx> wrote:
>>> As a simpler case, a user could tailor to her keyboard layout with
>>>
>>> git config revalias.↓ u
>>
Hmm, this opens up interesting ideas:
git config revalias.base = '! git merge-base -a "$@"'
git show HEAD@{base master}
but that seems like it's a bit over-the-top for some reason :).
Conrad
--
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