On Wed, Jan 08, 2014 at 03:12:44AM +0100, Francesco Pretto wrote:
> 2014/1/8 W. Trevor King :
> > Note that I've moved away from “submodule..branch
> > set means attached” towards “we should set per-superproject-branch
> > submodule..local-branch explicitly” [1].
>
> Honestly, I'm having an hard time to follow this thread.
I tried to refocus things (with a new subject) in this sub-thread.
Hopefully that helps make the discussion more linear ;).
> Also, you didn't update the patch.
I'm waiting [1] to see how the C-level checkout by Jens and Jonathan
progresses [2,3] before writing more code.
> If you were endorsed by someone (Junio, Heiko, ...) for the
> "submodule..local-branch" feature please show me where.
As far as I know, no-one else has endorsed this idea (yet :). Heiko
has expressed concern [4], but not convincingly enough (yet :) to win
me over ;).
> I somehow understand the point of the
> "submodule..local-branch" property, but I can't "see" the the
> workflow. Please, show me some hypothetical scripting example with
> as much complete as possible workflow (creation, developer update,
> mantainers creates feature branch, developer update, developer
> attach to another branch).
I've put this at the bottom of the message to avoid bothering the
tl;dr crowd, although they have probably long since tuned us out ;).
> Also, consider I proposed to support the attached HEAD path to
> reduce complexity and support a simpler use case for git
> submodules. I would be disappointed if the complexity is reduced in
> a way and augmented in another.
Agreed. I think we're all looking for the least-complex solution that
covers all (or most) reasonable workflows.
> > On Wed, Jan 08, 2014 at 01:17:49AM +0100, Francesco Pretto wrote:
> >> # Attach the submodule HEAD to .
> >> # Also set ".git/config" 'submodule..branch' to
> >> $ git submodule head -b --attach
> > [...]
> > I also prefer 'checkout' to 'head', because 'checkout'
> > already exists in non-submodule Git for switching between local
> > branches.
>
> I can agree with similarity to other git commands, but 'checkout'
> does not give me the idea of something that writes to ".git/config"
> or ".gitmodules".
Neither does 'head'. We have precedence in 'git submodule add' for
embracing and extending a core git command with additional .gitmodules
manipulation. I think it's easier to pick up the submodule jargon
when we add submodule-specific side-effects to submodule-specific
commands named after their core analogs than it would be if we pick
unique names for the submodule-specific commands.
> >> # Unset ".git/config" 'submodule..branch'
> >> # Also attach or detach the HEAD according to what is in ".gitmodules":
> >> # with Trevor's patch 'submodule..branch' set means attached,
> >> # unset means detached
> >> $ git submodule head --reset
> >
> > To me this reads “always detach HEAD” (because it unsets
> > submodule..branch, and submodule..branch unset means
> > detached).
>
> I disagree: this would remove only the value in ".git/config". If the
> value is till present in ".gitmodules", as I wrote above, the behavior
> of what is in the index should be respected as for the other
> properties. Also it gives a nice meaning to a switch like --reset :
> return to how it was before.
Ah, that makes more sense. I had confused .git/config with
“.gitmodules and .git/config”.
> >> NOTE: feature branch part!
> >>
> >> # Set ".gitmodules" 'submodule..branch' to
> >> $ git submodule head -b --attach --index
> >>
> >> # Unset ".gitmodules" 'submodule..branch'
> >> $ git submodule head --reset --index
> >> -
> >
> > These are just manipulating .gitmodules. I think we also need
> > per-superproject-branch configs under the superproject's .git/ for
> > developer overrides.
>
> I disagree: in my idea the --index switch is a maintainer only command
> to modify the behavior of the developers and touch only indexed files
> (.gitmodules, or create a new submodule branch). It expressly don't
> touch .git/config.
Something that just touches the config files is syntactic sugar, so I
avoided a more detailed review and moved on to address what I saw as a
more fundamental issue (preferred submodule local branches on a
per-superproject-branch level).
Here's a detailed workflow for the {my-feature, my-feature, master}
example I roughed out before [5].
# create the subproject
mkdir subproject &&
(
cd subproject &&
git init &&
echo 'Hello, world' > README &&
git add README &&
git commit -m 'Subproject v1'
) &&
# create the superproject
mkdir superproject
(
cd superproject &&
git init &&
git submodule add ../subproject submod &&
git config -f .gitmodules submodule.submod.update merge &&
git commit -am 'Superproject v1' &&
( # 'submodule update' doesn't look in .gitmodules (yet [6]) for a
# default update mode. Copy submodule.submod
