From: Junio C Hamano <hidden> Date: 2016-06-15 22:46:26
Johannes Schindelin [off-list ref] writes:
Often, it is quite interesting to inspect the branch tracked by a given
branch. This patch introduces a nice notation to get at the tracked
branch: '%<branch>' can be used to access that tracked branch.
A special shortcut '%' refers to the branch tracked by the current branch.
Suggested by Pasky.
Even if a branch name can legally start with a '%' sign, we can use the
special character '%' here, as you can always specify the full ref:
refs/heads/%my-branch (pointed out by doener on IRC).
That is not a good argument, as %<name> is (just like name@{-n} is) a
substitute way to spell the "name" of a branch, not just a random SHA-1,
and to some commands it makes a difference between <branchname> and
refs/heads/<branchname>. The latter is not giving the name of the branch,
but merely a commit object name.
An most obvious one is that "git checkout branchname" and "git checkout
refs/heads/branchname" behave differently. You cannot checkout a branch
called %master after this patch goes in.
Just be honest and say "You may have a branch whose name begins with a '%'
and you cannot refer to it anymore in certain contexts. Too bad. Don't
do it next time you create a new branch". I _can_ buy that argument.
It however asks for a sane escape hatch. You cannot "fix" such branch
names in most obvious ways (if you could, that would be a bug in this %
feature).
(1) git branch -m %master percent-master
We would end up renaming what master tracks to new name.
(2) git branch percent-master refs/heads/%master; git branch -d %master
The first part is a good try, but the latter deletes what master
tracks.
"git update-ref -d refs/heads/%master" needs to replace the second step of
the latter.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:46:26
Hi,
On Fri, 20 Mar 2009, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
Often, it is quite interesting to inspect the branch tracked by a given
branch. This patch introduces a nice notation to get at the tracked
branch: '%<branch>' can be used to access that tracked branch.
A special shortcut '%' refers to the branch tracked by the current branch.
Suggested by Pasky.
Even if a branch name can legally start with a '%' sign, we can use the
special character '%' here, as you can always specify the full ref:
refs/heads/%my-branch (pointed out by doener on IRC).
That is not a good argument, as %<name> is (just like name@{-n} is) a
substitute way to spell the "name" of a branch, not just a random SHA-1,
and to some commands it makes a difference between <branchname> and
refs/heads/<branchname>. The latter is not giving the name of the branch,
but merely a commit object name.
An most obvious one is that "git checkout branchname" and "git checkout
refs/heads/branchname" behave differently. You cannot checkout a branch
called %master after this patch goes in.
Just be honest and say "You may have a branch whose name begins with a '%'
and you cannot refer to it anymore in certain contexts. Too bad. Don't
do it next time you create a new branch". I _can_ buy that argument.
Be that as it may, at this point I kick the ball back to the interested
parties. I did my duty.
Ciao,
Dscho
An most obvious one is that "git checkout branchname" and "git checkout
refs/heads/branchname" behave differently. You cannot checkout a branch
called %master after this patch goes in.
Just be honest and say "You may have a branch whose name begins with a '%'
and you cannot refer to it anymore in certain contexts. Too bad. Don't
do it next time you create a new branch". I _can_ buy that argument.
It however asks for a sane escape hatch. You cannot "fix" such branch
names in most obvious ways (if you could, that would be a bug in this %
feature).
(1) git branch -m %master percent-master
We would end up renaming what master tracks to new name.
(2) git branch percent-master refs/heads/%master; git branch -d %master
The first part is a good try, but the latter deletes what master
tracks.
How about adding a generic escape hatch, that would cover this and
future extensions?
Let a ref that starts with a single quote be taken as given and not
processed. You have to escape it to get it past the shell, but that makes
it rather unlikely that anyone has used a name that starts with a quote -
and if they have you can still use this mechanism to rename it.
So now (1) above could be written:
git branch -m "'%master" percent-master
and other commands, such as
git branch -d "'%master"
or
git checkout "'%master"
would also do the right thing (i.e. use refs/heads/%master as a branch).
--
Julian
---
Stewie Griffin: [looking in the fridge for a drink] Soda... purple stuff... Sunny D, all right!
Heya,
On Sat, Mar 21, 2009 at 00:08, Julian Phillips [off-list ref] wrote:
git branch -m "'%master" percent-master
Which kinda defeats the purpose of having a short-and-easy-to-write
refname, no? "'%master" is not that easy to type, I at least get my
fingers mixed up in the "'% sequence. Perhaps we should reserve these
special characters now, and deprecate their use? Junio seemed to be
open to that (quoted below)...
Just be honest and say "You may have a branch whose name begins with a '%'
and you cannot refer to it anymore in certain contexts. Too bad. Don't
do it next time you create a new branch". I _can_ buy that argument.
Heya,
On Sat, Mar 21, 2009 at 00:08, Julian Phillips [off-list ref] wrote:
quoted
git branch -m "'%master" percent-master
Which kinda defeats the purpose of having a short-and-easy-to-write
refname, no? "'%master" is not that easy to type, I at least get my
fingers mixed up in the "'% sequence. Perhaps we should reserve these
special characters now, and deprecate their use? Junio seemed to be
open to that (quoted below)...
But it's not supposed to be easy to type ...
To use the new syntax you type %master only. What I was proposing was a
way to get at the branch that you had before the wizzy new feature was
added. Something you only do once to rename it - why waste an easy to
type sequence on that?
I agree that adding some more reserved characters is a reasonable way
forward - but I think a way should be provided for people who are
_already_ using those characters to rename their branches to something that
avoids those characters in a simple (but not necessarily easy to type)
way.
--
Julian
---
panic("%s: CORRUPTED BTREE OR SOMETHING", __FUNCTION__);
linux-2.6.6/fs/xfs/xfs_bmap.c
Heya,
On Sat, Mar 21, 2009 at 00:41, Julian Phillips [off-list ref] wrote:
To use the new syntax you type %master only. What I was proposing was a way
to get at the branch that you had before the wizzy new feature was added.
Something you only do once to rename it - why waste an easy to type
sequence on that?
Oooooh, sorry, I totally understood your suggestion the wrong way
around! In that case, I like it! :)
I agree that adding some more reserved characters is a reasonable way
forward - but I think a way should be provided for people who are _already_
using those characters to rename their branches to something that avoids
those characters in a simple (but not necessarily easy to type) way.
Your suggestion on how to escape the DWIMery sounds sane to me :).
--
Cheers,
Sverre Rabbelier
From: Andreas Gruenbacher <hidden> Date: 2016-06-15 22:46:26
On Saturday, 21 March 2009 0:08:42 Julian Phillips wrote:
How about adding a generic escape hatch, that would cover this and
future extensions?
Let a ref that starts with a single quote be taken as given and not
processed. You have to escape it to get it past the shell, but that makes
it rather unlikely that anyone has used a name that starts with a quote -
and if they have you can still use this mechanism to rename it.
To me the most obvious escape sequence would be \x for disabling whatever
special meaning x has (for non-alphabetic x). With quoting you likely
eventually end up needing \' in some cases anyway...
Andreas
From: Miles Bader <hidden> Date: 2016-06-15 22:46:26
Andreas Gruenbacher [off-list ref] writes:
To me the most obvious escape sequence would be \x for disabling whatever
special meaning x has (for non-alphabetic x). With quoting you likely
eventually end up needing \' in some cases anyway...
I think it's a good idea to _avoid_ using backslash as an escape when
possible -- the potential for confusion and screwups from multiple
layers all interpreting backslash should be familiar to most people
here... (single-quote suffers from the same problem a bit, but at least
it's not quite as overused as backslash)
-Miles
--
One of the lessons of history is that nothing is often a good thing to
do, and always a clever thing to say. -- Will Durant
On Saturday, 21 March 2009 0:08:42 Julian Phillips wrote:
quoted
How about adding a generic escape hatch, that would cover this and
future extensions?
Let a ref that starts with a single quote be taken as given and not
processed. You have to escape it to get it past the shell, but that makes
it rather unlikely that anyone has used a name that starts with a quote -
and if they have you can still use this mechanism to rename it.
To me the most obvious escape sequence would be \x for disabling whatever
special meaning x has (for non-alphabetic x). With quoting you likely
eventually end up needing \' in some cases anyway...
Except that \ is the escape character for the shell too ... and that can
get very confusing. Haven't you ever spent too long trying to figure out
how many \s you needed to get the command to work properly?
--
Julian
---
I'm still waiting for the advent of the computer science groupie.
On Saturday, 21 March 2009 0:08:42 Julian Phillips wrote:
quoted
How about adding a generic escape hatch, that would cover this and
future extensions?
Let a ref that starts with a single quote be taken as given and not
processed. You have to escape it to get it past the shell, but that
makes
it rather unlikely that anyone has used a name that starts with a quote
-
and if they have you can still use this mechanism to rename it.
To me the most obvious escape sequence would be \x for disabling whatever
special meaning x has (for non-alphabetic x). With quoting you likely
eventually end up needing \' in some cases anyway...
Except that \ is the escape character for the shell too ... and that can get
very confusing. Haven't you ever spent too long trying to figure out how
many \s you needed to get the command to work properly?
Having said that, the actual character used doesn't really matter. That's
just a what colour do you want your shed type detail ...
--
Julian
---
BOFH Excuse #118:
the router thinks its a printer.