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 pclo...@gmail.com
Date: Fri Jan 11 16:05:47
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
Matthijs Kooijman matth...@stdin.nl 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
Hi Junio,
On Tue, May 28, 2013 at 10:04:46AM -0700, Junio C Hamano wrote:
Matthijs Kooijman matth...@stdin.nl 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
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
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
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
Matthijs Kooijman matth...@stdin.nl 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:
Duy Nguyen pclo...@gmail.com writes:
On Tue, Jan 8, 2013 at 1:54 PM, Junio C Hamano gits...@pobox.com 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
Junio C Hamano gits...@pobox.com 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
On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano gits...@pobox.com 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
On 01/08/2013 03:28 PM, Duy Nguyen wrote:
On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano gits...@pobox.com 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
On Tue, Jan 8, 2013 at 9:32 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
On 01/08/2013 03:28 PM, Duy Nguyen wrote:
On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano gits...@pobox.com wrote:
Speaking of --depth, I think in Git 2.0 we should fix the semantics
of deepening done with git
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
Jonathan Nieder jrnie...@gmail.com 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
On Tue, Jan 8, 2013 at 1:06 AM, Stefan Beller
stefanbel...@googlemail.com 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
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com 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
On Tue, Jan 8, 2013 at 1:54 PM, Junio C Hamano gits...@pobox.com 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
18 matches
Mail list logo
