git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Heiko Voigt <hvoigt@hvoigt.net>
To: Nick Townsend <nick.townsend@mac.com>
Cc: "Junio C Hamano" <gitster@pobox.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: Tue, 3 Dec 2013 19:33:01 +0100	[thread overview]
Message-ID: <20131203183301.GB4629@sandbox-ub> (raw)
In-Reply-To: <3C71BC83-4DD0-43F8-9E36-88594CA63FC5@mac.com>

Hi,

On Mon, Dec 02, 2013 at 03:55:36PM -0800, Nick Townsend wrote:
> 
> On 29 Nov 2013, at 14:38, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> > 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
> 
> It seems to me that the question that you are trying to solve is
> more complex than the problem I faced in git-archive, where we have a
> single commit of the top-level repository that we are chasing. 
> Perhaps we should split the work into two pieces:
> 
> a. Identifying the complete submodule configuration for a single commit, and
> b. the complexity of behaviour when fetching and cloning recursively (which 
>     of course requires a.)

You are right the latter (b) is a separate topic. So how about I extract the
submodule config parsing part from the mentioned patch and you can then
use that patch as a basis for your work? As far as I understand you only
need to parse the .gitmodules file for one commit and then lookup the
submodule names from paths right? That would simplify matters and we can
postpone the caching of multiple commits for the time when I continue on b.

> I’m very happy to work on the first, but the second seems to me to require more
> understanding than I currently possess. In order to do this it would help to have a
> place to discuss this. I see you have used the wiki of your fork of git on GitHub.
> Is that the right place to solicit input?

I only used that to collect all information into one place. I am not
sure if thats actually necessary for the .gitmodules parsing you need.

I think we should discuss everything related to the design and patches
here on the list. If you have questions regarding my code I am also
happy to answer that via private mail.

Cheers Heiko

  parent reply	other threads:[~2013-12-03 18:35 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
     [not found]           ` <3C71BC83-4DD0-43F8-9E36-88594CA63FC5@mac.com>
2013-12-03  0:05             ` Nick Townsend
2013-12-03 18:33             ` Heiko Voigt [this message]
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=20131203183301.GB4629@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).