On Wed, Jan 08, 2014 at 03:12:44AM +0100, Francesco Pretto wrote: > 2014/1/8 W. Trevor King <[email protected]>: > > Note that I've moved away from “submodule.<name>.branch > > set means attached” towards “we should set per-superproject-branch > > submodule.<name>.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.<name>.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.<name>.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 <branch>.
> >> # Also set ".git/config" 'submodule.<module>.branch' to <branch>
> >> $ git submodule head -b <branch> --attach <module>
> > [...]
> > 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.<module>.branch'
> >> # Also attach or detach the HEAD according to what is in ".gitmodules":
> >> # with Trevor's patch 'submodule.<module>.branch' set means attached,
> >> # unset means detached
> >> $ git submodule head --reset <module>
> >
> > To me this reads “always detach HEAD” (because it unsets
> > submodule.<name>.branch, and submodule.<name>.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.<module>.branch' to <branch>
> >> $ git submodule head -b <branch> --attach --index <module>
> >>
> >> # Unset ".gitmodules" 'submodule.<module>.branch'
> >> $ git submodule head --reset --index <module>
> >> ---------------------------------------------------------------------
> >
> > 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.update over to
# .git/config
git submodule init
)
) &&
# start a feature branch on the superproject
(
cd superproject &&
#git checkout -b my-feature --recurse-submodules &&
( # 'git submodule checkout --recurse-submodules' doesn't exist yet, so...
git checkout -b my-feature &&
git config -f .gitmodules submodule.submod.local-branch my-feature &&
cd submod &&
git checkout -b my-feature
) &&
(
cd submod &&
echo 'Add the subproject side of this feature' > my-feature &&
git add my-feature &&
git commit -m 'Add my feature to the subproject'
) &&
echo 'Add the superproject side of this feature' > my-feature &&
git add my-feature &&
git commit -m 'Add the feature to the superproject'
) &&
# meanwhile, the subproject has been advancing
(
cd subproject &&
echo 'Goodbye, world' >> README &&
git commit -am 'Subproject v2'
) &&
# we need to get that critical advance into the superproject quick!
(
cd superproject &&
# update the master branch
#git checkout --recurse-submodules master
( # 'git checkout --recurse-submodules' doesn't exist yet [2,3].
# Even with that patch, 'git checkout' won't respect
# submodule.<name>.local-branch without further work.
git checkout master &&
cd submod &&
git checkout master # don't pull in our my-feature work
)
git submodule update --remote &&
git commit -am 'Catch submod up with Subproject v2' &&
# update the my-feature branch
git checkout my-feature
( # 'git checkout' doesn't mess with submodules
cd submod &&
git checkout my-feature
)
git submodule update --remote &&
git commit -am 'Catch submod up with Subproject v2' &&
# what does the history look like?
(
cd submod &&
git --no-pager log --graph --date-order --oneline --decorate --all
# * 3a22cef (HEAD, my-feature) Merge commit
'd53958b18277ce5bd6c734e9597a69bb878b31e1' into my-feature
# |\
# * | 8322dcc Add my feature to the subproject
# | * d53958b (origin/master, origin/HEAD, master) Subproject v2
# |/
# * 9813010 Subproject v1
) &&
git ls-tree master submod &&
# 160000 commit d53958b18277ce5bd6c734e9597a69bb878b31e1 submod
git ls-tree my-feature submod
# 160000 commit 3a22cef30db57f1b89251f3e434fa0bd0f1b99a2 submod
)
git --version
# git version 1.8.3.2
The currently-ugly bits could be fixed with:
* 'git submodule update' falling back on .gitmodules for
submodule.<name>.update [6].
* 'git submodule checkout -b my-feature --recurse-submodules' should
checkout the submodule.<name>.local-branch configured for the
super-project's my-feature branch (but only if that wouldn't destroy
some current submodule information). This would build on work in
Jens and Jonathans' branch [2,3].
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/240127
[2]: http://article.gmane.org/gmane.comp.version-control.git/240117
[3]: http://thread.gmane.org/gmane.comp.version-control.git/239695
[4]: http://article.gmane.org/gmane.comp.version-control.git/240178
[5]: http://article.gmane.org/gmane.comp.version-control.git/240190
[6]: http://article.gmane.org/gmane.comp.version-control.git/239246
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
