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

Reply via email to