From: brian m. carlson brian.carl...@cpanel.net
Thin packs are enabled when pushing by default, but with a large number
of refs and a fast network, git may spend more time trying to find a
good delta than it would spend simply sending data over the network.
Add a per-remote option, pushThin, that
On Wed, Dec 10, 2014 at 11:49:49PM +, brian m. carlson wrote:
From: brian m. carlson brian.carl...@cpanel.net
Thin packs are enabled when pushing by default, but with a large number
of refs and a fast network, git may spend more time trying to find a
good delta than it would spend simply
Hi,
What are the difference between pre 1.8.5 and 1.8.5 about thin pack support?
Could you describe thin pack?
From the doc, it says --thin is default option. Is that true?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
On Thu, Dec 5, 2013 at 8:44 AM, 乙酸鋰 ch3co...@gmail.com wrote:
What are the difference between pre 1.8.5 and 1.8.5 about thin pack support?
No idea.
Could you describe thin pack?
It gets a bit technical. Under the hood objects are deltified, only
the differences between an object and its base
On Wed, 2013-11-06 at 15:42 -0800, Shawn Pearce wrote:
On Wed, Nov 6, 2013 at 1:41 PM, Carlos Martín Nieto c...@elego.de wrote:
On Wed, 2013-11-06 at 12:32 -0800, Junio C Hamano wrote:
I'll queue these for now, but I doubt the wisdom of this series,
given that the ship has already sailed
Up to now git has assumed that all servers are able to fix thin
packs. This is however not always the case.
Document the 'no-thin' capability and prevent send-pack from generating
a thin pack if the server advertises it.
---
This is a re-roll of the series I sent earlier this month, switching
On Sat, 2013-11-23 at 17:07 +0100, Carlos Martín Nieto wrote:
Up to now git has assumed that all servers are able to fix thin
packs. This is however not always the case.
Document the 'no-thin' capability and prevent send-pack from generating
a thin pack if the server advertises it.
Sorry
On Sat, Nov 23, 2013 at 05:07:55PM +0100, Carlos Martín Nieto wrote:
Up to now git has assumed that all servers are able to fix thin
packs. This is however not always the case.
Document the 'no-thin' capability and prevent send-pack from generating
a thin pack if the server advertises
upload-pack has long advertised thin-pack, letting the clients request
these smaller packs. The client however unconditionally assumes that a
server is able to fix thin packs and there is no way of telling the
client that this is in fact not the case.
Make receive-pack advertise 'thin-pack
In combination a the previous patch making receive-pack advertise the
thin-pack capability, this allows git to push to a server in a
constrained environment which is not able to fix thin packs while taking
advantage of the feature for servers which can.
Signed-off-by: Carlos Martín Nieto c
://thread.gmane.org/gmane.comp.version-control.git/235766/focus=236402
Carlos Martín Nieto (2):
receive-pack: advertise thin-pack
send-pack: only send a thin pack if the server supports it
Documentation/technical/protocol-capabilities.txt | 20 +++-
builtin/receive-pack.c
Carlos Martín Nieto c...@elego.de writes:
Hi all,
This comes as a result of the discussion starting at [0] about
git-push assuming that a server will always support thin packs. Most
out there in fact do, but this isn't necessarily the case.
Some implementations may not have support for it
On Wed, 2013-11-06 at 12:32 -0800, Junio C Hamano wrote:
I'll queue these for now, but I doubt the wisdom of this series,
given that the ship has already sailed long time ago.
Currently, no third-party implementation of a receiving end can
accept thin push, because thin push is not a
, but it still is sensible.
If a receiving end does not want to (this includes it is incapable
of doing so, but does not have to be limited to) complete a thin
pack, the series will give it such an option in the longer term.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git
.
If a receiving end does not want to (this includes it is incapable
of doing so, but does not have to be limited to) complete a thin
pack, the series will give it such an option in the longer term.
I wonder if we want to make the flag go in the opposite direction, then.
Right now we have no flag, and we
On Wed, Nov 6, 2013 at 1:41 PM, Carlos Martín Nieto c...@elego.de wrote:
On Wed, 2013-11-06 at 12:32 -0800, Junio C Hamano wrote:
I'll queue these for now, but I doubt the wisdom of this series,
given that the ship has already sailed long time ago.
Currently, no third-party implementation of
a thin pack. This is the same as now, and the same as step 2 above.
3. An upgraded send-pack will understand no-thin and do as the server
asks.
So an upgraded client and server can start cooperating immediately, and
we do not have to wait for the long assumption time to pass before
On Tue, 2013-10-08 at 15:22 -0700, Jonathan Nieder wrote:
Duy Nguyen wrote:
Or maybe it's not that late. How about you go with your patch and add
thin-pack capability to receive-pack too?
When new git push is used against old server, thin pack is disabled.
But that's not a big deal (I
send_pack_args *args,
quiet_supported = 1;
if (server_supports(agent))
agent_supported = 1;
+ if (!server_supports(thin-pack))
+ args-use_thin_pack = 0;
if (!remote_refs) {
fprintf(stderr, No refs in common and none
;
if (server_supports(agent))
agent_supported = 1;
+ if (!server_supports(thin-pack))
+ args-use_thin_pack = 0;
Hmm.. I think this introduces a regression in C Git because
receive-pack never advertises thin-pack and so git push from now
on will never send thin packs
@@ int send_pack(struct send_pack_args *args,
quiet_supported = 1;
if (server_supports(agent))
agent_supported = 1;
+ if (!server_supports(thin-pack))
+ args-use_thin_pack = 0;
Hmm.. I think this introduces a regression in C Git
send_pack_args *args,
quiet_supported = 1;
if (server_supports(agent))
agent_supported = 1;
+ if (!server_supports(thin-pack))
+ args-use_thin_pack = 0;
Hmm.. I think this introduces a regression in C Git because
receive-pack never
Duy Nguyen wrote:
Or maybe it's not that late. How about you go with your patch and add
thin-pack capability to receive-pack too?
When new git push is used against old server, thin pack is disabled.
But that's not a big deal (I hope).
Could we have separate patches to introduce the server
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/unpack-objects.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c
index 6d0a65c..c9eb31d 100644
--- a/builtin/unpack-objects.c
+++
24 matches
Mail list logo
