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]

 



Johannes Schindelin wrote:
> On Tue, 6 Oct 2009, Euguess@xxxxxxxxx wrote:
> > in case if you didn't do that and you try to checkout you will end up 
> > having detached HEAD which is quite scary;) for non-experienced user and 
> > as i see might lead to some unnecessary questions in this list or on IRC 
> > channel...
[...]
> One thing one might add for the technically inclined folks (i.e. those who 
> need to implement, and to see that Git is in dear need of some 
> user-friendliness first): "git checkout" is a porcelain (i.e. a program 
> meant for end-user consumption), and as such should not have a problem to 
> react to isatty(0) (i.e. "is the input coming directly from the 
> console?").

Sadly git-checkout seems to be stuck between being declared a
porcelain, but at the same time being an extremely important command
for scripts all over.  (There are probably others in the same place:
reset comes to mind.)

Your idea is also a backwards incompatible change, so we can just as
well implement the original suggestion and force scripts (or us) to
use some other means when they want to detach.  Say, why not just
invent an option along the lines of

  git checkout {-d|--detach} $ref

to make it explicit.  We have to resort to more arcane means to
*reliably* detach anyway, like 'git checkout master^0'.  Then in some
future release, git-checkout will start making DWIM branches if the -d
is not given.

And while we're there, --attach would be a nice complement to force
refs/heads/foo to attach.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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]