On Thu, Dec 8, 2011 at 4:13 AM, <andreas.t.auer_gtml_37453@xxxxxxxxxxxx> wrote:
>
> On 07.12.2011 23:23 Jens Lehmann wrote:
>> > If you have tracking branches, the supermodule can just update the
>> > corresponding branch. If this branch is currently checkedout and
>> > the work area is clean, then the work area is updated, too. If
>> > there is currently a local branch or a diffent super-branch
>> > checked out then the working area should be considered "detached"
>> > from the superproject and not updated.
>>
>> This sounds a lot like the "follow branch tip" model we discussed
>> recently (which could be configured via .gitmodules), but I'm not
>> sure you really are in the same boat here.
>
> When I understood that correctly it was just a configuration to what branch
> should be automatically checked out in the submodule. This seems to be too
> complicated IMO, because when you have different branches in the
> superproject then you may want to have different branches in the submodules,
> too, but you would need to configure that submodule branch in .gitmodules
> for each branch separately. I.e. in the master branch the .gitmodule may
> contain "master", in the maint branch the .gitmodules may have "maint" as
> the branch to follow.
Yes, but maybe you can update this information in the .gitmodules file
easily with a command. Maybe it could be something simpler than "git
sync-gitmodules-branches", but that is essentially what it would do:
it would save the current branch in each submodule as the "tracked"
branch in the .gitmodules file.
The advantages to this, I think, are that
1. Your "submodule A follows branch X" information is explicit in the
.gitmodules file and so it is not hidden when I examine your patch.
(It sounds to me like the refs/super/* branches would necessarily be
hard to find since the refs/ hierarchy is usually meta data about
local and remote branches. Maybe I should think about tags and notes
more, though.)
2. When you change to "submodule A now follows branch Y", this
information can be unambiguously saved in the commit where it occurred
rather than tucked away, again, in refs/super/*.
The disadvantage, maybe, are that you must now use 'git submodule
sync' or something like that to put any .gitmodules changes into
effect.
Or maybe that is an advantage. How often will this branch tracking change?
I like where you are going, though. But I have trouble following your
meaning when you toss around words like "ref" and "HEAD" and "branch"
and "super-branch". Maybe we can set up a strawman repo (virtually or
on github) where you can explain what happens now and what you wish
would happen instead.
For example, I have some repos like this:
super
+--subA
+--subB
I wish I could do this:
cd super && checkout master
to get this:
super (master)
+--subA (master)
+--subB (master)
Or, if I have SubB on super/'master' tracking 'foo', I could get this:
super (master)
+--subA (master)
+--subB (foo)
And I wish these commands would work as if this was all one repository:
cd super && git diff master maint
cd super && git grep foo
cd subA && git grep foo -- :/
cd super && git status
cd subA && git status
But I wonder what this would do:
cd super && git remote -v &&
cd subA && git remote -v
> I do want to follow the tip of the branch, if the superproject has that
> currently checked out. If the superproject checks out a tagged version for a
> rebuild, then the submodule should not follow the tip, but should get a
> detached HEAD of the corresponding commit, just as the superproject. When
> the superproject goes back to the branch, the submodule should go back to
> its tracking branch.
Now this makes sense. I want the same thing. I want to preserve
history on "old" commits, but I want to "advance to tip" on "new"
commits.
The trouble, I think, is in telling the difference between "old" and
"new". I think it means there is a switch, like --auto-follow (or
--no-auto-follow for the alternate if core.auto_follow is set). But
having a config option as the default is likely to break lots of
scripts.
So maybe I need a new command that does this:
git checkout master && git submodule foreach 'git checkout master'
Maybe it's called "git checkout master --recurse-submodules". But I
seem to recall this is already a non-starter for some reason, and
anyway it doesn't solve the "variant branches in some submodules"
problem.
Which brings us back to .gitmodules.
>> > With this concept you could even switch branches in the
>> > superproject and the attached submodules follow - still having no
>> > detached HEAD. When you want to do some local work on the
>> > submodule you checkout a local branch and merge back into the super
>> > branch later.
>>
>> You lost me here. How can you merge a submodule branch into one of
>> the superproject?
>
> It wouldn't work, if the super/* branch would contain a superproject's
> SHA-1, that is right. But as explained above, it points to a commit of the
> submodule.
>>
>>
>> But we would want to have a deterministic update procedure, no? (And
>> what has more freedom than a detached HEAD? ;-)__
>
> I think my proposal would be deterministic.
> And everything where you can commit to has more freedom than a detached HEAD
You can commit to a detached HEAD. I do it all the time. The trick
is in not switching away from a detached HEAD with your local commits
still on it. :-)
>> > Even though it will raise a lot of detailed questions like "should
>> > the refs/super/* be pushed/pulled when syncing the submodule
>> > repositories".
>>
>> I doubt that is a good idea, as that might conflict with the same
>> submodule sitting in a different superproject. But I'm interested to
>> hear how you want to solve that.
>
> The first answer to my question was "yes, you need to transfer the refs or
> you get unreferenced objects" and "no, you can't transfer the refs, because
> they are owned by the superproject, not the submodule."
> But binding a submodule to a superproject makes perfect sense if it is _one_
> project that is split into submodules. In that case you only have one
> superproject for a submodule and for that purpose it would be good workflow.
This is not useful to me, though. Sorry.
> It is even nice to see which commits in the submodule belong to what
> branches in the superproject or to what release version (so tracking
> superproject tags would make sense, too). If you have a submodule that has
> more than one superproject but these are well-defined, it could be solved
> using refspecs (e.g. refs/super/foo/* for one and refs/super/bar/* for the
> other superproject), but currently I can't think of a context where this
> makes sense.
I can, but this does put the cart before the horse. The submodule is
subservient to the super project in all my setups. The submodule is
not aware who owns him. He is a bit like the DAG in reverse. He
knows one direction only (children), not the other (parents).
Phil
--
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