Re: Pushing/fetching from/into a shallow-cloned repository
- From
- Konstantin Khomoutov <flatworm@users.sourceforge.net>
- Date
- Apr 19, 2013, 16:02 UTC
- 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 <gitster@pobox.com> wrote:
Show 16 quoted lines
> "Philip Oakley" <philipoakley@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