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

From: Mark Levedahl <mlevedahl@gmail.com>
Date: Dec 3, 2014, 11:30 UTC
Message-ID: <547EF46F.3000007@gmail.com>
In-Reply-To: <xmqq4mtem029.fsf@gitster.dls.corp.google.com>

On 12/02/2014 12:30 PM, Junio C Hamano wrote:

Show 14 quoted lines

> 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