Eliminate git clone --depth 1 or provide a work around it

Comments (6)

1. 

   Eric Seidel

   • changed status to open
   • removed comment

   The shallow clone is only used for anonymous checkouts. This way users will have a quicker checkout time, but developers will get the full history of the repository. This should not be an issue with git as the read-only git:xxx URL can go in !URL, whereas the authenticated git@xxx URL can go in !AUTH_URL. I could also add a --[no-]shallow-clone option, but I think this would be superfluous.

   • 2010-12-16T17:58:55+00:00
2. 

   Bruno Mundim reporter

   • removed comment

   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.

   • 2010-12-17T12:19:25+00:00
3. 

   Eric Seidel

   • removed comment

   As an example of the speedup gained by shallow clones, a full clone of Carpet uses 110MB whereas a shallow clone only uses 73MB. I don't think this is insignificant, but I see your point about the arbitrary distinction between users and developers. I'll implement the shallow/no-shallow command-line option, and we can discuss what should be the default on the mailing list.

   • 2010-12-17T13:02:31+00:00
4. 

   Frank Löffler

   • removed comment

   I have to back up Eric here. The decision about the shallow clone was done as a group consensus a while back. The speed and space improvements of shallow clones are, as Eric mentioned, not insignificant. Developers need full clones, otherwise commits will not work, so it wasn't enabled for them. I can also see your points Bruno though, and agree that there probably should be an option for this, and we can argue about it's default value, for anonymous clones. I don't understand the argument about the private repositories though. Is there a reason for someone not to use authenticated access to their own repositories?

   • 2010-12-17T14:36:38+00:00
5. 

   Eric Seidel

   • changed status to resolved
   • removed comment

   I added a "--[no]shallow" option, which will give users the option to override GetComponents default behavior.

   • 2010-12-28T12:41:31+00:00
6. 

   Roland Haas

   • edited description
   • changed status to closed

   • 2019-02-21T20:17:11+00:00
7. Log in to comment