Re: [PATCH] branch: Forbid to create local branches with confusing names

[Ingo Rohloff <ingo.rohloff@lauterbach.com>]

Hello Johannes,

On Wed, 6 Nov 2019 23:15:44 +0100 (CET)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

> Hi Ingo,
> 
> On Wed, 6 Nov 2019, Ingo Rohloff wrote:
> 
> > Without this patch, git allows to do something like this:  
> 
> Maybe start the patch with a description of the problem it tries to
> solve? In other words, I would have appreciated a first paragraph that
> starts with "Many Git users ...".

That's actually one of the problems: 
It's not clear what exactly the problem is :-).

After thinking about it more: The minimal goal I can think of is to make sure 
that if you use
   git log refs/<something>

you will never get a 
   warning: refname '...' is ambiguous

Rationale behind that: If even "refs/<something>" gives you this warning, 
then you might be in a lot of trouble. It means even giving a "full" refname 
is not enough to resolve ambiguities.
I think this is bad, because it means it might be hard to get out of this 
situation, because you might get the "ambiguous" warnings when you try to 
get rid of the offending refnames.


> 
> A lot of this text should probably go into the commit message itself,
> possibly with accompanying Message-IDs or even public-inbox URLs right
> away.

I did read "Documentation/SubmittingPatches". There it says:

    Try to make sure your explanation can be understood
    without external resources. Instead of giving a URL to a 
    mailing list archive, summarize the relevant points of 
    the discussion.

so that's what I tried to do.

> 
> A more common problem for me, personally, is when I manage to fool
> myself by creating a local branch like `origin/master`. Clearly, I want
> to refer to the remote-tracking branch, but by mistake I create a local
> branch that now conflicts with the (short) name of the remote-tracking
> branch.
> 
> To remedy this, you would not only have to ensure that `create_branch()`
> verifies that the branch name does not have a `<remote-name>/` prefix
> where `<remote-name>` refers to a valid remote, but you would also need
> a corresponding patch that teaches `git add remote <nick> <url>` to
> verify that no local branch starts with `<nick>/`.
> 
> What do you think?
> 

I agree: When I first started to use git, I was quite surprised that this
"double naming" is allowed.

But I also think, this is for another patch series; you probably need to 
honor "--force", or even add a git configuration option to allow this
anyway.

I am able to imagine that people intentionally set up a local branch
called "refs/heads/repoX/master" which tracks "refs/remotes/repoX/master".

For me this sounds like an unnecessary complication (because now you always
have to use the "long" refname), but if you put some software on top of git, 
I can imagine that this might make a lot of sense...

I am not enough of a git wizard to fully grasp the implications here.

so long
  Ingo