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

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