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  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?
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