git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Documentation: reword --thin description
@ 2010-02-10  5:14 Stephen Boyd
  2010-02-10 16:07 ` Nicolas Pitre
  2010-02-12  8:00 ` [PATCHv2] Documentation: describe --thin more accurately Stephen Boyd
  0 siblings, 2 replies; 11+ messages in thread
From: Stephen Boyd @ 2010-02-10  5:14 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---

Don't know if git-push needs to say that --thin is passed to send-pack.

 Documentation/git-fetch-pack.txt |    4 ++--
 Documentation/git-push.txt       |    6 +++---
 Documentation/git-send-pack.txt  |    4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
index e9952e8..2b4e4dd 100644
--- a/Documentation/git-fetch-pack.txt
+++ b/Documentation/git-fetch-pack.txt
@@ -44,8 +44,8 @@ OPTIONS
 	locked against repacking.
 
 --thin::
-	Spend extra cycles to minimize the number of objects to be sent.
-	Use it on slower connection.
+	Spend extra cycles minimizing the number of sent objects.
+	Use it with a slow connection.
 
 --include-tag::
 	If the remote side supports it, annotated tags objects will
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index bd79119..a14bc9c 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -141,9 +141,9 @@ useful if you write an alias or script around 'git push'.
 
 --thin::
 --no-thin::
-	These options are passed to 'git send-pack'.  Thin
-	transfer spends extra cycles to minimize the number of
-	objects to be sent and meant to be used on slower connection.
+	These options are passed to 'git send-pack'.  A thin
+	transfer spends extra cycles minimizing the number of
+	sent objects and is meant to be used with a slow connection.
 
 -v::
 --verbose::
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index 8178d92..0a78dac 100644
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git-send-pack.txt
@@ -48,8 +48,8 @@ OPTIONS
 	Run verbosely.
 
 --thin::
-	Spend extra cycles to minimize the number of objects to be sent.
-	Use it on slower connection.
+	Spend extra cycles minimizing the number of sent objects.
+	Use it with a slow connection.
 
 <host>::
 	A remote host to house the repository.  When this
-- 
1.7.0.rc2

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH] Documentation: reword --thin description
  2010-02-10  5:14 [PATCH] Documentation: reword --thin description Stephen Boyd
@ 2010-02-10 16:07 ` Nicolas Pitre
  2010-02-10 16:52   ` Stephen Boyd
  2010-02-10 18:59   ` Junio C Hamano
  2010-02-12  8:00 ` [PATCHv2] Documentation: describe --thin more accurately Stephen Boyd
  1 sibling, 2 replies; 11+ messages in thread
From: Nicolas Pitre @ 2010-02-10 16:07 UTC (permalink / raw)
  To: Stephen Boyd; +Cc: git, Junio C Hamano

On Tue, 9 Feb 2010, Stephen Boyd wrote:

>  --thin::
> -	Spend extra cycles to minimize the number of objects to be sent.
> -	Use it on slower connection.
> +	Spend extra cycles minimizing the number of sent objects.
> +	Use it with a slow connection.

Both the old and the new text are bollocks.

There is no extra cycles involved here.  And linking this to a slow 
connection is misleading.

The point of --thin is to create a pack containing delta objects while 
excluding the base objects they depend on when those objects are known 
to exist in the receiver's repository already.  Because base objects 
are usually significantly bigger than delta objects, this results in a 
large reduction in the amount of data to transfer.

However we don't allow a pack with delta objects referencing base 
objects to be stored in a Git repository if those base objects are not 
part of the same pack for robustness reasons.  Therefore, when a thin 
pack is transferred via the git protocol, the receiving end must 
"fatten" the pack by appending those missing base objects for that pack 
to be complete and valid.  This results in somewhat suboptimal object 
storage on the receiving end due to some object duplications.  Of course 
a simple gc will fix that.

These days --thin is always the default for a fetch.  We used to think 
that --thin might not be the best thing to do on a push given that the 
receiving end is typically a central server in that case and keeping 
storage low on a central server should be preferred.  But --thin turned 
out to be re-enabled by default for pushes by mistake on a few occasions 
when the affected code has been reworked.  No idea what state it is now, 
and I don't think that makes such a difference on the server in the end.


Nicolas

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Documentation: reword --thin description
  2010-02-10 16:07 ` Nicolas Pitre
@ 2010-02-10 16:52   ` Stephen Boyd
  2010-02-10 18:59   ` Junio C Hamano
  1 sibling, 0 replies; 11+ messages in thread
From: Stephen Boyd @ 2010-02-10 16:52 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git, Junio C Hamano

On 02/10/2010 08:07 AM, Nicolas Pitre wrote:
> Both the old and the new text are bollocks.
>
> There is no extra cycles involved here.  And linking this to a slow 
> connection is misleading.
>
> The point of --thin is to create a pack containing delta objects while 
> excluding the base objects they depend on when those objects are known 
> to exist in the receiver's repository already.  Because base objects 
> are usually significantly bigger than delta objects, this results in a 
> large reduction in the amount of data to transfer.

Thanks. Maybe this would more accurately describe the option?

Create a pack containing only delta objects when the base objects the
delta objects depend upon are present in the receiver's repository. This
typically results in less data being transferred. Default: on

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Documentation: reword --thin description
  2010-02-10 16:07 ` Nicolas Pitre
  2010-02-10 16:52   ` Stephen Boyd
@ 2010-02-10 18:59   ` Junio C Hamano
  2010-02-10 21:04     ` Nicolas Pitre
  1 sibling, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2010-02-10 18:59 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: Stephen Boyd, git

Nicolas Pitre <nico@fluxnic.net> writes:

> ....  But --thin turned 
> out to be re-enabled by default for pushes by mistake on a few occasions 
> when the affected code has been reworked.  No idea what state it is now, 
> and I don't think that makes such a difference on the server in the end.

Hmmmm... it's doubly bad that the maintainer does not recall these
few occasions that mistakes happened.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Documentation: reword --thin description
  2010-02-10 18:59   ` Junio C Hamano
@ 2010-02-10 21:04     ` Nicolas Pitre
  0 siblings, 0 replies; 11+ messages in thread
From: Nicolas Pitre @ 2010-02-10 21:04 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Stephen Boyd, git

On Wed, 10 Feb 2010, Junio C Hamano wrote:

> Nicolas Pitre <nico@fluxnic.net> writes:
> 
> > ....  But --thin turned 
> > out to be re-enabled by default for pushes by mistake on a few occasions 
> > when the affected code has been reworked.  No idea what state it is now, 
> > and I don't think that makes such a difference on the server in the end.
> 
> Hmmmm... it's doubly bad that the maintainer does not recall these
> few occasions that mistakes happened.

The default was changed in commit a4503a15af.  Seems that today --thin 
is on by default again.  I don't think we should care that much, 
especially as --thin would logically have to be the default when pushing 
to a bundle.  Obviously leaving it off for push and on for fetch is 
creating needless confusion.


Nicolas

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCHv2] Documentation: describe --thin more accurately
  2010-02-10  5:14 [PATCH] Documentation: reword --thin description Stephen Boyd
  2010-02-10 16:07 ` Nicolas Pitre
@ 2010-02-12  8:00 ` Stephen Boyd
  2010-02-12 17:36   ` Junio C Hamano
  2010-02-15 19:33   ` [PATCHv3] " Stephen Boyd
  1 sibling, 2 replies; 11+ messages in thread
From: Stephen Boyd @ 2010-02-12  8:00 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, Nicolas Pitre

The description for --thin was misleading and downright wrong. Correct
it with some inspiration from the description of index-pack's --fix-thin
and some background information from Nicolas Pitre <nico@fluxnic.net>.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---

Changes since v1:
 - No longer bollocks ;-)
 - Document --thin for pack-object

 Documentation/git-fetch-pack.txt   |    6 ++++--
 Documentation/git-index-pack.txt   |    4 ++--
 Documentation/git-pack-objects.txt |    8 ++++++++
 Documentation/git-push.txt         |    7 ++++---
 Documentation/git-send-pack.txt    |    6 ++++--
 5 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
index e9952e8..c428f6d 100644
--- a/Documentation/git-fetch-pack.txt
+++ b/Documentation/git-fetch-pack.txt
@@ -44,8 +44,10 @@ OPTIONS
 	locked against repacking.
 
 --thin::
-	Spend extra cycles to minimize the number of objects to be sent.
-	Use it on slower connection.
+	Fetch a "thin" pack, which records objects in deltified form based
+	on objects not included in the pack to reduce network traffic.
+	The excluded objects are expected to be present on the receiving
+	end.
 
 --include-tag::
 	If the remote side supports it, annotated tags objects will
diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt
index 65a301b..73fe51a 100644
--- a/Documentation/git-index-pack.txt
+++ b/Documentation/git-index-pack.txt
@@ -46,10 +46,10 @@ OPTIONS
 	'git repack'.
 
 --fix-thin::
-	It is possible for 'git pack-objects' to build
+	It is possible for 'git pack-objects' to build a
 	"thin" pack, which records objects in deltified form based on
 	objects not included in the pack to reduce network traffic.
-	Those objects are expected to be present on the receiving end
+	The excluded objects are expected to be present on the receiving end
 	and they must be included in the pack for that pack to be self
 	contained and indexable. Without this option any attempt to
 	index a thin pack will fail. This option only makes sense in
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index ffd5025..f32c322 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -179,6 +179,14 @@ base-name::
 	Add --no-reuse-object if you want to force a uniform compression
 	level on all data no matter the source.
 
+--thin::
+	Create a "thin" pack, which records objects in deltified form based
+	on objects not included in the pack to reduce network traffic.
+	The excluded objects are expected to be present on the receiving end
+	and eventually must be included in the pack for that pack to be self
+	contained and indexable. This option only makes sense in
+	conjunction with --stdout.
+
 --delta-base-offset::
 	A packed archive can express base object of a delta as
 	either 20-byte object name or as an offset in the
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index bd79119..c67b06c 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -141,9 +141,10 @@ useful if you write an alias or script around 'git push'.
 
 --thin::
 --no-thin::
-	These options are passed to 'git send-pack'.  Thin
-	transfer spends extra cycles to minimize the number of
-	objects to be sent and meant to be used on slower connection.
+	These options are passed to linkgit:git-send-pack[1]. A thin transfer
+	significantly reduces the number of sent objects when the sender and
+	receiver share many of the same objects in common. The default is
+	\--thin.
 
 -v::
 --verbose::
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index 8178d92..1d7c4d4 100644
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git-send-pack.txt
@@ -48,8 +48,10 @@ OPTIONS
 	Run verbosely.
 
 --thin::
-	Spend extra cycles to minimize the number of objects to be sent.
-	Use it on slower connection.
+	Send a "thin" pack, which records objects in deltified form based
+	on objects not included in the pack to reduce network traffic.
+	The excluded objects are expected to be present on the receiving
+	end.
 
 <host>::
 	A remote host to house the repository.  When this
-- 
1.7.0.rc2.28.gf476c0

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCHv2] Documentation: describe --thin more accurately
  2010-02-12  8:00 ` [PATCHv2] Documentation: describe --thin more accurately Stephen Boyd
@ 2010-02-12 17:36   ` Junio C Hamano
  2010-02-15 19:33   ` [PATCHv3] " Stephen Boyd
  1 sibling, 0 replies; 11+ messages in thread
From: Junio C Hamano @ 2010-02-12 17:36 UTC (permalink / raw)
  To: Stephen Boyd; +Cc: git, Nicolas Pitre

Stephen Boyd <bebarino@gmail.com> writes:

> The description for --thin was misleading and downright wrong. Correct
> it with some inspiration from the description of index-pack's --fix-thin
> and some background information from Nicolas Pitre <nico@fluxnic.net>.
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>

Looks better, but...

> diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
> index e9952e8..c428f6d 100644
> --- a/Documentation/git-fetch-pack.txt
> +++ b/Documentation/git-fetch-pack.txt
> @@ -44,8 +44,10 @@ OPTIONS
>  	locked against repacking.
>  
>  --thin::
> -	Spend extra cycles to minimize the number of objects to be sent.
> -	Use it on slower connection.
> +	Fetch a "thin" pack, which records objects in deltified form based
> +	on objects not included in the pack to reduce network traffic.
> +	The excluded objects are expected to be present on the receiving
> +	end.

It is useless and misleading to say "expected to be" for fetch-pack and
send-pack.  Imagine you are a first time reader of this documentation and
read the above.  Wouldn't it be very natural to ask yourself: "I want to
take advantage of reduced network traffic by using --thin.  How do I make
sure that my local repository (i.e. receiving end) satisfies that
expectation?"

The answer is, "nothing"---the protocol exchange ensures that condition.

> diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt
> index 65a301b..73fe51a 100644
> --- a/Documentation/git-index-pack.txt
> +++ b/Documentation/git-index-pack.txt
> @@ -46,10 +46,10 @@ OPTIONS
>  	'git repack'.
>  
>  --fix-thin::
> -	It is possible for 'git pack-objects' to build
> +	It is possible for 'git pack-objects' to build a
>  	"thin" pack, which records objects in deltified form based on
>  	objects not included in the pack to reduce network traffic.
> -	Those objects are expected to be present on the receiving end
> +	The excluded objects are expected to be present on the receiving end
>  	and they must be included in the pack for that pack to be self
>  	contained and indexable. Without this option any attempt to
>  	index a thin pack will fail. This option only makes sense in

This "expected to be present and they must be included" is correct, but
"running index-pack with this option is how you 'fix' the thin pack by
including them" is missing (not your patch's fault---but because you are
touching in the vicinity on this exact topic anyway...).

> diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
> index ffd5025..f32c322 100644
> --- a/Documentation/git-pack-objects.txt
> +++ b/Documentation/git-pack-objects.txt
> @@ -179,6 +179,14 @@ base-name::
>  	Add --no-reuse-object if you want to force a uniform compression
>  	level on all data no matter the source.
>  
> +--thin::
> +	Create a "thin" pack, which records objects in deltified form based
> +	on objects not included in the pack to reduce network traffic.
> +	The excluded objects are expected to be present on the receiving end
> +	and eventually must be included in the pack for that pack to be self
> +	contained and indexable. This option only makes sense in
> +	conjunction with --stdout.

Before using such a "thin" pack, the receiving end must add excluded
objects back to make it self-contained and indexable by running index-pack
with its --fix-thin option.

> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index bd79119..c67b06c 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -141,9 +141,10 @@ useful if you write an alias or script around 'git push'.
>  
>  --thin::
>  --no-thin::
> -	These options are passed to 'git send-pack'.  Thin
> -	transfer spends extra cycles to minimize the number of
> -	objects to be sent and meant to be used on slower connection.
> +	These options are passed to linkgit:git-send-pack[1]. A thin transfer
> +	significantly reduces the number of sent objects when the sender and
> +	receiver share many of the same objects in common. The default is
> +	\--thin.

It is sometimes true that "number of" send objects is reduced, but the
significant reduction comes from sending smaller amount of data.

If both sides start out with a file with 10000 lines, and you have two
commits since then, one adding a line A and then adding another line B on
top of it.  Without --thin, you would send the last version (10000
original lines plus A and B) in full and a delta that says "starting from
that version, delete line B", in order to represent the two versions (one
with addition of line A, the other with addition of both line A and B).
With --thin, you would instead send two deltas that say "starting from the
10000-line file you have, add line A" and "starting from that result, add
line B", without sending any full version.  The sent number of objects in
these two cases are the same (the version with A added, and the version
with both A and B added). 

> diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
> index 8178d92..1d7c4d4 100644
> --- a/Documentation/git-send-pack.txt
> +++ b/Documentation/git-send-pack.txt
> @@ -48,8 +48,10 @@ OPTIONS
>  	Run verbosely.
>  
>  --thin::
> -	Spend extra cycles to minimize the number of objects to be sent.
> -	Use it on slower connection.
> +	Send a "thin" pack, which records objects in deltified form based
> +	on objects not included in the pack to reduce network traffic.
> +	The excluded objects are expected to be present on the receiving
> +	end.

The same comment as fetch-pack one applies here.

Thanks.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCHv3] Documentation: describe --thin more accurately
  2010-02-12  8:00 ` [PATCHv2] Documentation: describe --thin more accurately Stephen Boyd
  2010-02-12 17:36   ` Junio C Hamano
@ 2010-02-15 19:33   ` Stephen Boyd
  2010-02-15 20:44     ` Junio C Hamano
  2010-02-18  9:10     ` [PATCHv4] " Stephen Boyd
  1 sibling, 2 replies; 11+ messages in thread
From: Stephen Boyd @ 2010-02-15 19:33 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, Nicolas Pitre

The description for --thin was misleading and downright wrong. Correct
it with some inspiration from the description of index-pack's --fix-thin
and some background information from Nicolas Pitre <nico@fluxnic.net>.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---

Changes since v2:
 - Address Junio's comments

 Documentation/git-fetch-pack.txt   |    4 ++--
 Documentation/git-index-pack.txt   |   11 ++++++-----
 Documentation/git-pack-objects.txt |    9 +++++++++
 Documentation/git-push.txt         |    7 ++++---
 Documentation/git-send-pack.txt    |    4 ++--
 5 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
index e9952e8..0ad94e3 100644
--- a/Documentation/git-fetch-pack.txt
+++ b/Documentation/git-fetch-pack.txt
@@ -44,8 +44,8 @@ OPTIONS
 	locked against repacking.
 
 --thin::
-	Spend extra cycles to minimize the number of objects to be sent.
-	Use it on slower connection.
+	Fetch a "thin" pack, which records objects in deltified form based
+	on objects not included in the pack to reduce network traffic.
 
 --include-tag::
 	If the remote side supports it, annotated tags objects will
diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt
index 65a301b..b4fa98e 100644
--- a/Documentation/git-index-pack.txt
+++ b/Documentation/git-index-pack.txt
@@ -46,14 +46,15 @@ OPTIONS
 	'git repack'.
 
 --fix-thin::
-	It is possible for 'git pack-objects' to build
+	It's possible for 'git pack-objects' to build a
 	"thin" pack, which records objects in deltified form based on
 	objects not included in the pack to reduce network traffic.
-	Those objects are expected to be present on the receiving end
+	The excluded objects are expected to be present on the receiving end
 	and they must be included in the pack for that pack to be self
-	contained and indexable. Without this option any attempt to
-	index a thin pack will fail. This option only makes sense in
-	conjunction with --stdin.
+	contained and indexable. This option fixes the "thin" pack by
+	adding the missing objects to the pack. Without this option any
+	attempt to index a "thin" pack will fail. This option only makes
+	sense in conjunction with --stdin.
 
 --keep::
 	Before moving the index into its final destination
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index ffd5025..fd9181a 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -179,6 +179,15 @@ base-name::
 	Add --no-reuse-object if you want to force a uniform compression
 	level on all data no matter the source.
 
+--thin::
+	Create a "thin" pack, which records objects in deltified form based
+	on objects not included in the pack to reduce network traffic.
+	The excluded objects are expected to be present on the receiving end
+	and eventually must be included in the pack for that pack to be self
+	contained and indexable (see the \--fix-thin option of
+	linkgit:git-index-pack[1] for more details). This option only makes
+	sense in conjunction with --stdout.
+
 --delta-base-offset::
 	A packed archive can express base object of a delta as
 	either 20-byte object name or as an offset in the
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index bd79119..c86ad29 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -141,9 +141,10 @@ useful if you write an alias or script around 'git push'.
 
 --thin::
 --no-thin::
-	These options are passed to 'git send-pack'.  Thin
-	transfer spends extra cycles to minimize the number of
-	objects to be sent and meant to be used on slower connection.
+	These options are passed to linkgit:git-send-pack[1]. A thin transfer
+	significantly reduces the amount of sent data when the sender and
+	receiver share many of the same objects in common. The default is
+	\--thin.
 
 -v::
 --verbose::
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index 8178d92..deaa7d9 100644
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git-send-pack.txt
@@ -48,8 +48,8 @@ OPTIONS
 	Run verbosely.
 
 --thin::
-	Spend extra cycles to minimize the number of objects to be sent.
-	Use it on slower connection.
+	Send a "thin" pack, which records objects in deltified form based
+	on objects not included in the pack to reduce network traffic.
 
 <host>::
 	A remote host to house the repository.  When this
-- 
1.7.0.17.g7e5eb

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCHv3] Documentation: describe --thin more accurately
  2010-02-15 19:33   ` [PATCHv3] " Stephen Boyd
@ 2010-02-15 20:44     ` Junio C Hamano
  2010-02-18  8:33       ` Stephen Boyd
  2010-02-18  9:10     ` [PATCHv4] " Stephen Boyd
  1 sibling, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2010-02-15 20:44 UTC (permalink / raw)
  To: Stephen Boyd; +Cc: git, Nicolas Pitre

Stephen Boyd <bebarino@gmail.com> writes:

> The description for --thin was misleading and downright wrong. Correct
> it with some inspiration from the description of index-pack's --fix-thin
> and some background information from Nicolas Pitre <nico@fluxnic.net>.
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---

Looking better, thanks.

> index 65a301b..b4fa98e 100644
> --- a/Documentation/git-index-pack.txt
> +++ b/Documentation/git-index-pack.txt
> @@ -46,14 +46,15 @@ OPTIONS
>  	'git repack'.
>  
>  --fix-thin::
> +	It's possible for 'git pack-objects' to build a
>  	"thin" pack, which records objects in deltified form based on
>  	objects not included in the pack to reduce network traffic.
> +	The excluded objects are expected to be present on the receiving end
>  	and they must be included in the pack for that pack to be self
> +	contained and indexable. This option fixes the "thin" pack by
> +	adding the missing objects to the pack. Without this option any
> +	attempt to index a "thin" pack will fail. This option only makes
> +	sense in conjunction with --stdin.

Assuming that the reader knows only what "git objects" are, and that a
"pack" contains "git objects" either in full or in a "deltified form based
on another object", the description needs to explain three points:

 - "self-containedness" requirement to be directly usable by git;
 - "thin" pack reduces transfer by violating "self-containedness"; and
 - "--fix-thin" makes "thin" into "self-contained".

I however think the first two points might be better covered by the
description of `--thin` of `pack-objects` and we should simply refer to it
from here, like this:

    --fix-thin::
            Make a "thin" pack produced by `git pack-objects --thin` (see
            linkgit:git-pack-objects[1] for details) directly usable by
            git, by adding objects that the objects stored in the
            deltified form are based on to the packfile.

And we can thicken the --thin description of pack-objects like this:

> +--thin::
> +	Create a "thin" pack, which records objects in deltified form based
> +	on objects not included in the pack to reduce network traffic.
> +	The excluded objects are expected to be present on the receiving end
> +	and eventually must be included in the pack for that pack to be self
> +	contained and indexable (see the \--fix-thin option of
> +	linkgit:git-index-pack[1] for more details). This option only makes
> +	sense in conjunction with --stdout.
> +

    --thin::
            Create a "thin" pack in order to reduce network transfer.
    +
    For a packfile to be usable directly by git, any object in the pack
    that is represented in the deltified form must be based on an object
    that exists in the same pack.  Such a pack is called "self-contained".
    +
    If the sender sends an object in the deltified form based on an object
    both the sender and the receiver have, but excludes the common object
    itself from the datastream, it can often reduce the network traffic
    dramatically.  Such a datastream is called a "thin" pack.
    +
    Note that a thin pack violates the self-containedness requirement and
    is not directly usable by git on the receiving end without making it a
    self-contained pack by running `git index-pack --fix-thin` (see
    linkgit:git-index-pack[1]).

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCHv3] Documentation: describe --thin more accurately
  2010-02-15 20:44     ` Junio C Hamano
@ 2010-02-18  8:33       ` Stephen Boyd
  0 siblings, 0 replies; 11+ messages in thread
From: Stephen Boyd @ 2010-02-18  8:33 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Nicolas Pitre

On 02/15/2010 12:44 PM, Junio C Hamano wrote:
> I however think the first two points might be better covered by the
> description of `--thin` of `pack-objects` and we should simply refer to it
> from here, like this:
>
>     --fix-thin::
>             Make a "thin" pack produced by `git pack-objects --thin` (see
>             linkgit:git-pack-objects[1] for details) directly usable by
>             git, by adding objects that the objects stored in the
>             deltified form are based on to the packfile.
>

This looks good. I'd like to avoid introducing the term packfile though
and just use pack throughout.

>     --thin::
>             Create a "thin" pack in order to reduce network transfer.
>     +
>     For a packfile to be usable directly by git, any object in the pack
>     that is represented in the deltified form must be based on an object
>     that exists in the same pack.  Such a pack is called "self-contained".
>     +
>     If the sender sends an object in the deltified form based on an object
>     both the sender and the receiver have, but excludes the common object
>     itself from the datastream, it can often reduce the network traffic
>     dramatically.  Such a datastream is called a "thin" pack.
>     +
>     Note that a thin pack violates the self-containedness requirement and
>     is not directly usable by git on the receiving end without making it a
>     self-contained pack by running `git index-pack --fix-thin` (see
>     linkgit:git-index-pack[1]).

This looks long winded. Perhaps we can do without explaining what
self-containedness is? If you read the second paragraph in the
description section of git-pack-objects.txt it tries to explain
self-contained:

    The packed archive format (.pack) is designed to be 
    self-contained so that it can be unpacked without
    any further information


If all I know is a pack contains objects and deltas based on other
objects I might be able to figure out that all the objects must be
present in the pack for it to be self-contained. This description
section might need some work but I don't think repeating ourselves in
--thin is good.

Updated patch to follow.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCHv4] Documentation: describe --thin more accurately
  2010-02-15 19:33   ` [PATCHv3] " Stephen Boyd
  2010-02-15 20:44     ` Junio C Hamano
@ 2010-02-18  9:10     ` Stephen Boyd
  1 sibling, 0 replies; 11+ messages in thread
From: Stephen Boyd @ 2010-02-18  9:10 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano, Nicolas Pitre

The description for --thin was misleading and downright wrong. Correct
it with some inspiration from the description of index-pack's --fix-thin
and some background information from Nicolas Pitre <nico@fluxnic.net>.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---

Changes since v3:
 - More heavily reworked git-pack-objects.txt
 - git-index-pack.txt got inspiration from Junio in round 3

 Documentation/git-fetch-pack.txt   |    4 +-
 Documentation/git-index-pack.txt   |   12 +++-------
 Documentation/git-pack-objects.txt |   37 +++++++++++++++++++++++------------
 Documentation/git-push.txt         |    7 +++--
 Documentation/git-send-pack.txt    |    4 +-
 5 files changed, 36 insertions(+), 28 deletions(-)

diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
index e9952e8..0ad94e3 100644
--- a/Documentation/git-fetch-pack.txt
+++ b/Documentation/git-fetch-pack.txt
@@ -44,8 +44,8 @@ OPTIONS
 	locked against repacking.
 
 --thin::
-	Spend extra cycles to minimize the number of objects to be sent.
-	Use it on slower connection.
+	Fetch a "thin" pack, which records objects in deltified form based
+	on objects not included in the pack to reduce network traffic.
 
 --include-tag::
 	If the remote side supports it, annotated tags objects will
diff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt
index 65a301b..f3ccc72 100644
--- a/Documentation/git-index-pack.txt
+++ b/Documentation/git-index-pack.txt
@@ -46,14 +46,10 @@ OPTIONS
 	'git repack'.
 
 --fix-thin::
-	It is possible for 'git pack-objects' to build
-	"thin" pack, which records objects in deltified form based on
-	objects not included in the pack to reduce network traffic.
-	Those objects are expected to be present on the receiving end
-	and they must be included in the pack for that pack to be self
-	contained and indexable. Without this option any attempt to
-	index a thin pack will fail. This option only makes sense in
-	conjunction with --stdin.
+	Fix a "thin" pack produced by `git pack-objects --thin` (see
+	linkgit:git-pack-objects[1] for details) by adding the
+	excluded objects the deltified objects are based on to the
+	pack. This option only makes sense in conjunction with --stdin.
 
 --keep::
 	Before moving the index into its final destination
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index ffd5025..1fe5a54 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -21,16 +21,21 @@ DESCRIPTION
 Reads list of objects from the standard input, and writes a packed
 archive with specified base-name, or to the standard output.
 
-A packed archive is an efficient way to transfer set of objects
-between two repositories, and also is an archival format which
-is efficient to access.  The packed archive format (.pack) is
-designed to be self contained so that it can be unpacked without
-any further information, but for fast, random access to the objects
-in the pack, a pack index file (.idx) will be generated.
-
-Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
+A packed archive is an efficient way to transfer a set of objects
+between two repositories as well as an access efficient archival
+format.  In a packed archive, an object is either stored as a
+compressed whole or as a difference from some other object.
+The latter is often called a delta.
+
+The packed archive format (.pack) is designed to be self-contained
+so that it can be unpacked without any further information. Therefore,
+each object that a delta depends upon must be present within the pack.
+
+A pack index file (.idx) is generated for fast, random access to the
+objects in the pack. Placing both the index file (.idx) and the packed
+archive (.pack) in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
 any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
-enables git to read from such an archive.
+enables git to read from the pack archive.
 
 The 'git unpack-objects' command can read the packed archive and
 expand the objects contained in the pack into "one-file
@@ -38,10 +43,6 @@ one-object" format; this is typically done by the smart-pull
 commands when a pack is created on-the-fly for efficient network
 transport by their peers.
 
-In a packed archive, an object is either stored as a compressed
-whole, or as a difference from some other object.  The latter is
-often called a delta.
-
 
 OPTIONS
 -------
@@ -179,6 +180,16 @@ base-name::
 	Add --no-reuse-object if you want to force a uniform compression
 	level on all data no matter the source.
 
+--thin::
+	Create a "thin" pack by omitting the common objects between a
+	sender and a receiver in order to reduce network transfer. This
+	option only makes sense in conjunction with --stdout.
++
+Note: A thin pack violates the packed archive format by omitting
+required objects and is thus unusable by git without making it
+self-contained. Use `git index-pack --fix-thin`
+(see linkgit:git-index-pack[1]) to restore the self-contained property.
+
 --delta-base-offset::
 	A packed archive can express base object of a delta as
 	either 20-byte object name or as an offset in the
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index bd79119..c86ad29 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -141,9 +141,10 @@ useful if you write an alias or script around 'git push'.
 
 --thin::
 --no-thin::
-	These options are passed to 'git send-pack'.  Thin
-	transfer spends extra cycles to minimize the number of
-	objects to be sent and meant to be used on slower connection.
+	These options are passed to linkgit:git-send-pack[1]. A thin transfer
+	significantly reduces the amount of sent data when the sender and
+	receiver share many of the same objects in common. The default is
+	\--thin.
 
 -v::
 --verbose::
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index 8178d92..deaa7d9 100644
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git-send-pack.txt
@@ -48,8 +48,8 @@ OPTIONS
 	Run verbosely.
 
 --thin::
-	Spend extra cycles to minimize the number of objects to be sent.
-	Use it on slower connection.
+	Send a "thin" pack, which records objects in deltified form based
+	on objects not included in the pack to reduce network traffic.
 
 <host>::
 	A remote host to house the repository.  When this
-- 
1.7.0.17.g7e5eb

^ permalink raw reply related	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2010-02-18  9:10 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-10  5:14 [PATCH] Documentation: reword --thin description Stephen Boyd
2010-02-10 16:07 ` Nicolas Pitre
2010-02-10 16:52   ` Stephen Boyd
2010-02-10 18:59   ` Junio C Hamano
2010-02-10 21:04     ` Nicolas Pitre
2010-02-12  8:00 ` [PATCHv2] Documentation: describe --thin more accurately Stephen Boyd
2010-02-12 17:36   ` Junio C Hamano
2010-02-15 19:33   ` [PATCHv3] " Stephen Boyd
2010-02-15 20:44     ` Junio C Hamano
2010-02-18  8:33       ` Stephen Boyd
2010-02-18  9:10     ` [PATCHv4] " Stephen Boyd

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).