From: Andreas Krey <a.krey@gmx.de>
Date: Wed, 05 Oct 2011 20:00:43 GMT
Subject: Re: [RFC/PATCH] Add multiple workdir support to branch/checkout
Message-ID: <20111005200043.GA32732@inner.h.iocl.org>
In-Reply-To: <CAG+J_Dzg2D+vmFRfLX01S2k98YZQBE0FFv76VAyPnXdetyWADQ@mail.gmail.com>

On Wed, 05 Oct 2011 15:11:30 +0000, Jay Soffian wrote:
...
> >  - Error out (or warn if forced) upon any attempt to update the tip of a
> >   branch that is checked out in more than one place; and
> 
> I think that's a worse user experience. "Sorry, can't commit your
> changes because you've checked out this branch elsewhere."

This is actually pretty much the same as "you can't push into the
currently checked-out branch".

I do come from CVS where multiple checkouts of the same branch are obviously
common, but the semantics are different. git would need to allow to be in
a detached state but still have a notion of a 'current' branch to mimic that;
this tentative 'current' branch being what we need to merge or rebase onto later.
Just thinking.

It may actually be logical to put the other workdirs into detached state when
the branch they are on is committed into; however, this is seriously confusing.

> Now the
> user's choices are:
> 
> 1. commit --force (and thus confusing the other workdirs)
> 2. checkout -b new_branch && commit
> 
> Both of which I think are worse than preventing the checkout in the first place.

Hmm. You mean forcing the user to make a new branch *earlier* than at
commit time is better?

Andreas