2014/1/9 W. Trevor King <wking@xxxxxxxxxx>:
>
> However, submodule.<name>.local-branch has nothing to do with remote
> repositories or tracking branches.
My bad: this means the feature is still not entirely clear to me.
>
> [branch "my-feature"]
> remote = origin
> merge = refs/heads/my-feature
> [submodule "submod"]
> local-branch = "my-feature"
>
> and I don't think Git's config supports such nesting.
>
Aesthetically, It doesn't look very nice.
>
> I can resuscitate that if folks want, but Heiko felt that my initial
> consolidation didn't go far enough [2]. If it turns out that we're ok
> with the current level of consolidation, would you be ok with
> "non-checkout submodule.<name>.update" as the trigger [3]?
For me it was ok with what you did:
-------------------------------------------------
if "just_cloned" and "config_branch"
then
!git reset --hard -q"
fi
-------------------------------------------------
So yes: at the first clone 'checkout' keeps attached HEAD, while
'merge' and 'rebase' attach to the branch.
If it's not the first clone, you should take no action (and your
original patch was ok about this).
> I think
> that adding a halfway step between the current status and full(ish)
> submodule.<name>.local-branch support is just going to confuse people
Well, for now you got some success in confusing me with this "local-branch" :)
At certain point you may ask maintainers what are the accepted
features (because all these debates should be about getting, or not
getting, endorsement about something) and finalize a patch so people
can further review.
--
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