On Wed, Dec 10, 2014 at 11:49:49PM +, brian m. carlson wrote:
> From: "brian m. carlson"
>
> 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
From: "brian m. carlson"
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 controls the default f
On Thu, Dec 5, 2013 at 8:44 AM, 乙酸鋰 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 are stor
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...@vg
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
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
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, sw
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 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 ti
rstand no-thin will ignore it and send
> 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
>
On Wed, Nov 6, 2013 at 1:41 PM, Carlos Martín Nieto 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 rec
; OK, I agree that it sounds quite niche-y, 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.
I wonder
quivalent, there is no git object db that it can query for the missing
> base objects. I realise this is pretty a unusual situation.
OK, I agree that it sounds quite niche-y, but it still is sensible.
If a receiving end does not want to (this includes "it is incapable
of doing so", but d
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 c
Carlos Martín Nieto 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 yet, or
http://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-p
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
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-pac
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 serv
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 hav
_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
@@ -205,6 +205,8 @@ int send_pack(struct send_pack_args *args,
> > quiet_supported = 1;
> > if (server_supports("agent"))
> > agent_supported = 1;
> > + if (!server_supports("thin-pack"))
> > +
= 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 advertises "thi
ack(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;
if (!remote_refs) {
Signed-off-by: Nguyễn Thái Ngọc Duy
---
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
+++ b/builtin/unpack-objects.c
24 matches
Mail list logo
