Re: Re: [PATCH] submodule recursion in git-archive

> Nick Townsend <nick.townsend@mac.com> writes:
> > * The .gitmodules file can be dirty (easy to flag, but should we
> > allow archive to proceed?)
> 
> As we are discussing "archive", which takes a tree object from the
> top-level project that is recorded in the object database, the
> information _about_ the submodule in question should come from the
> given tree being archived.  There is no reason for the .gitmodules
> file that happens to be sitting in the working tree of the top-level
> project to be involved in the decision, so its dirtyness should not
> matter, I think.  If the tree being archived has a submodule whose
> name is "kernel" at path "linux/" (relative to the top-level
> project), its repository should be at .git/modules/kernel in the
> layout recent git-submodule prepares, and we should find that
> path-and-name mapping from .gitmodules recorded in that tree object
> we are archiving. The version that happens to be checked out to the
> working tree may have moved the submodule to a new path "linux-3.0/"
> and "linux-3.0/.git" may have "gitdir: .git/modules/kernel" in it,
> but when archiving a tree that has the submodule at "linux/", it
> would not help---we would not know to look at "linux-3.0/.git" to
> learn that information anyway because .gitmodules in the working
> tree would say that the submodule at path "linux-3.0/" is with name
> "kernel", and would not tell us anything about "linux/".
> 
> > * Users can mess with settings both prior to git submodule init
> > and before git submodule update.
> 
> I think this is irrelevant for exactly the same reason as above.
> 
> What makes this tricker, however, is how to deal with an old-style
> repository, where the submodule repositories are embedded in the
> working tree that happens to be checked out.  In that case, we may
> have to read .gitmodules from two places, i.e.
> 
>  (1) We are archiving a tree with a submodule at "linux/";
> 
>  (2) We read .gitmodules from that tree and learn that the submodule
>      has name "kernel";
> 
>  (3) There is no ".git/modules/kernel" because the repository uses
>      the old layout (if the user never was interested in this
>      submodule, .git/modules/kernel may also be missing, and we
>      should tell these two cases apart by checking .git/config to
>      see if a corresponding entry for the "kernel" submodule exists
>      there);
> 
>  (4) In a repository that uses the old layout, there must be the
>      repository somewhere embedded in the current working tree (this
>      inability to remove is why we use the new layout these days).
>      We can learn where it is by looking at .gitmodules in the
>      working tree---map the name "kernel" we learned earlier, and
>      map it to the current path ("linux-3.0/" if you have been
>      following this example so far).
> 
> And in that fallback context, I would say that reading from a dirty
> (or "messed with by the user") .gitmodules is the right thing to
> do.  Perhaps the user may be in the process of moving the submodule
> in his working tree with
> 
>     $ mv linux-3.0 linux-3.2
>     $ git config -f .gitmodules submodule.kernel.path linux-3.2
> 
> but hasn't committed the change yet.
> 
> > For those reasons I deliberately decided not to reproduce the
> > above logic all by myself.
> 
> As I already hinted, I agree that the "how to find the location of
> submodule repository, given a particular tree in the top-level
> project the submodule belongs to and the path to the submodule in
> question" deserves a separate thread to discuss with area experts.