Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Sun, 22 Jul 2007, Julian Phillips wrote:

> On Sun, 22 Jul 2007, Johannes Schindelin wrote:
> 
> > On Sun, 22 Jul 2007, Julian Phillips wrote:
> > 
> > > On Sun, 22 Jul 2007, Johannes Schindelin wrote:
> > > 
> > > > 	IMHO this is a better syntax than what is in contrib/, and "git
> > > > 	branch" is probably the right place for such a thing, from a
> > > > 	user's perspective.
> > > 
> > > Surely checkout would make more sense than branch?  You are effectively
> > > checking out into a new directory ... also you may want to get an
> > > existing branch (certainly most of my usage of new-workdir is checking
> > > out existing branches, e.g. to look at - as in build and play with - an
> > > interesting branch that someone else has pushed out).
> > 
> > My rationale here was:
> > 
> > - to make sure that the user cannot check out the same branch as in the
> >  current repo, _or some other workdir of it_, and
> 
> Since you can checkout any branch you like once you have the workdir, 
> this is really an artificial limitation - you are protected when you 
> create the workdir, but not after.

Well, it is not really an artificial limitation.  IMHO it is much more 
likely that you keep in mind what you should not do, when you have to work 
around such a limitation if you really want to do.

> If you want to have a workdir for an exisiting branch then you have to create
> a new one, and then switch it over.  That seems like a really big usability
> wart to me ... certainly it would make the option pretty much useless to me.
> My original motivation for the new-workdir script was to give me the ability
> to flatten out branches from a single repo for when I'm working on multiple
> branches at the same time.

Nowadays, we have separate remotes layout by default.  (Indeed, you cannot 
even disable it, as I found out recently).  Which means that you already 
have to branch off your local branch.  So the consequences are lesser.

> > - to have finer grained lock control, as well as respecting has_symlinks.
> 
> Not really sure what this means, since I am too tired to have read the 
> actual patch - is it referring to the fact that checkout is shell rather 
> than C?  If so, surely that is not really a good justification for 
> putting the option in the "wrong" command?

Well, I am really not interested in shooting myself in the foot, and 
having that option in checkout would make that much more likely.  So I 
really, really want to have this in git-branch.

Once git-checkout is builtin, we can still come back and add this option 
to git-checkout (with a big fat red warning, to be sure); it is not like 
we have git-branch and git-checkout functionality well separated...

Ciao,
Dscho