From: Philip Oakley Date: Mon, 15 Aug 2011 23:00:09 GMT Subject: Re: shallow clone not very shallow due to tags Message-ID: <4EEB129543344D0AA1C3AD3696F8F5D5@PhilipOakley> In-Reply-To: Monday, August 15, 2011 6:16 PM "Shawn Pearce" > On Mon, Aug 15, 2011 at 07:03, Nguyen Thai Ngoc Duy > wrote: >> On Mon, Aug 15, 2011 at 6:58 AM, Shawn Pearce >> wrote: >>> Uhm. That is not a very shallow clone. The clone copied 20234 objects >>> at 9.15 MiB... so its ~20 MiB lighter than a full clone. But nearly >>> all of the tags exist, because the clone client is declaring want >>> lines for them, making the server generate up to 1 commit back from >>> the wanted tag. I know shallow support is the feature nobody wants to >>> think about, but this just seems broken to me. Clients performing a >>> shallow clone shouldn't be asking for tags... but they should be using >>> the include-tag protocol option so that if they do happen to receive a >>> tagged commit, the tag object will also be sent. >> >> The same would apply if the repo in question has many branches. Should >> we fetch only master (or a user-specified set of refs) in shallow >> clone? > > Yes, I think a user who is making a shallow clone should only get the > HEAD branch to the depth specified, nothing else. If they want > additional branches, they should either pass them on the command line > to a new flag for clone, or modify their fetch configuration > after-the-fact and fetch those separately. > > From what I can gather from some users I have talked to, the primary > usage of shallow clone is to try and (sort of) quickly grab a branch, > make a change, and post that change to the maintainers for review and > acceptance. E.g. correcting a spelling typo. Relatively simple changes > that can be built on a specific branch, and don't really require all > of the history. > > And if a repository does have more than one branch, but is shallow > cloned at say depth of 1, the user probably doesn't get the merge > bases between them, so the value of the other branches is greatly > reduced. You can't make a merge between these, and a new developer > getting involved in the project cannot see how the branches relate to > each other. So there isn't a lot of value in sucking down those > additional branches during clone. > The shallow clone problem came up a few times recently on StackOverflow. One usage is to create an orphan branch, but the manual doesn't point the user to that option. When I first read the man page I expected that any clone would be from a fixed point in history, rather than a point that may move (as extra commits are made to the remote). It maybe that what is needed is an option that will clone from a fixed commit point, so that there is no confusion as to the 'current depth'.