Re: Pushing/fetching from/into a shallow-cloned repository
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 -- 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
Re: Pushing/fetching from/into a shallow-cloned repository
On Fri, Apr 19, 2013 at 6:27 AM, Philip Oakley wrote: > From: "Konstantin Khomoutov" >> 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. > The problem is that the depth is a movable feast that depends on how far the > branches have progressed. > The DAG will be missing the historic merge bases, and in some scenarios can > form disconnected runs of commits. The ref negotiation can also be a > problem. > > The git\Documentation\technical\shallow.txt has some extra details on > issues. With recent improvements in index-pack, I think we can be certain that all gaps are caught. So either it works or it does not. It cannot lead to an incomplete repository. At least for git and smart http transports. So I'm inclined to lift the limitation for these transports. Missing merge bases remains a limitation the user should be aware of, of course. -- Duy -- 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
Re: Pushing/fetching from/into a shallow-cloned repository
"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. -- 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
Re: Pushing/fetching from/into a shallow-cloned repository
From: "Konstantin Khomoutov" Sent: Thursday, April 18, 2013 10:52 AM The git-clone manual page, both [1] and my local copy coming with Git for Windows 1.8.1, say about the --depth command-line option: --depth Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. But having done a shallow clone (--depth=1) of one of my repositories, I was able to record a new commit, push it out to a "reference" bare repository and then fetch back to another clone of the same repository just fine. I have then killed my test commit doing a forced push from another clone and subsequently was able to do `git fetch` in my shallow clone just fine. 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. The problem is that the depth is a movable feast that depends on how far the branches have progressed. The DAG will be missing the historic merge bases, and in some scenarios can form disconnected runs of commits. The ref negotiation can also be a problem. The git\Documentation\technical\shallow.txt has some extra details on issues. Philip -- 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
Re: Pushing/fetching from/into a shallow-cloned repository
On Thu, 18 Apr 2013 13:52:33 +0400 Konstantin Khomoutov wrote: > The git-clone manual page, both [1] and my local copy coming with > Git for Windows 1.8.1, say about the --depth command-line option: [...] Oops, by [1] I wanted to refer to this version: https://www.kernel.org/pub/software/scm/git/docs/git-clone.html -- 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
