Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, 6 Oct 2009, Thomas Rast wrote:

> Jeff King wrote:
> > On Mon, Oct 05, 2009 at 11:17:09PM +0200, Johannes Schindelin wrote:
> > 
> > > > $ git checkout next
> > > > error: pathspec 'next' did not match any file(s) known to git.
> > > 
> > > Actually, we should really think long and hard why we should not 
> > > automatically check out the local branch "next" in that case.  I mean, 
> > > really long and hard, and making sure to take user-friendliness into 
> > > account at least as much as simplicity of implementation.
> > 
> > Some devil's advocate questions:
> > 
> >   1. How do we find "origin/next" given "next"? What are the exact
> >      lookup rules? Do they cover every case? Do they avoid surprising
> >      the user?
> > 
> >   2. What do we do if our lookup is ambiguous (e.g., "origin/next" and
> >      "foobar/next" both exist)?
> > 
> >   3. If our lookup does have ambiguities or corner cases, is it better
> >      to simply be suggesting to the user, rather than proceeding with an
> >      action?
> 
> If I may add another:
> 
> 4. Are there any (scripted?) use-cases where git-checkout should fail
>    because it was given an invalid branch name?
> 
> The following gives a hint, though they could of course be fixed and
> the ^0 case doesn't really count:
> 
>   $ git grep 'git checkout .*||' -- "*.sh"
>   git-bisect.sh:          git checkout "$start_head" -- || exit
>   git-rebase--interactive.sh:                     output git checkout $first_parent 2> /dev/null ||
>   git-rebase--interactive.sh:                     output git checkout "$1" ||
>   git-rebase.sh:git checkout -q "$onto^0" || die "could not detach HEAD"
>   t/t2007-checkout-symlink.sh:git checkout -f master || exit

Actually, in said cases (with exception of the test case, which should be 
fine, however, having no remote branches), I would expect the user to be 
grateful if the DWIMery would happen.

I have to clarify something here: I am not proposing to include a patch 
that does that DWIMery.  We need to discuss the downsides and upsides 
until we can be pretty certain that it does more good than harm.

Unfortunately, this list does not seem to be very inviting to pure users, 
who I hoped would chime in on this issue.

Ciao,
Dscho

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]