Re: [PATCH/RFC] Introduce git submodule add|update --attach

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2014/1/3 Francesco Pretto <ceztko@xxxxxxxxx>:
> Concluding, my point is that at the current state submodules in git
> seem to be flawed because of the inconsistent HEAD state between "add"
> and "update" users. With my patch applied the attached HEAD behavior
> would be fully supported. At some point "git submodule add" (without
> the "--attached" switch) could be also modified to produce a detached
> HEAD by default, removing any remaining inconsistency.

Junio, please let me amend this affirmation as it's inaccurate.
According to the current *upstream* features this should the supported
use case for submodules:
- there's a maintainer "add" user that adds the submodule. He will
need to track the upstream submodule revision sha1, so he will clone
the repository with an *attached* HEAD;
- there's a developer "update" use that just clone the submodule
repository and track the sha1 decided by the maintainer "add" user. He
won't need to track upstream submodule revision sha1 so cloning the
repository with a *detached* HEAD. Subsequent "merge" or "rebase"
update operations will keep the HEAD detached.

We should *not* modify/break this default workflow in any way.

The current documentation seems to be misleading when saying that
"This [the update command] will make the submodules HEAD be detached
**unless** --rebase or --merge is specified", as it seems to imply
that the update operation will result in a repository with the HEAD
attached. The repository will be indeed updated merging changes, but
the HEAD will stay detached.

Now, the use case I would like git to support is this:
- there's a maintainer "add" user that adds the submodule. He won't
track the upstream submodule revision sha1, so
"submodule.<module>.ignore" will be set to "all". He will still clone
the repository with an *attached* HEAD;
- there's a developer "update" user. He will clone the submodule
repository with an *attached* HEAD. Subsequent "merge" or "rebase"
update operations will keep the HEAD attached.

To fully support this workflow in my patch I want to:
- introduce a "submodule.<module>.attach" property so "update" users
will clone the submodule repository with an attached HEAD;
- introduce "--attach|--dettach" switches to "update" commmant to
eventually override "submodule.<module>.attach" property value in the
command line;
- introduce "--attach" (but better rename it to "--keep-attached" or
something else) switch to the "add" operation. This "--keep-attached"
will:
    * set "submodule.<module>.attach" to true;
    * set "submodule.<module>.ignore" to all.

Being the workflow complementary, and the behavior fully optional, I
think the proposed feature should be solid. Give me some time to
produce an improved patch and let see if I can convince you.

Regards,
Francesco
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]