[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