Re: Restoring detached HEADs after Git operations

[Stefan Beller <sbeller@google.com>]

On Mon, Jun 19, 2017 at 10:55 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> On Mon, Jun 19, 2017 at 2:52 AM, Patrick Lehmann
>> <Patrick.Lehmann@plc2.de> wrote:
>>> Hello Lars,
>>>
>>> for your questions:
>>>> If there are multiple branches with the same hash then your script would pick the first one. Can you imagine a situation where this would be a problem?
>>>
>>> I can't think of a good solution to resolve it automatically. Maybe a script could print that there are multiple possibilities and it choose the first branch in the list.
>>>
>>>
>>>> Plus, you are looking only at local branches. Wouldn't it make sense to look at remote branches, too?
>>>
>>> This is also related to restoring tags. If we go this way, we should have this priority list:
>>> - local branches
>>> - remote branches
>>
>> For remote branches you would create a local branch of the same name
>> (if such a branch would not exist, possibly setting it up to track that remote
>> branch)?
>>
>>> - tags
>>
>> as said in the other email and similar to remote branches, we'd not want to have
>> HEAD pointing to them directly but somehow have a local branch.
>
> Let's step back a bit.  We detach the HEAD for a good reason, no?

And the 'good reason' being that at the time git-submodule was written
we did not know what would be best, and having a detached HEAD
would be (a) easy to implement, and (b) removing one moving thing
from the whole construction, hence making it a bit safer,
(c) it sort of follows the mental model:

    the superproject said it had the submodule at X
        (and not at branch Y!)
    the submodule itself is a whole repo on its own
        (it doesn't need to be aware of the superproject)

so in this world detaching at X is the best we can do.

> Why is it a good idea to move them back on to a branch picked among
> multiple ones that all happen to be pointing at the same commit?

This (rhetorical?) question reads like 2 questions actually:
(a) "Why is it a good idea to move them back on to a branch?"
It makes working easier as the submodule is not detached,
but on a proper branch
(b) "picked among multiple ones that all ..."
I think this is a bad idea and we'd rather want to follow
some configuration instead of wild-guessing by Git.

> The user may build on a history of a submodule, and then may push
> the result out to a particular branch at the other side; that is
> when being on a named branch in the submodule becomes useful, but
> even then I do not think randomly picking one branch and be on it
> is a good thing to do.

so you provide one reason why it is useful, but then claiming it is
'not a good thing' (yet). Can you give a reason why this is a 'bad thing'?

> I would understand the workflow would go more like so:
>
>  - You do something at the superproject (e.g. create a new branch X
>    from an existing commit and check it out), which results in
>    submodules' HEADs getting detached at the commits bound to the
>    superproject's tree.

And here we'd want to discuss if we *really* want to detach the HEADs
or rather have a symbolic ref "following the superproject".

>  - Because you want to make changes to both submodules and the
>    superproject in a consistent way, you'd want to commit changes to
>    all of these repositories and the push the result out in an
>    atomic way.

Committing and pushing are different things. You should not care if
I commit atomically as you (in the general "upstream" sense)
cannot observe my local commits.

For pushing we would want to have an atomic push, but that is
not the scope of this discussion. (As a Gerrit user, we implemented
the submodule atomicity serverside, but in plain Git server you'd
not need the atomicity either:

    git commit -a -m "update submodule pointers"
    git submodule foreach git push
    git push

should be fine w.r.t. any non-atomic race condition.)

>  - Hence you tell "Hey, Git, I want all the submodules that I
>    modified to be on branch X" from the superproject.
>
>    - This may succeed in a submodule where X is a new name, or the
>      current tip of branch X is an ancestor of the detached HEAD.

so we'd allow fast forward for X. This seems arbitrary to me. I could
also say "If X exists I allow a merge to be made between old X and
the object name given by the superproject". (maybe as a config option)

>    - This may fail in a submodule where there is branch X that does
>      not want to move to the detached HEAD's state.  In this latter
>      case, the user needs to deal with the situation (perhaps the
>      old X is expendable; perhaps the HEAD's commit may need to be
>      merged to old X; perhaps there are other cases).

makes sense.

>
> though.