From: Heiko Voigt <hvoigt@hvoigt.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Nick Townsend" <nick.townsend@mac.com>,
"René Scharfe" <l.s.r@web.de>,
"Jens Lehmann" <Jens.Lehmann@web.de>,
git@vger.kernel.org, "Jeff King" <peff@peff.net>
Subject: Re: Re: [PATCH] submodule recursion in git-archive
Date: Fri, 29 Nov 2013 23:38:45 +0100 [thread overview]
Message-ID: <20131129223845.GA31636@sandbox-ub> (raw)
In-Reply-To: <xmqqzjopsk9b.fsf@gitster.dls.corp.google.com>
On Wed, Nov 27, 2013 at 11:43:44AM -0800, Junio C Hamano wrote:
> 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.
FYI, I already started to implement this lookup of submodule paths early
this year[1] but have not found the time to proceed on that yet. I am
planning to continue on that topic soonish. We need it to implement a
correct recursive fetch with clone on-demand as a basis for the future
recursive checkout.
During the work on this I hit too many open questions. Thats why I am
currently working on a complete plan[2] so we can discuss and define how
this needs to be implemented. It is an asciidoc document which I will
send out once I am finished with it.
Cheers Heiko
[1] http://article.gmane.org/gmane.comp.version-control.git/217020
[2] https://github.com/hvoigt/git/wiki/submodule-fetch-config
next prev parent reply other threads:[~2013-11-29 22:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-26 0:04 [PATCH] submodule recursion in git-archive Nick Townsend
2013-11-26 15:17 ` René Scharfe
2013-11-26 18:57 ` Jens Lehmann
2013-11-26 22:18 ` Junio C Hamano
2013-11-27 0:28 ` René Scharfe
2013-11-27 3:28 ` Nick Townsend
2013-11-27 19:05 ` Junio C Hamano
2013-11-27 3:55 ` Nick Townsend
2013-11-27 19:43 ` Junio C Hamano
2013-11-29 22:38 ` Heiko Voigt [this message]
[not found] ` <3C71BC83-4DD0-43F8-9E36-88594CA63FC5@mac.com>
2013-12-03 0:05 ` Nick Townsend
2013-12-03 18:33 ` Heiko Voigt
2013-12-09 20:55 ` [RFC/WIP PATCH] implement reading of submodule .gitmodules configuration into cache Heiko Voigt
2013-12-09 23:37 ` Junio C Hamano
2013-12-12 13:03 ` Heiko Voigt
2013-12-03 0:00 ` [PATCH] submodule recursion in git-archive Nick Townsend
2013-12-03 0:03 ` Fwd: " Nick Townsend
2013-11-26 22:38 ` Heiko Voigt
2013-11-27 3:33 ` Nick Townsend
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131129223845.GA31636@sandbox-ub \
--to=hvoigt@hvoigt.net \
--cc=Jens.Lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=l.s.r@web.de \
--cc=nick.townsend@mac.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).