Re: [PATCH 24/34] checkout: reject if the branch is already checked out elsewhere

[Mark Levedahl <mlevedahl@gmail.com>]

On 12/02/2014 12:30 PM, Junio C Hamano wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> FWIW git-branch usually can show the original branch of detached head
>> (must not always). I don't think we have a plumbing equivalent for it
>> though. People can "tail -1 $GIT_DIR/logs/HEAD| sed .." but that seems
>> hacky.
> @{-1}, i.e. "the last branch I checked out"?
>
>> I do like "read-only" ref concept where we can keep ref name
>> (especially tags) in HEAD until the next commit. But it didn't go
>> anywhere
> Remind me.  That sounds somewhat interesting.
>
>
I think these ideas support solutions more complicated than the 
"problem" trying to be solved. Consider a use case: multiple algorithms, 
each a different branch in one repository, any of which can be used to 
analyze the same kinds of data. We also have multiple data sets, each a 
separate branch in a other repository. For development / test / analysis 
it is necessary to have multiple checked out pairs (algorithm + data) on 
the same machine to allow comparison / debugging in place of different 
combinations. Assume one algorithm, multiple data sets are checked out 
and being worked on.

With new-workdir, or Duy's approach with --ignore-other-checkouts, all 
are checked out normally in git, git-branch, git-status, git log all 
work normally. If a change needs to be made that affects the branch in 
more than one checked out repository, once done the other copies are out 
of date. It does not matter which instance is modified, once committed 
the change is already visible in all others, and "git reset --hard" in 
all the others completes the process. This is not difficult to 
understand, requires no new code, no special methods.

Consider the alternatives:
a) Use separate complete repositories + work trees: now the new branch 
needs to be broadcast to all using fetch or pull, and as the change 
might have been an amend, fetch + reset --hard may be required. This is 
not "simpler" to implement in practice, nor do I find it easier to 
explain. Note also that if using push, it is possible to force push into 
the current branch of the other copies, with receive.denyCurrentBranch = 
false, resulting in exactly the same situation as above using 
new-workdir (checked out code not matching the ref).

b) Use Duy's approach without --ignore-other-checkouts. First, you have 
to find the copy that is not on a detached HEAD, detach the HEAD their, 
then go back to the copy where the problem is found, attach the HEAD in 
that one, and make the change. Then go back and do git reset --hard 
$branch in the others.

I just don't see how these alternatives are in the end any simpler to 
use or explain.


Mark