From: Martin von Gagern <Martin.vGagern@gmx.net>
To: git@vger.kernel.org
Subject: Shallow submodule efficiency
Date: Tue, 28 Jun 2016 07:39:27 +0200 [thread overview]
Message-ID: <f572d4ee-c618-6501-a8e5-717feca3ed7c@gmx.net> (raw)
Hi!
I have the feeling that “git submodule update --depth 1” is less clever
than it could be. Here is one example I observed with git 2.0.0:
git init foo
cd foo
git clone --single-branch \
-b v0.99 https://github.com/git/git.git git-scm
git submodule add https://github.com/git/git.git git-scm
git commit -m Submod
git clone --dissociate . ../bar
cd ../bar
git submodule update --init --depth 1 git-scm
This will download quite a bit of history, then result in an error message:
error: no such remote ref a3eb250f996bf5e12376ec88622c4ccaabf20ea8
Fetched in submodule path 'git-scm', but it did not contain
a3eb250f996bf5e12376ec88622c4ccaabf20ea8. Direct fetching of that
commit failed.
That seems so avoidable, since the commit in question is a tag, so it
would be perfectly possible to fetch that specific commit from the
server directly. Something like the following commands would do the trick:
git fetch $url $(git ls-remote $url | \
awk /$sha1/'{print $2}' | sed 's/\^{}//')
If the commit in question is NOT a ref, then whether asking for it by
unlisted SHA1 is supported will probably depend on the server's
uploadpack.allowReachableSHA1InWant setting. I guess this is a reason
why fb43e31 made the fetch for a specific SHA1 a fallback after the
fetch for the default branch. Nevertheless, in case of “--depth 1” I
think it would make sense to abort early: if none of the listed refs
matches the requested one, and asking by SHA1 isn't supported by the
server, then there is no point in fetching anything, since we won't be
able to satisfy the submodule requirement either way.
For the case of “--depth n” with n > 1, I was wondering whether it would
make sense to prefer the branch listed in submodule.‹name›.branch over
the default branch.
I think shallow submodules would be very useful to embed libraries into
projects, without too much care for history (and without the download
times getting it entails), but with efficient updates to affected files
only in case of a change in library version. But not being able to get a
specific tag as a shallow submodule is a major showstopper here, I think.
Greetings,
Martin von Gagern
next reply other threads:[~2016-06-28 5:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-28 5:39 Martin von Gagern [this message]
2016-06-28 17:20 ` Shallow submodule efficiency Stefan Beller
2016-06-28 19:08 ` Martin von Gagern
2016-06-28 19:56 ` Stefan Beller
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=f572d4ee-c618-6501-a8e5-717feca3ed7c@gmx.net \
--to=martin.vgagern@gmx.net \
--cc=git@vger.kernel.org \
/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).