git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Jacob Keller <jacob.keller@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git mailing list <git@vger.kernel.org>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Jens Lehmann <Jens.Lehmann@web.de>
Subject: Re: [PATCHv5 8/8] clone: recursive and reference option triggers submodule alternates
Date: Wed, 24 Aug 2016 15:52:53 -0700	[thread overview]
Message-ID: <CAGZ79kah4sY0NJkaqDiUqcwsCHn0SECkMjN8SoXQ8vGi6zRkuw@mail.gmail.com> (raw)
In-Reply-To: <CA+P7+xpmyx+QsdOpS7JC1i9Z6cdsy_=MK7J_rGYiukPsqAJBVQ@mail.gmail.com>

On Tue, Aug 23, 2016 at 11:29 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Tue, Aug 23, 2016 at 4:03 PM, Stefan Beller <sbeller@google.com> wrote:
>>>> +
>>>> +       if (option_recursive) {
>>>> +               if (option_required_reference.nr &&
>>>> +                   option_optional_reference.nr)
>>>> +                       die(_("clone --recursive is not compatible with "
>>>> +                             "both --reference and --reference-if-able"));
>>>
>>> So if you have multiple references that don't all match we basically
>>> just refuse to allow recursive?
>>>
>>> Would it be better to simply assume that we want to die on missing
>>> references instead of failing the clone here?
>>
>> The new config options are per repo (or even set globally), and not
>> per alternate. And as we communicate the [if-able] part via the config
>> options to the submodules it is not feasible to transport both
>> kinds of (reference-or-die and reference-but-ignore-misses).
>>
>> That is why I introduced this check in the first place. If we'd go back
>> to the drawing board and come up with a solution that is on a
>> "per alternate" basis we could allow such things.
>>
>>> That is, treat it so
>>> that multiple reference and reference-if-able will die, and only info
>>> if we got only reference-if-able?
>>>
>>> Probably what's here is fine, and mixing reference and
>>> reference-if-able doesn't make much sense.
>>
>> I think the reference-if-able doesn't make sense for one project alone
>> as you can easily script around that, but is only useful if you have
>> submodules in a partially checked out superproject that you want
>> to reference to.
>>
>> Thanks,
>> Stefan
>
> I'm not sure there is a better design.  How are alternates stored? In
> a config section?

Alternates are stored in .git/objects/info/alternates
with each alternate in a new line. On that file (from
(man gitrepository-layout):

objects/info/alternates

This file records paths to alternate object stores that this object store
borrows objects from, one pathname per line. Note that not only native
Git tools use it locally, but the HTTP fetcher also tries to use it remotely;
this will usually work if you have relative paths (relative to the object
database, not to the repository!) in your alternates file, but it will not work
if you use absolute paths unless the absolute path in filesystem and web
URL is the same. See also objects/info/http-alternates.

So changing that file is out of question.
Ideally we would have a flag for each path here, though.

> Or is there some way we can store the is-able per
> alternate and look it up when adding them to submodule?

I guess we could invent a file as alternate-flags that is matches
line by line to the alternates file.

I don't think we'd want to go that way for now as it would really only
help in an edge case?

If we later find out we need the flag on a per-alternate basis we can
still come up with a solution and just not set these config variables,
so I think we'll be fine for now with this approach.

Thanks,
Stefan

  reply	other threads:[~2016-08-24 22:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-15 21:53 [PATCHv5 0/8] git clone: Marry --recursive and --reference Stefan Beller
2016-08-15 21:53 ` [PATCHv5 1/8] t7408: modernize style Stefan Beller
2016-08-23 22:04   ` Jacob Keller
2016-08-15 21:53 ` [PATCHv5 2/8] t7408: merge short tests, factor out testing method Stefan Beller
2016-08-23 22:10   ` Jacob Keller
2016-08-15 21:53 ` [PATCHv5 3/8] submodule--helper module-clone: allow multiple references Stefan Beller
2016-08-23 22:12   ` Jacob Keller
2016-08-15 21:53 ` [PATCHv5 4/8] submodule--helper update-clone: " Stefan Beller
2016-08-23 22:20   ` Jacob Keller
2016-08-15 21:53 ` [PATCHv5 5/8] clone: factor out checking for an alternate path Stefan Beller
2016-08-23 22:29   ` Jacob Keller
2016-08-15 21:53 ` [PATCHv5 6/8] clone: clarify option_reference as required Stefan Beller
2016-08-23 22:31   ` Jacob Keller
2016-08-15 21:53 ` [PATCHv5 7/8] clone: implement optional references Stefan Beller
2016-08-23 22:35   ` Jacob Keller
2016-08-15 21:53 ` [PATCHv5 8/8] clone: recursive and reference option triggers submodule alternates Stefan Beller
2016-08-23 22:43   ` Jacob Keller
2016-08-23 23:03     ` Stefan Beller
2016-08-24  6:29       ` Jacob Keller
2016-08-24 22:52         ` Stefan Beller [this message]
2016-08-24 23:37           ` Jacob Keller
2016-08-31  5:04             ` Stefan Beller
2016-08-31  6:21               ` Jacob Keller
2016-08-15 22:30 ` [PATCHv5 0/8] git clone: Marry --recursive and --reference Junio C Hamano

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=CAGZ79kah4sY0NJkaqDiUqcwsCHn0SECkMjN8SoXQ8vGi6zRkuw@mail.gmail.com \
    --to=sbeller@google.com \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jacob.keller@gmail.com \
    --cc=jrnieder@gmail.com \
    /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).