Re: [PATCH] git clone depth of 0 not possible.
Hi Junio, > While implementing the above, I noticed my fix now introduced an > off-by-one error the other way. When investigating, I found this commit: > > commit 682c7d2f1a2d1a5443777237450505738af2ff1a > Author: Nguyễn Thái Ngọc Duy > Date: Fri Jan 11 16:05:47 2013 +0700 > > upload-pack: fix off-by-one depth calculation in shallow clone > > get_shallow_commits() is used to determine the cut points at a given > depth (i.e. the number of commits in a chain that the user likes to > get). However we count current depth up to the commit "commit" but > we > do the cutting at its parents (i.e. current depth + 1). This makes > upload-pack always return one commit more than requested. This patch > fixes it. > > Signed-off-by: Nguyễn Thái Ngọc Duy > Signed-off-by: Junio C Hamano > > Which actually seems to fix the off-by-one bug that is described in this > thread, but without going through the hoops of preserving current > behaviour for older git versions (that is, it makes behaviour dependent > on server version instead of client version). > > Does this mean the discussion in this thread is meaningless, or is that > commit not intended to be the final fix? Looking more closely, I also see that the above change is already released in 1.8.2 versions. Given that, I don't think it makes sense to to still try to provide this capability to get backward compatible behaviour, since this would cause a off-by-one error the other way when talking to 1.8.2.x servers... However, since I pretty much finished the code for this, I'll send over the patches and let you decide wether to include them or not. If you want to include them but they need to be changed in some way, just let me know. The first patch of the series should be merged regardless. Gr. Matthijs -- 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: [PATCH] git clone depth of 0 not possible.
Hi Junio, > Doing it "correctly" (in the shorter term) would involve: > > - adding a capability on the sending side "fixed-off-by-one-depth" >to the protocol, and teaching the sending side to advertise the >capability; > > - teaching the requestor that got --depth=N from the end user to >pay attention to the new capability in such a way that: > >- when talking to an old sender (i.e. without the off-by-one > fix), send N-1 for N greater than 1. Punt on N==1; > >- when talking to a fixed sender, ask to enable the capability, > and send N as is (including N==1). > > - teaching the sending side to see if the new behaviour to fix >off-by-one is asked by the requestor, and stop at the correct >number of commits, not oversending one more. Otherwise retain >the old behaviour. While implementing the above, I noticed my fix now introduced an off-by-one error the other way. When investigating, I found this commit: commit 682c7d2f1a2d1a5443777237450505738af2ff1a Author: Nguyễn Thái Ngọc Duy Date: Fri Jan 11 16:05:47 2013 +0700 upload-pack: fix off-by-one depth calculation in shallow clone get_shallow_commits() is used to determine the cut points at a given depth (i.e. the number of commits in a chain that the user likes to get). However we count current depth up to the commit "commit" but we do the cutting at its parents (i.e. current depth + 1). This makes upload-pack always return one commit more than requested. This patch fixes it. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano Which actually seems to fix the off-by-one bug that is described in this thread, but without going through the hoops of preserving current behaviour for older git versions (that is, it makes behaviour dependent on server version instead of client version). Does this mean the discussion in this thread is meaningless, or is that commit not intended to be the final fix? In any case, IIUC that particular patch makes a piece of the existing code dead, which needs to be removed. Gr. Matthijs -- 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: [PATCH] git clone depth of 0 not possible.
Matthijs Kooijman writes: >> Doing it "correctly" (in the shorter term) would involve: > > Given below suggestion, I take it you don't like what Jonathan proposed > (changing the meaning of the deepen parameter in the protocol so that > the server effectively decides how to interpret --depth)? Correct. > We can implement these two in current git already, since they only > add to the protocol, not break it in an incompatible manner, right? Correct. >> - teaching the requestor that got --depth=N from the end user to >>pay attention to the new capability in such a way that: >> >>- when talking to an old sender (i.e. without the off-by-one >> fix), send N-1 for N greater than 1. Punt on N==1; >> >>- when talking to a fixed sender, ask to enable the capability, >> and send N as is (including N==1). > And these should wait for git2, since they change the meaning of the > --depth parameter? Or is this change ok for current git as well? My suggestion was based on the understanding that everybody agreed that the current behaviour of --depth=1 to have one extra commit behind the shallow "snapshot" aka "poor-man's tarball", is a *bug* to be fixed, so I didn't mean it as a "backward incompatible change" at all. > What do you mean by "punt" exactly? As old senders can only send a history with 2 or more commits deep, it would be sensible for the receiver to warn the user that we are buggily asking for one more than the user asked for to the sender, and fetch history with two commits. It would be a regression to error it out. >> In the longer term, I think we should introduce a better deepening >> mechanism. Cf. > Even when there will be a better deepening mechanism, the above is still > useful (passing --depth=1 serves to get just a single commit without > history, which is a distinct usecase from deepening the history of an > existing shallow repository). Correct. That is why I said "in the longer term, we should introduce". Did I say "introduce and replace with it"? -- 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: [PATCH] git clone depth of 0 not possible.
Hi Junio, On Tue, May 28, 2013 at 10:04:46AM -0700, Junio C Hamano wrote: > Matthijs Kooijman writes: > > > Did you consider how to implement this? Looking at the code, it seems > > the "deepen" parameter in the wire protocol now means: > > - 0: Do not change anything about the shallowness (i.e., fetch > >everything from the shallow root to the tip). > > - > 0: Create new shallow commits at depth commits below the tip (so > >depth == 1 means tip and one below). > > - INFINITE_DEPTH (0x7fff): Remove all shallowness and fetch > >complete history. > > > > Given this, I'm not sure how one can express "fetch the tip and nothing > > below that", since depth == 0 already has a different meaning. > > Doing it "correctly" (in the shorter term) would involve: Given below suggestion, I take it you don't like what Jonathan proposed (changing the meaning of the deepen parameter in the protocol so that the server effectively decides how to interpret --depth)? > - adding a capability on the sending side "fixed-off-by-one-depth" >to the protocol, and teaching the sending side to advertise the >capability; > > - teaching the sending side to see if the new behaviour to fix >off-by-one is asked by the requestor, and stop at the correct >number of commits, not oversending one more. Otherwise retain >the old behaviour. We can implement these two in current git already, since they only add to the protocol, not break it in an incompatible manner, right? > - teaching the requestor that got --depth=N from the end user to >pay attention to the new capability in such a way that: > >- when talking to an old sender (i.e. without the off-by-one > fix), send N-1 for N greater than 1. Punt on N==1; > >- when talking to a fixed sender, ask to enable the capability, > and send N as is (including N==1). And these should wait for git2, since they change the meaning of the --depth parameter? Or is this change ok for current git as well? What do you mean by "punt" exactly? Show an error to the user, saying only depth >= 2 is supported? > In the longer term, I think we should introduce a better deepening > mechanism. Cf. Even when there will be a better deepening mechanism, the above is still useful (passing --depth=1 serves to get just a single commit without history, which is a distinct usecase from deepening the history of an existing shallow repository). In other words, I think the "improved deepening" and "fixed depth" should be complementary features. Gr. Matthijs -- 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: [PATCH] git clone depth of 0 not possible.
Matthijs Kooijman writes: > Did you consider how to implement this? Looking at the code, it seems > the "deepen" parameter in the wire protocol now means: > - 0: Do not change anything about the shallowness (i.e., fetch >everything from the shallow root to the tip). > - > 0: Create new shallow commits at depth commits below the tip (so >depth == 1 means tip and one below). > - INFINITE_DEPTH (0x7fff): Remove all shallowness and fetch >complete history. > > Given this, I'm not sure how one can express "fetch the tip and nothing > below that", since depth == 0 already has a different meaning. Doing it "correctly" (in the shorter term) would involve: - adding a capability on the sending side "fixed-off-by-one-depth" to the protocol, and teaching the sending side to advertise the capability; - teaching the requestor that got --depth=N from the end user to pay attention to the new capability in such a way that: - when talking to an old sender (i.e. without the off-by-one fix), send N-1 for N greater than 1. Punt on N==1; - when talking to a fixed sender, ask to enable the capability, and send N as is (including N==1). - teaching the sending side to see if the new behaviour to fix off-by-one is asked by the requestor, and stop at the correct number of commits, not oversending one more. Otherwise retain the old behaviour. In the longer term, I think we should introduce a better deepening mechanism. Cf. http://thread.gmane.org/gmane.comp.version-control.git/212912/focus=212940 > Of course, one could using depth == 1 in this case to receive two > commits and then drop one, but this would seem a bit pointless to me > (especially if the commit below the tip is very different from the tip > leading to a lot of useless data transfer). -- 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: [PATCH] git clone depth of 0 not possible.
Matthijs Kooijman wrote: > In other words: we won't break existing clients if we suddenly send back > one less commit than before, since the client just sends over what it > wants and then assumes that whatever it gets back is really what it > wanted? Yes, depending on your definition of "break". An advantage of that approach is that old clients would get the new, intuitive behavior without upgrading. A disadvantage is that it is a confusing world where the same command produces different effects when contacting different servers. -- 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: [PATCH] git clone depth of 0 not possible.
Hi Jonathan, > > Did you consider how to implement this? Looking at the code, it seems > > the "deepen" parameter in the wire protocol now means: > > - 0: Do not change anything about the shallowness (i.e., fetch > >everything from the shallow root to the tip). > > - > 0: Create new shallow commits at depth commits below the tip (so > >depth == 1 means tip and one below). > > - INFINITE_DEPTH (0x7fff): Remove all shallowness and fetch > >complete history. > > > > Given this, I'm not sure how one can express "fetch the tip and nothing > > below that", since depth == 0 already has a different meaning. > > If I remember correctly, what we discussed is just changing the > protocol to "5 means a depth of 5". The mail from Junio I replied to said: > >> As long as we do not change the meaning of the "shallow" count > >> going over the wire Which seems to conflict with your suggestion. Or are the "shallow count" and the "depth" different things? > The client already trusts what the server provides. In other words: we won't break existing clients if we suddenly send back one less commit than before, since the client just sends over what it wants and then assumes that whatever it gets back is really what it wanted? Gr. Matthijs -- 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: [PATCH] git clone depth of 0 not possible.
Jonathan Nieder wrote: > If I remember correctly, what we discussed is just changing the > protocol to "5 means a depth of 5". The client already trusts what the > server provides. (Or tweaking the protocol by adding a new capability, if unpredictable behavior based on the version of the server won't fly. :)) Jonathan -- 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: [PATCH] git clone depth of 0 not possible.
Matthijs Kooijman wrote: > Did you consider how to implement this? Looking at the code, it seems > the "deepen" parameter in the wire protocol now means: > - 0: Do not change anything about the shallowness (i.e., fetch >everything from the shallow root to the tip). > - > 0: Create new shallow commits at depth commits below the tip (so >depth == 1 means tip and one below). > - INFINITE_DEPTH (0x7fff): Remove all shallowness and fetch >complete history. > > Given this, I'm not sure how one can express "fetch the tip and nothing > below that", since depth == 0 already has a different meaning. If I remember correctly, what we discussed is just changing the protocol to "5 means a depth of 5". The client already trusts what the server provides. Thanks and hope that helps, Jonathan -- 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: [PATCH] git clone depth of 0 not possible.
Hi Junio, I'm interested in getting a fetch tip commit only feature into git, I'll probably look into creating a patch for this. > >>> Sounds buggy. Would anything break if we were to make --depth=1 mean > >>> "1 deep, including the tip commit"? > >> > >> As long as we do not change the meaning of the "shallow" count going > >> over the wire (i.e. the number we receive from the user will be > >> fudged, so that user's "depth 1" that used to mean "the tip and one > >> behind it" is expressed as "depth 2" at the end-user level, and we > >> send over the wire the number that corresponded to the old "depth > >> 1"), I do not think anything will break, and then --depth=0 may > >> magically start meaning "only the tip; its immediate parents will > >> not be transferred and recorded as the shallow boundary in the > >> receiving repository". > > > > I'd rather we reserve 0 for unlimited fetch, something we haven't done > > so far [1]. And because "unlimited clone" with --depth does not make > > sense, --depth=0 should be rejected by git-clone. > > I actually was thinking about changing --depth=1 to mean "the tip, > with zero commits behind it" (and that was consistent with my > description of "fudging"), but ended up saying "--depth=0" by > mistake. I too think "--depth=0" or "--depth<0" does not make > sense, so we are in agreement. Did you consider how to implement this? Looking at the code, it seems the "deepen" parameter in the wire protocol now means: - 0: Do not change anything about the shallowness (i.e., fetch everything from the shallow root to the tip). - > 0: Create new shallow commits at depth commits below the tip (so depth == 1 means tip and one below). - INFINITE_DEPTH (0x7fff): Remove all shallowness and fetch complete history. Given this, I'm not sure how one can express "fetch the tip and nothing below that", since depth == 0 already has a different meaning. Of course, one could using depth == 1 in this case to receive two commits and then drop one, but this would seem a bit pointless to me (especially if the commit below the tip is very different from the tip leading to a lot of useless data transfer). Or did I misunderstand something here? Gr. Matthijs -- 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: [PATCH] git clone depth of 0 not possible.
Stefan Beller writes: > On 01/08/2013 03:28 PM, Duy Nguyen wrote: >> On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano wrote: >>> Speaking of --depth, I think in Git 2.0 we should fix the semantics >>> of "deepening" done with "git fetch". >> >> Speaking of 2.0, we should support depth per ref. Well we don't have >> to wait until 2.0 because we could just add shallow2 extension to the >> pack protocol. We should also apply depth to new refs when fetching >> them the first time. > > Would this mean I could do something along? > $ git clone --since v1.8.0 git://github.com/gitster/git.git > > So tags would be allowed as anchors? As the end-user facing UI, I think it would be much easier to use for users who want to get only the recent part of history that is relevant to their development if you allowed them to ask "starting from this one, I do not care anything older than that" with such an interface. The current "count how many more generations you want" interface is crazy in that it forces you to count what you have not even seen; I suspect the only reason it was done in such a hacky manner was implementation expediency. At the syntax level, however, I do not think we can use --since there, because the keyword has a very different meaning already. I personally do not think "depth per ref" deserves "it would be nice to support in 2.0", let alone "2.0 *should* support", label. Some may find it an interesting mental exercise to think about corner cases it will introduce and have to deal with (e.g. you ask 100 from master and 2 from maint, but maint is behind master by less than 100---what should happen?), but I do not particularly see any practical use cases, and I highly doubt that there is much value in bringing in extra complexity such a "feature" requires to do it right. -- 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: [PATCH] git clone depth of 0 not possible.
On Tue, Jan 8, 2013 at 9:32 PM, Stefan Beller wrote: > On 01/08/2013 03:28 PM, Duy Nguyen wrote: >> On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano wrote: >>> Speaking of --depth, I think in Git 2.0 we should fix the semantics >>> of "deepening" done with "git fetch". >> >> Speaking of 2.0, we should support depth per ref. Well we don't have >> to wait until 2.0 because we could just add shallow2 extension to the >> pack protocol. We should also apply depth to new refs when fetching >> them the first time. >> > > Would this mean I could do something along? > $ git clone --since v1.8.0 git://github.com/gitster/git.git > > So tags would be allowed as anchors? No. This is what I had in mind: git clone --branch=master --depth=2 git.git # get branch master with depth 2 git fetch --depth=10 origin next# get branch next with depth 10 # master's depth remains 2 git fetch origin# get (new) branch 'pu' with default depth 2 But your case is interesting. We could specify --depth=v1.8.0.. or even --depth=v1.8.0~200.. (200 commits before v1.8.0). Somebody may even go crazy and make --depth=v1.6.0..v1.8.0 work. --depth is probably not the right name anymore. Any SHA-1 would be allowed as anchor. But I think we need to wait for reachability bitmap feature to come first so that we can quickly verify the anchor is reachable from the public refs. -- 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: [PATCH] git clone depth of 0 not possible.
On 01/08/2013 03:28 PM, Duy Nguyen wrote: > On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano wrote: >> Speaking of --depth, I think in Git 2.0 we should fix the semantics >> of "deepening" done with "git fetch". > > Speaking of 2.0, we should support depth per ref. Well we don't have > to wait until 2.0 because we could just add shallow2 extension to the > pack protocol. We should also apply depth to new refs when fetching > them the first time. > Would this mean I could do something along? $ git clone --since v1.8.0 git://github.com/gitster/git.git So tags would be allowed as anchors? -- 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: [PATCH] git clone depth of 0 not possible.
On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano wrote: > Speaking of --depth, I think in Git 2.0 we should fix the semantics > of "deepening" done with "git fetch". Speaking of 2.0, we should support depth per ref. Well we don't have to wait until 2.0 because we could just add shallow2 extension to the pack protocol. We should also apply depth to new refs when fetching them the first time. -- 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: [PATCH] git clone depth of 0 not possible.
Junio C Hamano writes: > I think we need a protocol update to fix this; instead of sending > "Now I want your tips and N commits behind it, please update my > shallow bottom accordingly", which creates the above by giving you Z > and 3 generations back and updates your cut-off point to W, the > receiving end should be able to ask "I have a shallow history that > cuts off at these commits. I want to get the history leading up to > your tips, and also deepen the history further back from my current > cut-off points by N commits", so that you would instead end up with > something like this: > > (you) > o---o---o---A---B---C---D---E---F---...---W---X---Y---Z > > That is, truly "deepen my history by 3". We could call that "git > fetch --deepen=3" or something. I take that back. If you start from > (upstream) > ---o---o---o---A---B > > (you) > A---B and you are interested in peeking the history a bit deeper, you should be able to ask "I have a shallow history that cuts off at these commits. I want my history deepened by N commits. I do not care where your current tips are, by the way." with git fetch --deepen=3 and end up with > (you) > o---o---o---A---B without getting the new history leading to the updated tip at the upstream. If you want the new history leading to the updated tip, you can just say: git fetch without any --depth nor --deepen option to end up with: > (you) > A---B---C---D---E---F---...---W---X---Y---Z instead. -- 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: [PATCH] git clone depth of 0 not possible.
Duy Nguyen writes: > On Tue, Jan 8, 2013 at 1:54 PM, Junio C Hamano wrote: >>> Sounds buggy. Would anything break if we were to make --depth=1 mean >>> "1 deep, including the tip commit"? >> >> As long as we do not change the meaning of the "shallow" count going >> over the wire (i.e. the number we receive from the user will be >> fudged, so that user's "depth 1" that used to mean "the tip and one >> behind it" is expressed as "depth 2" at the end-user level, and we >> send over the wire the number that corresponded to the old "depth >> 1"), I do not think anything will break, and then --depth=0 may >> magically start meaning "only the tip; its immediate parents will >> not be transferred and recorded as the shallow boundary in the >> receiving repository". > > I'd rather we reserve 0 for unlimited fetch, something we haven't done > so far [1]. And because "unlimited clone" with --depth does not make > sense, --depth=0 should be rejected by git-clone. I actually was thinking about changing --depth=1 to mean "the tip, with zero commits behind it" (and that was consistent with my description of "fudging"), but ended up saying "--depth=0" by mistake. I too think "--depth=0" or "--depth<0" does not make sense, so we are in agreement. Thanks for a sanity check. -- 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: [PATCH] git clone depth of 0 not possible.
On Tue, Jan 8, 2013 at 1:54 PM, Junio C Hamano wrote: >> Sounds buggy. Would anything break if we were to make --depth=1 mean >> "1 deep, including the tip commit"? > > As long as we do not change the meaning of the "shallow" count going > over the wire (i.e. the number we receive from the user will be > fudged, so that user's "depth 1" that used to mean "the tip and one > behind it" is expressed as "depth 2" at the end-user level, and we > send over the wire the number that corresponded to the old "depth > 1"), I do not think anything will break, and then --depth=0 may > magically start meaning "only the tip; its immediate parents will > not be transferred and recorded as the shallow boundary in the > receiving repository". I'd rather we reserve 0 for unlimited fetch, something we haven't done so far [1]. And because "unlimited clone" with --depth does not make sense, --depth=0 should be rejected by git-clone. [1] If we don't want to break the protocol, we could make depth 0x a special value as "unlimited" for newer git. Older git works most of the time, until some project exceeds 4G commit depth history. -- 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: [PATCH] git clone depth of 0 not possible.
Duy Nguyen writes: > If we choose not to do the off-by-one topic Junio suggested elsewhere > in the same thread, I think this document patch should be turned into > code instead. Just reject --depth=0 with an explanation. Users who are > hit by this will be caught without the need to read through the > document. I thought --depth=0 was a way to explicitly say "I do not want any shallow history" so far, so we would need to be a bit more careful, though. -- 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: [PATCH] git clone depth of 0 not possible.
Junio C Hamano writes: > Jonathan Nieder writes: > >> Stefan Beller wrote: >> >>> Currently it is not possible to have a shallow depth of >>> just 0, i.e. only one commit in that repository after cloning. >>> The minimum number of commits is 2, caused by depth=1. >> >> Sounds buggy. Would anything break if we were to make --depth=1 mean >> "1 deep, including the tip commit"? > > As long as we do not change the meaning of the "shallow" count going > over the wire (i.e. the number we receive from the user will be > fudged, so that user's "depth 1" that used to mean "the tip and one > behind it" is expressed as "depth 2" at the end-user level, and we > send over the wire the number that corresponded to the old "depth > 1"), I do not think anything will break, and then --depth=0 may > magically start meaning "only the tip; its immediate parents will > not be transferred and recorded as the shallow boundary in the > receiving repository". > > I do not mind carrying such a (technially) backward incompatible > change in jn/clone-2.0-depth-off-by-one branch, keep it cooking in > 'next' for a while and push it out together with other "2.0" topics > in a future release ;-). Speaking of --depth, I think in Git 2.0 we should fix the semantics of "deepening" done with "git fetch". Its "--depth" parameter is used to specify the new depth of the history that you can tangle from the updated tip of remote tracking branches, and it has a rather unpleasant ramifications. Suppose you start from "git clone --depth=1 $there". You have the today's snapshot, and one parent behind it. You keep working happily with the code and then realize that you want to know a bit more history behind the snapshot you started from. (upstream) ---o---o---o---A---B (you) A---B So you do: $ git fetch --depth=3 (upstream) ---o---o---o---A---B---C---D---E---F---...---W---X---Y---Z (you) A---B W---X---Y---Z But in the meantime, if the upstream accumulated 20+ commits, you end up getting the commit at the updated tip of the upstream, and 3 generations of parents behind it. There will be a 10+ commit worth of gap between the bottom of the new shallow history and the old tip you have been working on, and the history becomes disjoint. I think we need a protocol update to fix this; instead of sending "Now I want your tips and N commits behind it, please update my shallow bottom accordingly", which creates the above by giving you Z and 3 generations back and updates your cut-off point to W, the receiving end should be able to ask "I have a shallow history that cuts off at these commits. I want to get the history leading up to your tips, and also deepen the history further back from my current cut-off points by N commits", so that you would instead end up with something like this: (you) o---o---o---A---B---C---D---E---F---...---W---X---Y---Z That is, truly "deepen my history by 3". We could call that "git fetch --deepen=3" or something. -- 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: [PATCH] git clone depth of 0 not possible.
On Tue, Jan 8, 2013 at 1:06 AM, Stefan Beller wrote: > Currently it is not possible to have a shallow depth of > just 0, i.e. only one commit in that repository after cloning. > The minimum number of commits is 2, caused by depth=1. > > I had no good idea how to add this behavior to git clone as > the depth variable in git_transport_options struct (file transport.h) > uses value 0 for another meaning, so it would have need changes at > all places, where the transport options depth is being used > (e.g. fetch) > > So I documented the current behavior, see attached patch. If we choose not to do the off-by-one topic Junio suggested elsewhere in the same thread, I think this document patch should be turned into code instead. Just reject --depth=0 with an explanation. Users who are hit by this will be caught without the need to read through the document. -- 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: [PATCH] git clone depth of 0 not possible.
Jonathan Nieder writes: > Stefan Beller wrote: > >> Currently it is not possible to have a shallow depth of >> just 0, i.e. only one commit in that repository after cloning. >> The minimum number of commits is 2, caused by depth=1. > > Sounds buggy. Would anything break if we were to make --depth=1 mean > "1 deep, including the tip commit"? As long as we do not change the meaning of the "shallow" count going over the wire (i.e. the number we receive from the user will be fudged, so that user's "depth 1" that used to mean "the tip and one behind it" is expressed as "depth 2" at the end-user level, and we send over the wire the number that corresponded to the old "depth 1"), I do not think anything will break, and then --depth=0 may magically start meaning "only the tip; its immediate parents will not be transferred and recorded as the shallow boundary in the receiving repository". I do not mind carrying such a (technially) backward incompatible change in jn/clone-2.0-depth-off-by-one branch, keep it cooking in 'next' for a while and push it out together with other "2.0" topics in a future release ;-). -- 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: [PATCH] git clone depth of 0 not possible.
Stefan Beller wrote: > Currently it is not possible to have a shallow depth of > just 0, i.e. only one commit in that repository after cloning. > The minimum number of commits is 2, caused by depth=1. Sounds buggy. Would anything break if we were to make --depth=1 mean "1 deep, including the tip commit"? -- 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
