* Failed shallow submodule clone for fixed SHA1 falls back to checking out HEAD
@ 2017-04-18 13:04 Sebastian Schuberth
[not found] ` <CAGZ79kazh5+6vx87PVXUNgyJebO2m6pEkT1G8rSFvCmWQZdSuw@mail.gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Sebastian Schuberth @ 2017-04-18 13:04 UTC (permalink / raw)
To: git; +Cc: Stefan Beller
Hi,
this is using "git version 2.12.2.windows.2" on Windows / "git version 2.12.2-639-g584f897" on Linux.
I have configured my superproject with .gitmodules saying
---8<---
[submodule "src/funTest/resources/projects/external/jgnash"]
path = src/funTest/resources/projects/external/jgnash
url = https://github.com/ccavanaugh/jgnash.git
shallow = true
---8<---
and configured the submodule to checkout commit 2aa4cce7d7fd46164030f2b4d244c4b89e77f722 [1]. When doing a fresh clone of my superproject via "git clone --recursive" I get
---8<---
error: Server does not allow request for unadvertised object 2aa4cce7d7fd46164030f2b4d244c4b89e77f722
Fetched in submodule path 'src/funTest/resources/projects/external/jgnash', but it did not contain 2aa4cce7d7fd464030f2b4d244c4b89e77f722. Direct fetching of that commit failed.
---8<---
So far so good, it simply seems that GitHub does not support allowReachableSHA1InWant [2]. The interesting bit is that my submodule checkout still ends up being shallow, but poiting to HEAD:
---8<---
$ cd src/funTest/resources/projects/external/jgnash
$ git log
commit 12036fffb6c620515edd96416363fd1749b5d003 (grafted, HEAD -> master, origin/master, origin/HEAD)
Author: Craig Cavanaugh <jgnash.devel@gmail.com>
Date: Tue Apr 18 05:33:06 2017 -0400
Fix typos
---8<---
Wouldn't it make more sense to unshallow the submodule clone in this case and checkout the configured commit 2aa4cce7d7fd46164030f2b4d244c4b89e77f722 afterwards? At least I'd be getting what I asked for in that case, even if at the cost of additional network traffic. Because if I read [3] correctly, the command line option belonging to "submodule.<name>.shallow" is called "--[no-]recommend-shallow", i.e. it's only a recommendation, to falling back to a full clone should be fine.
[1] https://github.com/ccavanaugh/jgnash/commit/2aa4cce7d7fd46164030f2b4d244c4b89e77f722
[2] https://git-scm.com/docs/git-config#git-config-uploadpackallowReachableSHA1InWant
[3] https://git-scm.com/docs/git-submodule
Regards,
Sebastian
^ permalink raw reply [flat|nested] 3+ messages in thread
* Fwd: Failed shallow submodule clone for fixed SHA1 falls back to checking out HEAD
[not found] ` <CAGZ79kazh5+6vx87PVXUNgyJebO2m6pEkT1G8rSFvCmWQZdSuw@mail.gmail.com>
@ 2017-04-18 19:12 ` Stefan Beller
2017-04-18 19:18 ` Sebastian Schuberth
0 siblings, 1 reply; 3+ messages in thread
From: Stefan Beller @ 2017-04-18 19:12 UTC (permalink / raw)
To: Sebastian Schuberth, git@vger.kernel.org
On Tue, Apr 18, 2017 at 6:04 AM, Sebastian Schuberth
<sschuberth@gmail.com> wrote:
> Hi,
>
> this is using "git version 2.12.2.windows.2" on Windows / "git version 2.12.2-639-g584f897" on Linux.
>
> I have configured my superproject with .gitmodules saying
>
> ---8<---
> [submodule "src/funTest/resources/projects/external/jgnash"]
> path = src/funTest/resources/projects/external/jgnash
> url = https://github.com/ccavanaugh/jgnash.git
> shallow = true
> ---8<---
>
> and configured the submodule to checkout commit 2aa4cce7d7fd46164030f2b4d244c4b89e77f722 [1]. When doing a fresh clone of my superproject via "git clone --recursive" I get
>
> ---8<---
> error: Server does not allow request for unadvertised object 2aa4cce7d7fd46164030f2b4d244c4b89e77f722
> Fetched in submodule path 'src/funTest/resources/projects/external/jgnash', but it did not contain 2aa4cce7d7fd464030f2b4d244c4b89e77f722. Direct fetching of that commit failed.
> ---8<---
>
> So far so good, it simply seems that GitHub does not support allowReachableSHA1InWant [2].
Maybe the error message should say so: "Bug your host admin to enable
allowReachableSHA1InWant".
> The interesting bit is that my submodule checkout still ends up being shallow, but poiting to HEAD:
>
> ---8<---
> $ cd src/funTest/resources/projects/external/jgnash
> $ git log
> commit 12036fffb6c620515edd96416363fd1749b5d003 (grafted, HEAD -> master, origin/master, origin/HEAD)
> Author: Craig Cavanaugh <jgnash.devel@gmail.com>
> Date: Tue Apr 18 05:33:06 2017 -0400
>
> Fix typos
> ---8<---
>
> Wouldn't it make more sense to unshallow the submodule clone in this case and checkout the configured commit 2aa4cce7d7fd46164030f2b4d244c4b89e77f722 afterwards?
If I remember correctly the conclusion of the discussion at the time
was that people are more interested in "less data" rather than
"correct data" because otherwise you would not have asked for shallow.
> At least I'd be getting what I asked for in that case, even if at the cost of additional network traffic. Because if I read [3] correctly, the command line option belonging to "submodule.<name>.shallow" is called "--[no-]recommend-shallow", i.e. it's only a recommendation, to falling back to a full clone should be fine.
Heh, good point. Currently that option is more like a
"--[no-]follow-shallow-in-gitmodules" without second thought as the
"recommend" would elude to.
Thanks,
Stefan
>
> [1] https://github.com/ccavanaugh/jgnash/commit/2aa4cce7d7fd46164030f2b4d244c4b89e77f722
> [2] https://git-scm.com/docs/git-config#git-config-uploadpackallowReachableSHA1InWant
> [3] https://git-scm.com/docs/git-submodule
>
> Regards,
> Sebastian
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Fwd: Failed shallow submodule clone for fixed SHA1 falls back to checking out HEAD
2017-04-18 19:12 ` Fwd: " Stefan Beller
@ 2017-04-18 19:18 ` Sebastian Schuberth
0 siblings, 0 replies; 3+ messages in thread
From: Sebastian Schuberth @ 2017-04-18 19:18 UTC (permalink / raw)
To: Stefan Beller, git@vger.kernel.org
On 2017-04-18 21:12, Stefan Beller wrote:
>> Wouldn't it make more sense to unshallow the submodule clone in this case and checkout the configured commit 2aa4cce7d7fd46164030f2b4d244c4b89e77f722 afterwards?
>
> If I remember correctly the conclusion of the discussion at the time
> was that people are more interested in "less data" rather than
> "correct data" because otherwise you would not have asked for shallow.
I do believe this is an awkward choice. What does it help to get less
data if it's the wrong data?
--
Sebastian Schuberth
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-04-18 19:18 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-18 13:04 Failed shallow submodule clone for fixed SHA1 falls back to checking out HEAD Sebastian Schuberth
[not found] ` <CAGZ79kazh5+6vx87PVXUNgyJebO2m6pEkT1G8rSFvCmWQZdSuw@mail.gmail.com>
2017-04-18 19:12 ` Fwd: " Stefan Beller
2017-04-18 19:18 ` Sebastian Schuberth
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).