Re: [PATCH 6/6] Teach core object handling functions about gitlinks

> So I'd argue that branches in submodules give you:
> 
>  - you can develop the submodule *independently* of the supermodule, but 
>    still be able to easily merge back and forth.
> 
>    Quite often, the submodule would be developed entirely _outside_ of the 
>    supermodule, and the "branch" that gets the most development would thus
>    actually be the "vendor branch", entirely outside the supermodule. Call 
>    that the "main" branch or whatever, inside the supermodule it would 
>    often be something like the remote "remotes/origin/master" branch.
> 
>    So inside the supermodule, the HEAD would generally point to something 
>    that is *not* necessarily the "main development" branch, because the 
>    supermodule maintainer would quite logically and often have his own 
>    modifications to the original project on that branch. It migth be a 
>    detached branch, or just a local branch inside the submodule.

>  - branches inside submodules are *also* very useful even inside the 
>    supermodule, ie they again allow topic work to be fetched into the
>    submodule *without* having to actually be part of the supermodule,
>    or as a way to track a certain experimental branch of the supermodule.
> 
>    I suspect that most supermodule usage is as an "integrator" branch, 
>    which means that the supermodule tends to follow the "main 
>    development", and the whole point of the supermodule is largely to have 
>    a collection of "stable things that work together". 
> 
>    In contrast, branches within submodules are useful for doing all the 
>    development that is *not* yet ready to be committed to the supermodule, 
>    exactly because it's not yet been tested in the full "make World" kind 
>    of situation.

> > Whenever you do a checkout in the supermodule you also have to update
> > the submodule and this update has to change the same thing which is read
> > above.
> 
> I suspect (but will not guarantee) that the right approach is that a 
> supermodule checkout usually just uses a "detached HEAD" setup. Within the 
> context of the supermodule, only the actual commit SHA1 matters, not what 
> branch it was developed on (side note: I haven't decided if we should 
> allow the SHA1 to be a signed tag object too - the current patches 
> obviously don't care since they never follow the SHA1 anyway, and it might 
> be a good idea).

> So I strongly suspect (and that is what the patch series embodies) that as 
> far as the supermodule is concerned, it should *not* matter at all what 
> branch the subproject was on. The subproject can use branches for 
> development, and the supermodule really doesn't care what the local 
> branchname was when a commit was made - because branch-names are *local* 
> things, and a branch that is called "experimental" in one environment 
> might be called "master" in another.

> > Updating the branch which HEAD points to is dangerous.
> 
> I would strongly suggest that the *superproject* never really change the 
> status of the subproject HEAD, except it updates it for "pull/reset", and 
> then it just would use whatever the subproject decided to use.
> 
> The subproject HEAD policy would be entirely under the control of the 
> subproject. If the subproject wants to use a branch to track the 
> superproject, go wild: have a real branch that is called "my-integration" 
> and make HEAD a symref to that (and thus any work in the superproject will 
> update that branch - something that is visible when you pull directly from 
> that subproject!)

> But quite often, I suspect that a subproject would just use a detached 
> HEAD. The subproject may have branches of its own, of course, but you can 
> think of HEAD as not being connected to any of it's "own" branches, but 
> simply being the "superproject branch". That's a fairly accurate picture 
> of reality, and using "detached HEAD" sounds like a very natural thing to 
> do in that situation.

> So I really think you can do both, and I think using HEAD inside the 
> superproject gives you exactly that flexibility - you can decide on a 
> per-subproject basis whether HEAD should track a real local branch in a 
> subproject, or whether it should be detached.
> 
> (Side note: if you do *not* use detatched HEAD, I suspect the .gitmodules 
> file could also contain the branchname to be used for the subproject 
> tracking, but I think that's a detail, and quite debatable)
> 
> > So my advice is:
> > Always read and write one dedicated branch (hardcoded "master" or
> > configurable) when the supermodule wants to access a submodule.
> 
> So the main reasons I don't think that is a good idea are:
> 
>  - it's less flexible: see above on why you might want to use a dedicated 
>    branch *or* just detached HEAD, and why you might want to choose your 
>    own name for the dedicated branch.

>    This is an equally strong argument for just using HEAD - when we
>    actually implement a
> 
> 	 git diff --subproject
> 
>    flag that recurses into the subproject, if you don't use HEAD inside 
>    the subproject, that suddenly becomes a *very* confusing thing.