can we have @{U} as an alias for @{u}

can we have @{U} as an alias for @{u}

[Sitaram Chamarty]

Would be so much faster to type if uppercase U were also allowed...

-- 
Sitaram

[PATCH] rev-parse: Allow @{U} as a synonym for @{u}

[Conrad Irwin]

This facilitates specifying the upstream of a branch if you have
difficulty synchronising your shift-key and other characters, if you
just want to SHOUT at git, or if you're expecting consistency with
@{1DAY}.

Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
---
 Documentation/revisions.txt   |    4 ++--
 sha1_name.c                   |    2 +-
 t/t1507-rev-parse-upstream.sh |    8 ++++++++
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index b290b61..c89d74d 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -87,8 +87,8 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.
   before the current one.
 
 '<refname>@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::
-  The suffix '@\{upstream\}' to a ref (short form '<refname>@\{u\}') refers to
-  the branch the ref is set to build on top of.  A missing ref defaults
+  The suffix '@\{upstream\}' to a ref (short form '<refname>@\{u\}', or '@\{U\}')
+  refers to the branch the ref is set to build on top of.  A missing ref defaults
   to the current branch.
 
 '<rev>{caret}', e.g. 'HEAD{caret}, v1.5.1{caret}0'::
diff --git a/sha1_name.c b/sha1_name.c
index ff5992a..ef4b77f 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -334,7 +334,7 @@ static inline int upstream_mark(const char *string, int len)
 	for (i = 0; i < ARRAY_SIZE(suffix); i++) {
 		int suffix_len = strlen(suffix[i]);
 		if (suffix_len <= len
-		    && !memcmp(string, suffix[i], suffix_len))
+		    && !strncasecmp(string, suffix[i], suffix_len))
 			return suffix_len;
 	}
 	return 0;
diff --git a/t/t1507-rev-parse-upstream.sh b/t/t1507-rev-parse-upstream.sh
index a455551..5be605f 100755
--- a/t/t1507-rev-parse-upstream.sh
+++ b/t/t1507-rev-parse-upstream.sh
@@ -37,6 +37,14 @@ test_expect_success '@{u} resolves to correct full name' '
 	test refs/remotes/origin/master = "$(full_name @{u})"
 '
 
+test_expect_success '@{U} resolves to correct full name' '
+	test refs/remotes/origin/master = "$(full_name @{U})"
+'
+
+test_expect_success '@{Upstream} resolves to correct full name' '
+	test refs/remotes/origin/master = "$(full_name @{Upstream})"
+'
+
 test_expect_success 'my-side@{upstream} resolves to correct full name' '
 	test refs/remotes/origin/side = "$(full_name my-side@{u})"
 '
-- 
1.7.6.448.gc83e3.dirty

Re: [PATCH] rev-parse: Allow @{U} as a synonym for @{u}

[Junio C Hamano]

Conrad Irwin <conrad.irwin@gmail.com> writes:

> This facilitates specifying the upstream of a branch if you have
> difficulty synchronising your shift-key and other characters, if you
> just want to SHOUT at git, or if you're expecting consistency with
> @{1DAY}.

> +test_expect_success '@{U} resolves to correct full name' '
> +	test refs/remotes/origin/master = "$(full_name @{U})"
> +'
> +
> +test_expect_success '@{Upstream} resolves to correct full name' '
> +	test refs/remotes/origin/master = "$(full_name @{Upstream})"
> +'
> +
>  test_expect_success 'my-side@{upstream} resolves to correct full name' '
>  	test refs/remotes/origin/side = "$(full_name my-side@{u})"
>  '

Even though I sometimes use @{upstream} these days to keep track of
origins of various topic branches (some are fixes and fork from maint
while others are features and fork from master), I never felt a need for
@{U} or @{uPStreAM} myself, so as a new feature, this change is a "Meh"
for me personally.

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".

Letting u/upstream spelled case-insensitively does improve consistency
among the above, but at the same time if we ever wanted to enhance @{...}
notation even further in the future, we are restricted to a payload that
is case insensitive to retain the consistency.

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 hate to declare that we will never support such a feature with this
change, but at the same time, I do not think I would need such a feature
that often. But for that matter, I do not think I would miss @{UpStREAM},
either, and that takes me back to "Meh" for this change.

What do people think?

Re: [PATCH] rev-parse: Allow @{U} as a synonym for @{u}

[Nguyen Thai Ngoc Duy]

On Thu, Aug 18, 2011 at 5:53 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Letting u/upstream spelled case-insensitively does improve consistency
> among the above, but at the same time if we ever wanted to enhance @{...}
> notation even further in the future, we are restricted to a payload that
> is case insensitive to retain the consistency.
>
> 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 hate to declare that we will never support such a feature with this
> change, but at the same time, I do not think I would need such a feature
> that often. But for that matter, I do not think I would miss @{UpStREAM},
> either, and that takes me back to "Meh" for this change.
>
> What do people think?

The itch is probably because people have to release shift, then press
shift again to type "@{u}". How about allow case insensitive match if
there's only _one_ letter inside @{}?

That would solve the shift problem while leaving door for @{...} extension.
-- 
Duy

Re: [PATCH] rev-parse: Allow @{U} as a synonym for @{u}

[Michael J Gruber]

Nguyen Thai Ngoc Duy venit, vidit, dixit 18.08.2011 03:53:
> On Thu, Aug 18, 2011 at 5:53 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Letting u/upstream spelled case-insensitively does improve consistency
>> among the above, but at the same time if we ever wanted to enhance @{...}
>> notation even further in the future, we are restricted to a payload that
>> is case insensitive to retain the consistency.
>>
>> 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 hate to declare that we will never support such a feature with this
>> change, but at the same time, I do not think I would need such a feature
>> that often. But for that matter, I do not think I would miss @{UpStREAM},
>> either, and that takes me back to "Meh" for this change.
>>
>> What do people think?
> 
> The itch is probably because people have to release shift, then press
> shift again to type "@{u}". How about allow case insensitive match if
> there's only _one_ letter inside @{}?
> 
> That would solve the shift problem while leaving door for @{...} extension.

Well, this patch is actually specific to a particular keyboard layout!
It improves things only for a layout where you get @ and { using a shift
key.

For a german keyboard layout, you get @{u} from

hold AltGr (Meta)
press q
press 7
release AltGr
press u
hold AltGr
press 0

For me, an improvement would be to have the alias

@{↓}

for @{u} so that I can hold AltGr throughout and press q7u0. Which would
be very nice, pictorially :)

In general git could benefit from a rev alias mechanism. This idea has
come up several times, but in order to be really useful, we would need
that to be more general than textual replacements and allow for macro
like replacements such as

git config revalias.new "\1@{1}..\1"

to be used as, say

git log @{new(origin/next)}

after a fetch. (No, I'm not suggesting that specific syntax here.)

As a simpler case, a user could tailor to her keyboard layout with

git config revalias.↓ u

but for obvious reasons

git config revalias.U u

won't work.

So, maybe we could make the key part of a special revspec case
insensitive (just like config variable names) but still have a possible
payload (parameter) be case sensitive (just like config variable values)?

Michael

Re: [PATCH] rev-parse: Allow @{U} as a synonym for @{u}

[Nguyen Thai Ngoc Duy]

On Thu, Aug 18, 2011 at 2:15 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> For a german keyboard layout, you get @{u} from
>
> hold AltGr (Meta)
> press q
> press 7
> release AltGr
> press u
> hold AltGr
> press 0
>
> For me, an improvement would be to have the alias
>
> @{↓}

While it's convenient to type, the output now looks strange. If you do
a screencast, or someone is watching you, they may not understand what
that syntax is.

Also..

> As a simpler case, a user could tailor to her keyboard layout with
>
> git config revalias.↓ u

We may also have encoding issue here. What if config file is in utf-8,
but the console is not?

So I don't we should go this way. There may be a better way to deal
with different keyboard layouts.

> Well, this patch is actually specific to a particular keyboard layout!
> It improves things only for a layout where you get @ and { using a shift
> key.

Fully agreed. While it does not help non en-US keyboards, it does not
cause any harm (jealousy is not classified as harm to me, rather
motivation ;).
-- 
Duy

Re: [PATCH] rev-parse: Allow @{U} as a synonym for @{u}

[Michael J Gruber]

Nguyen Thai Ngoc Duy venit, vidit, dixit 18.08.2011 10:54:
> On Thu, Aug 18, 2011 at 2:15 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> For a german keyboard layout, you get @{u} from
>>
>> hold AltGr (Meta)
>> press q
>> press 7
>> release AltGr
>> press u
>> hold AltGr
>> press 0
>>
>> For me, an improvement would be to have the alias
>>
>> @{↓}
> 
> While it's convenient to type, the output now looks strange. If you do
> a screencast, or someone is watching you, they may not understand what
> that syntax is.

just like with any shell or git alias.

> 
> Also..
> 
>> As a simpler case, a user could tailor to her keyboard layout with
>>
>> git config revalias.↓ u
> 
> We may also have encoding issue here. What if config file is in utf-8,
> but the console is not?

It's a user setting, tailored for the user's environment.

> So I don't we should go this way. There may be a better way to deal
> with different keyboard layouts.
> 
>> Well, this patch is actually specific to a particular keyboard layout!
>> It improves things only for a layout where you get @ and { using a shift
>> key.
> 
> Fully agreed. While it does not help non en-US keyboards, it does not
> cause any harm (jealousy is not classified as harm to me, rather
> motivation ;).

If you sell it as

"rev key is like a config key, so make it case insensitive. As a side
effect, it helps certain keyboard layouts and does not harm others."

it may fair a better chance ;)

I guess this should apply to rev^{<type>} as well, then.

Michael

Re: [PATCH] rev-parse: Allow @{U} as a synonym for @{u}

[Conrad Irwin]

On Wed, Aug 17, 2011 at 3:53 PM, Junio C Hamano <gitster@pobox.com> 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@drmicha.warpmail.net> 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