Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Jeff King [off-list ref] writes:

On Thu, Mar 19, 2009 at 05:40:29PM -0700, Shawn O. Pearce wrote:

quoted

So yea, you can create a branch named "foo@{1}".

But you can't actually refer to it:

  $ git branch foo@{1}
  $ git show foo@{1} --
  fatal: bad revision 'foo@{1}'

which implies that nobody is actually using it for anything.

I think you are right.  It is just "git branch" and perhaps "git
update-ref" are too loose in enforcing what can be created.

Hi,

On Thu, 19 Mar 2009, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

On Thu, Mar 19, 2009 at 05:40:29PM -0700, Shawn O. Pearce wrote:

quoted

So yea, you can create a branch named "foo@{1}".

But you can't actually refer to it:

  $ git branch foo@{1}
  $ git show foo@{1} --
  fatal: bad revision 'foo@{1}'

which implies that nobody is actually using it for anything.

I think you are right.  It is just "git branch" and perhaps "git
update-ref" are too loose in enforcing what can be created.

"git branch" I agree with, but not "git update-ref".  As plumbing, the 
latter should be much more allowing, feeding rope aplenty (but also 
allowing cool tricks we do not think about yet).

Ciao,
Dscho

Hi!

On Fri, Mar 20, 2009 at 10:30:29AM +0100, Johannes Schindelin wrote:

On Thu, 19 Mar 2009, Junio C Hamano wrote:

quoted

I think you are right.  It is just "git branch" and perhaps "git
update-ref" are too loose in enforcing what can be created.

"git branch" I agree with, but not "git update-ref".  As plumbing, the 
latter should be much more allowing, feeding rope aplenty (but also 
allowing cool tricks we do not think about yet).

We shouldn't allow creating insane ref names even with update-ref. That
way porcelains cannot rely on update-ref to sanity check the user's
crap. At most, maybe you might want to bypass this check with some force
switch, though I really can't quite imagine why.

-- 
				Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr

Hi,

On Fri, 20 Mar 2009, Petr Baudis wrote:

On Fri, Mar 20, 2009 at 10:30:29AM +0100, Johannes Schindelin wrote:

quoted

On Thu, 19 Mar 2009, Junio C Hamano wrote:

quoted

I think you are right.  It is just "git branch" and perhaps "git
update-ref" are too loose in enforcing what can be created.

"git branch" I agree with, but not "git update-ref".  As plumbing, the 
latter should be much more allowing, feeding rope aplenty (but also 
allowing cool tricks we do not think about yet).

We shouldn't allow creating insane ref names even with update-ref. That
way porcelains cannot rely on update-ref to sanity check the user's
crap. At most, maybe you might want to bypass this check with some force
switch, though I really can't quite imagine why.

You really cannot imagine?  You, the author of filter-branch?  People _do_ 
have fscked-up repositories, but they get really angry when they cannot 
use rebase or filter-branch on them.

Ciao,
Dscho

On Fri, Mar 20, 2009 at 12:46:19PM +0100, Johannes Schindelin wrote:

Hi,

On Fri, 20 Mar 2009, Petr Baudis wrote:

quoted

On Fri, Mar 20, 2009 at 10:30:29AM +0100, Johannes Schindelin wrote:

quoted

On Thu, 19 Mar 2009, Junio C Hamano wrote:

quoted

I think you are right.  It is just "git branch" and perhaps "git
update-ref" are too loose in enforcing what can be created.

"git branch" I agree with, but not "git update-ref".  As plumbing, the 
latter should be much more allowing, feeding rope aplenty (but also 
allowing cool tricks we do not think about yet).

We shouldn't allow creating insane ref names even with update-ref. That
way porcelains cannot rely on update-ref to sanity check the user's
crap. At most, maybe you might want to bypass this check with some force
switch, though I really can't quite imagine why.

You really cannot imagine?  You, the author of filter-branch?  People _do_ 
have fscked-up repositories, but they get really angry when they cannot 
use rebase or filter-branch on them.

They can rename the ref as the first step of a cleanup, can't they?

-- 
				Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr

Hi,

On Fri, 20 Mar 2009, Petr Baudis wrote:

On Fri, Mar 20, 2009 at 12:46:19PM +0100, Johannes Schindelin wrote:

quoted

On Fri, 20 Mar 2009, Petr Baudis wrote:

quoted

On Fri, Mar 20, 2009 at 10:30:29AM +0100, Johannes Schindelin wrote:

quoted

On Thu, 19 Mar 2009, Junio C Hamano wrote:

quoted

I think you are right.  It is just "git branch" and perhaps "git
update-ref" are too loose in enforcing what can be created.

"git branch" I agree with, but not "git update-ref".  As plumbing, the 
latter should be much more allowing, feeding rope aplenty (but also 
allowing cool tricks we do not think about yet).

We shouldn't allow creating insane ref names even with update-ref. That
way porcelains cannot rely on update-ref to sanity check the user's
crap. At most, maybe you might want to bypass this check with some force
switch, though I really can't quite imagine why.

You really cannot imagine?  You, the author of filter-branch?  People _do_ 
have fscked-up repositories, but they get really angry when they cannot 
use rebase or filter-branch on them.

They can rename the ref as the first step of a cleanup, can't they?

Well, of course, we can make life hard on everybody.  That is quite 
possible.

But then, we can be nice, and at the same time fix the problem _properly_.

IMHO a _warning_ should be the best thing.

But all this does not solve _my_ problem: I'd like something as easy to 
write as %next, but as unlikely to be used in existing refs as @{..}.

Ciao,
Dscho

Johannes Schindelin venit, vidit, dixit 20.03.2009 12:57:

Hi,

On Fri, 20 Mar 2009, Petr Baudis wrote:

quoted

On Fri, Mar 20, 2009 at 12:46:19PM +0100, Johannes Schindelin wrote:

quoted

On Fri, 20 Mar 2009, Petr Baudis wrote:

quoted

On Fri, Mar 20, 2009 at 10:30:29AM +0100, Johannes Schindelin wrote:

quoted

On Thu, 19 Mar 2009, Junio C Hamano wrote:

quoted

I think you are right.  It is just "git branch" and perhaps "git
update-ref" are too loose in enforcing what can be created.

"git branch" I agree with, but not "git update-ref".  As plumbing, the 
latter should be much more allowing, feeding rope aplenty (but also 
allowing cool tricks we do not think about yet).

We shouldn't allow creating insane ref names even with update-ref. That
way porcelains cannot rely on update-ref to sanity check the user's
crap. At most, maybe you might want to bypass this check with some force
switch, though I really can't quite imagine why.

You really cannot imagine?  You, the author of filter-branch?  People _do_ 
have fscked-up repositories, but they get really angry when they cannot 
use rebase or filter-branch on them.

They can rename the ref as the first step of a cleanup, can't they?

Well, of course, we can make life hard on everybody.  That is quite 
possible.

But then, we can be nice, and at the same time fix the problem _properly_.

IMHO a _warning_ should be the best thing.

But all this does not solve _my_ problem: I'd like something as easy to 
write as %next, but as unlikely to be used in existing refs as @{..}.

Do we have ^ as a prefix yet?
Neither the suffix (commit^) nor the infix (commit^{type}) allow an
empty commit (for HEAD) - which might be nice, though. So, ^ as a prefix
is free, even without any specifier after.

Also, I don't think people would use @@ much in branch names.

Michael

Hi,

On Fri, 20 Mar 2009, Michael J Gruber wrote:

Do we have ^ as a prefix yet?

Yes, it means "not".  IOW '^bla blub' is the same as 'bla..blub'.

Also, I don't think people would use @@ much in branch names.

Whoa...

Ciao,
Dscho

Johannes Schindelin venit, vidit, dixit 20.03.2009 16:01:

Hi,

On Fri, 20 Mar 2009, Michael J Gruber wrote:

quoted

Do we have ^ as a prefix yet?

Yes, it means "not".  IOW '^bla blub' is the same as 'bla..blub'.

Oh yes, I forgot. commit specifiers and ranges are in different sections
in git-rev-parse.1.

quoted

Also, I don't think people would use @@ much in branch names.

Whoa...

We already have ^! and ^@ (I didn't know).

While someone may have a branch like "@junio" I think doubled special
characters are uncommon. Except for that topic branch /&$%$%§$%&/) for a
really nasty bug.

Of course, if @@ refers to a tracked branch which follows another
branch, then @@@@...

Michael

Petr Baudis [off-list ref] writes:

quoted

"git branch" I agree with, but not "git update-ref".  As plumbing, the 
latter should be much more allowing, feeding rope aplenty (but also 
allowing cool tricks we do not think about yet).

We shouldn't allow creating insane ref names even with update-ref. That
way porcelains cannot rely on update-ref to sanity check the user's
crap. At most, maybe you might want to bypass this check with some force
switch, though I really can't quite imagine why.

That's all nice and clean in theory, but it was more or less the same
reasoning as what was behind the tightening not to allow anything but
refs/heads pointed by HEAD, but you know what fell out of it.  "Insane"
and "crap" are in the eye of the beholder.

On Fri, 20 Mar 2009, Junio C Hamano wrote:

Petr Baudis [off-list ref] writes:

quoted

quoted

"git branch" I agree with, but not "git update-ref".  As plumbing, the 
latter should be much more allowing, feeding rope aplenty (but also 
allowing cool tricks we do not think about yet).

We shouldn't allow creating insane ref names even with update-ref. That
way porcelains cannot rely on update-ref to sanity check the user's
crap. At most, maybe you might want to bypass this check with some force
switch, though I really can't quite imagine why.

That's all nice and clean in theory, but it was more or less the same
reasoning as what was behind the tightening not to allow anything but
refs/heads pointed by HEAD, but you know what fell out of it.  "Insane"
and "crap" are in the eye of the beholder.

I think there's no possible use to being able to use update-ref to create 
a ref that rev-parse can't be made to read. I think people will want to do 
all sorts of things that are insane (I'd personally like some refs with 
the basename "..."), but they're only likely to do insane things that 
happen to work, rather than insane things that aren't prevented but still 
don't work.

	-Daniel
*This .sig left intentionally blank*

Hi,

On Fri, 20 Mar 2009, Daniel Barkalow wrote:

On Fri, 20 Mar 2009, Junio C Hamano wrote:

quoted

Petr Baudis [off-list ref] writes:

quoted

quoted

"git branch" I agree with, but not "git update-ref".  As plumbing, 
the latter should be much more allowing, feeding rope aplenty (but 
also allowing cool tricks we do not think about yet).

We shouldn't allow creating insane ref names even with update-ref. 
That way porcelains cannot rely on update-ref to sanity check the 
user's crap. At most, maybe you might want to bypass this check with 
some force switch, though I really can't quite imagine why.

That's all nice and clean in theory, but it was more or less the same 
reasoning as what was behind the tightening not to allow anything but 
refs/heads pointed by HEAD, but you know what fell out of it.  
"Insane" and "crap" are in the eye of the beholder.

I think there's no possible use to being able to use update-ref to 
create a ref that rev-parse can't be made to read. I think people will 
want to do all sorts of things that are insane (I'd personally like some 
refs with the basename "..."), but they're only likely to do insane 
things that happen to work, rather than insane things that aren't 
prevented but still don't work.

Of course, you are forgetting that rev-parse may well have been able to 
grok such a ref at some stage.

And at that stage, it becomes not a user error, but a _huge_ mistake by 
us, the Git developers.

Don't blame the user 
(http://www.schneier.com/blog/archives/2009/03/it_security_bla.html).

Ciao,
Dscho