delta/git.git/Documentation/git-pack-objects.txt, branch nd/pretty-commit-log-message

Use parentheses and `...' where appropriate

2010-10-08T19:31:07+00:00

Remove some stray usage of other bracket types and asterisks for the
same purpose.

Signed-off-by: Štěpán Němec 
Acked-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano

Use angles for placeholders consistently

2010-10-08T19:29:52+00:00

Signed-off-by: Štěpán Němec 
Acked-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano

pack-objects documentation: Fix --honor-pack-keep as well.

2010-02-25T03:10:22+00:00

Signed-off-by: Nelson Elhage 
Signed-off-by: Junio C Hamano

pack-objects documentation: reword "objects that appear in the standard input"

2010-02-24T23:41:27+00:00

These were written back when we always read objects from the standard
input.  These days --revs and its friends can feed only the start and
end points and have the command internally enumerate the objects.

Signed-off-by: Junio C Hamano

Documentation: pack-objects: Clarify --local's semantics.

2010-02-20T17:24:19+00:00

The current documentation suggests that --local also ignores any
objects in local packs, which is incorrect. Change the language to be
clearer and more parallel to the other options that ignore objects.

While we're at it, fix a trivial error in --incremental's
documentation.

Signed-off-by: Nelson Elhage 
Signed-off-by: Junio C Hamano

Documentation: describe --thin more accurately

2010-02-19T01:13:18+00:00

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 .

Signed-off-by: Stephen Boyd 
Signed-off-by: Junio C Hamano

docs: don't talk about $GIT_DIR/refs/ everywhere

2010-02-18T05:40:09+00:00

It is misleading to say that we pull refs from $GIT_DIR/refs/*, because we
may also consult the packed refs mechanism. These days we tend to treat
the "refs hierarchy" as more of an abstract namespace that happens to be
represented as $GIT_DIR/refs. At best, this is a minor inaccuracy, but at
worst it can confuse users who then look in $GIT_DIR/refs and find that it
is missing some of the refs they expected to see.

This patch drops most uses of "$GIT_DIR/refs/*", changing them into just
"refs/*", under the assumption that users can handle the concept of an
abstract refs namespace. There are a few things to note:

  - most cases just dropped the $GIT_DIR/ portion. But for cases where
    that left _just_ the word "refs", I changed it to "refs/" to help
    indicate that it was a hierarchy.  I didn't do the same for longer
    paths (e.g., "refs/heads" remained, instead of becoming
    "refs/heads/").

  - in some cases, no change was made, as the text was explicitly about
    unpacked refs (e.g., the discussion in git-pack-refs).

  - In some cases it made sense instead to note the existence of packed
    refs (e.g., in check-ref-format and rev-parse).

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano

make --max-pack-size argument to 'git pack-object' count in bytes

2010-02-04T04:39:56+00:00

The value passed to --max-pack-size used to count in MiB which was
inconsistent with the corresponding configuration variable as well as
other command arguments which are defined to count in bytes with an
optional unit suffix.  This brings --max-pack-size in line with the
rest of Git.

Also, in order not to cause havoc with people used to the previous
megabyte scale, and because this is a sane thing to do anyway, a
minimum size of 1 MiB is enforced to avoid an explosion of pack files.

Adjust and extend test suite accordingly.

Signed-off-by: Nicolas Pitre 
Signed-off-by: Junio C Hamano

Documentation: spell 'git cmd' without dash throughout

2010-01-10T12:01:28+00:00

The documentation was quite inconsistent when spelling 'git cmd' if it
only refers to the program, not to some specific invocation syntax:
both 'git-cmd' and 'git cmd' spellings exist.

The current trend goes towards dashless forms, and there is precedent
in 647ac70 (git-svn.txt: stop using dash-form of commands.,
2009-07-07) to actively eliminate the dashed variants.

Replace 'git-cmd' with 'git cmd' throughout, except where git-shell,
git-cvsserver, git-upload-pack, git-receive-pack, and
git-upload-archive are concerned, because those really live in the
$PATH.

pack-objects: split implications of --all-progress from progress activation

2009-11-24T05:33:09+00:00

Currently the --all-progress flag is used to use force progress display
during the writing object phase even if output goes to stdout which is
primarily the case during a push operation.  This has the unfortunate
side effect of forcing progress display even if stderr is not a
terminal.

Let's introduce the --all-progress-implied argument which has the same
intent except for actually forcing the activation of any progress
display.  With this, progress display will be automatically inhibited
whenever stderr is not a terminal, or full progress display will be
included otherwise.  This should let people use 'git push' within a cron
job without filling their logs with useless percentage displays.

Signed-off-by: Nicolas Pitre 
Tested-by: Jeff King 
Signed-off-by: Junio C Hamano