On Thu, 18 Apr 2013 15:46:12 -0700 Junio C Hamano <gits...@pobox.com> wrote:
> "Philip Oakley" <philipoak...@iee.org> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
