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
>
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 use
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)?
C
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
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 shal
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".
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
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 w
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 shallo
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
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. We
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 sho
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 unti
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 t
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
> r
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 numbe
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 w
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
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 anyth
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
>
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 --dept
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
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 transpo
23 matches
Mail list logo
