[ET Trac] [Einstein Toolkit] #148: Eliminate git clone --depth 1 or provide a work around it
Einstein Toolkit
trac-noreply at einsteintoolkit.org
Fri Dec 17 12:19:25 CST 2010
#148: Eliminate git clone --depth 1 or provide a work around it
----------------------------+-----------------------------------------------
Reporter: bmundim | Owner: eric9
Type: enhancement | Status: accepted
Priority: major | Milestone:
Component: GetComponents | Version:
Resolution: | Keywords: git clone shallow depth
----------------------------+-----------------------------------------------
Comment (by bmundim):
Why does the shallow clone have to be associated with anonymous checkouts?
The users may checkout anonymously their own private repositories.
Besides, I disagree with the distinction between users and developers
in this context. It is quite artificial. Ultimately ET users are
developers of their own private thorns, and will be interested in using
GetComponents to clone their repositories in a standard fashion
(I couldn't find any other project yet that recommends using shallow
clone. Git, linux kernel, android, perl, all use a standard clone
command with no options).
I am not sure if the quicker checkout time argument proceeds.
We haven't studied any network performance yet to conclude
on the speed gains. Also, we know that access to the ET repositories
has been notoriously unpredictable. It may take anything from 10min
to 40min to checkout the entire tree and a few modules may still
be missing, forcing users to repeat the procedure. So what kind of
gain do we have? 20% speed up? 30%? will that matter on a one time
checkout? I think it is more important to have full access to the
history of commits in order to investigate how a particular feature
was implemented or which commit introduced an unwanted side effect,
bug, etc.
So, I insist, users may access their private repositories anonymously,
then the !AUTH_URL directive won't work for these users and they end up
with a shallow clone, what is not standard. I suggest to have the shallow
option not associated with the kind of authentication users adopt.
Simply implement this option on its own. We could use then shallow
clone for the release as a default, a '-s' flag for example, and
not using it for the development, or whatever people want, but
at least we would have an option of not using it at all,
as I strongly recommend.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/148#comment:2>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
More information about the Trac
mailing list