Re: [PATCH] checkout --track: make up a sensible branch name if '-b' was omitted

Johannes Schindelin [off-list ref] writes:

On Sat, 9 Aug 2008, Junio C Hamano wrote:
...
At first, I liked the thoughts, but...

quoted

(1) You may not necessarily are used to --track, but may still want this
    done.  It might not be a bad idea to associate this "local dwimming"
    to creation of a new branch.  In other words, all of these:

    $ git checkout -b origin/next

This cannot be dwimmed, as it literally means "start a new branch called 
'origin/next' from HEAD".

Right.  Forget this part.

quoted

(2) If you work with somebody else, you might not want to have the name
    mapping to be "s|^[^/]*/||" (i.e. drop "origin/"):

    $ git remote add -f jeff $url_to_his_repository
    $ git checkout -b [--track] jeff-next jeff/next
    $ git checkout -b [--track] origin-next origin/next

As I said, I think you must not allow switching around the options -b and 
--track.

Oh, that was a typo.  "git checkout [--track] -b" was what I meant, but
the point was that with your patch "git checkout --track jeff/next" and
"git checkout --track origin/next" would create 'next' branch which will
not be useful for people who work with more than one repository.

Yes, you can of course explicitly name what you want to create with -b,
but that argument goes directly against the "usability enhancement" theme
of your patch.

Don't mistake this comment as "I oppose to the patch".  I was hoping
people who care, not necessarily you, might come up with a clean UI and
mechanism to let users affect how this dwimmery would work depending on
how the users want to work, by raising this point as something to ponder
on.

On Aug 9, 2008, at 11:11 PM, Junio C Hamano wrote:

quoted

quoted

(1) You may not necessarily are used to --track, but may still  
want this
   done.  It might not be a bad idea to associate this "local  
dwimming"
   to creation of a new branch.  In other words, all of these:

   $ git checkout -b origin/next

This cannot be dwimmed, as it literally means "start a new branch  
called
'origin/next' from HEAD".

Right.  Forget this part.

This is too bad. I often see people make mistakes like

	git checkout -b origin/master
or
	git checkout -b origin/master origin/master

which should be

	git checkout -b origin/master master

I think both forms should at least be an error if the remote branch  
"origin/master" already exists, as then suddenly they aren't reachable  
anymore by using "origin/master".

Changing the behaviour to mean "git checkout -b origin/master master"  
will change the meaning, but who uses -b with an existing remote  
branch anyway? I think the current behaviour leads to more confusion  
in every case and should at least error out ("Error: creating a local  
repository with the same name as the remote is not allowed") or do  
what it's meant to do, which is create a local repository with the  
trailing part.

Just my .02,

- Pieter

Hi,

On Sat, 9 Aug 2008, Pieter de Bie wrote:

Changing the behaviour to mean "git checkout -b origin/master master" 
will change the meaning, but who uses -b with an existing remote branch 
anyway?

FWIW I am totally opposed to this kind of reasoning.  I consider it sloppy 
to make assumptions that might or might not be true, and to force 
a change that might be convenient to you, but is likely to hurt others.

Besides, your suggestion completely breaks consistency.  If somebody asks 
to name a new branch "origin/master" (and "-b origin/master" is _just_ 
_that_), then it is not Git's job to fix the user's mistake.  Just like it 
is not Git's job to fix when somebody said "git commit", but meant "git 
push".

After all, I might _want_ to create a local branch "origin/master", and 
you would just break the valid assumption that "-b origin/master" would do 
that for me.

Hth,
Dscho

Hi,

On Sat, 9 Aug 2008, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

On Sat, 9 Aug 2008, Junio C Hamano wrote:
...

quoted

(2) If you work with somebody else, you might not want to have the name
    mapping to be "s|^[^/]*/||" (i.e. drop "origin/"):

    $ git remote add -f jeff $url_to_his_repository
    $ git checkout -b [--track] jeff-next jeff/next
    $ git checkout -b [--track] origin-next origin/next

As I said, I think you must not allow switching around the options -b 
and --track.

Oh, that was a typo.  "git checkout [--track] -b" was what I meant, but 
the point was that with your patch "git checkout --track jeff/next" and 
"git checkout --track origin/next" would create 'next' branch which will 
not be useful for people who work with more than one repository.

Yes, you can of course explicitly name what you want to create with -b, 
but that argument goes directly against the "usability enhancement" 
theme of your patch.

Not necessarily:

$ git checkout --track jeff/next
Switched to a new branch "next"

[do a lot of work, even on that 'next' branch]

[weeks, months or centuries later, decide to do something on origin/next]

$ git checkout --track origin/next
fatal: A branch named 'next' already exists.

[Ah! Slap your head, remembering that 'next' tracks jeff's 'next']
$ git branch -m next jeff-next
Branch: next renamed to jeff-next
$ git checkout --track -b origin-next origin/next


Concluding, I do not see how the DWIMing of the normal case impacts the 
non-normal case negatively.

Don't get me wrong.  I do not need that patch in git.git desperately.  
But if it is rejected, I want it to be rejected for reasons I understand.

Ciao,
Dscho