From: Konstantin Khomoutov Date: Fri, 19 Apr 2013 16:02:34 GMT Subject: Re: Pushing/fetching from/into a shallow-cloned repository Message-ID: <20130419200234.215de8c7b5dc7510025847b9@domain007.com> In-Reply-To: <7vbo9b4fuz.fsf@alter.siamese.dyndns.org> On Thu, 18 Apr 2013 15:46:12 -0700 Junio C Hamano wrote: > "Philip Oakley" writes: > > >> So I observe pushing/fetching works OK at least for a simple case > >> like this one. > >> > >> Hence I'd like to ask: if the manual page is wrong or I'm observing > >> some corner case? > >> -- > > The manual is deliberately misleading. > > Yes, it is erring on the safe side. > > It was not coded with the case where the gap widens (e.g. either > side rewinds the history) in mind as you explained; for simple cases > the code just happens to work, but the users are encouraged not to > rely on it to be safe than sorry. Well, actually my question arouse during the discussion which followed by this SO question [1] where someone asked if it's possible to update just one file in a remote repository without cloning it first (a-la Subversion, that is). While I perfectly understand that Git data model does not support such "server-side commits" I'm able to envision a case when, say, a developer is asked to perform some minor tweak to the code while they're in a situation with no repository clone at hand and only a crappy/costly cellular link available for communication. I think shallow cloning might be a palliative solution to this kind of problem (a one-off clone/edit/commit/push session). Taking into account what Duy Nguyen said on this topic, it seems that that description of the shallow cloning in the git-clone manual page could supposedly be made somewhat less denying about what could be done using a shallow clone. May be a note that such a setup could be okay for very simple things like clone/edit/push would be just enough? 1. http://stackoverflow.com/q/16077691/720999