The fixes focuses on improving the HTML output. Most noteworthy:
- Fix the Makefile to also make various *.html files depend on
included files.
- Consistently use 'NOTE: ...' instead of '[ ... ]' for additional
info.
- Fix ending '::' for description lists in OPTION section etc.
- Fix paragraphs in description lists ending up as preformated text.
- Always use listingblocks (preformatted text wrapped in lines with -----)
for examples that span empty lines, so they are put in only one HTML
block.
- Use '1.' instead of '(1)' for numbered lists.
- Fix linking to other GIT docs.
- git-rev-list.txt: put option descriptions in an OPTION section.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
maint
Jonas Fonseca20 years agocommitted byJunio C Hamano
@ -229,10 +229,10 @@ does rename or copy would not show in the output, and if the
@@ -229,10 +229,10 @@ does rename or copy would not show in the output, and if the
"o-file.c", it would find the commit that changed the statement
when it was in "o-file.c".
[ BTW, the current versions of "git-diff-tree -C" is not eager
NOTE: The current versions of "git-diff-tree -C" is not eager
enough to find copies, and it will miss the fact that a-file.c
was created by copying o-file.c unless o-file.c was somehow
changed in the same commit.]
changed in the same commit.
You can use the --pickaxe-all flag in addition to the -S flag.
This causes the differences from all the files contained in
@ -243,6 +243,6 @@ that contain this changed "if" statement:
@@ -243,6 +243,6 @@ that contain this changed "if" statement:
nitfol();
}' --pickaxe-all
[ Side note. This option is called "--pickaxe-all" because -S
NOTE: This option is called "--pickaxe-all" because -S
option is internally called "pickaxe", a tool for software
@ -254,11 +254,11 @@ As an example, typical orderfile for the core GIT probably
@@ -254,11 +254,11 @@ As an example, typical orderfile for the core GIT probably
@ -86,8 +86,8 @@ the more useful of the two in that what it does can't be emulated with
@@ -86,8 +86,8 @@ the more useful of the two in that what it does can't be emulated with
a "git-write-tree" + "git-diff-tree". Thus that's the default mode.
The non-cached version asks the question:
show me the differences between HEAD and the currently checked out
tree - index contents _and_ files that aren't up-to-date
show me the differences between HEAD and the currently checked out
tree - index contents _and_ files that aren't up-to-date
which is obviously a very useful question too, since that tells you what
you *could* commit. Again, the output matches the "git-diff-tree -r"
@ -107,13 +107,13 @@ not up-to-date and may contain new stuff. The all-zero sha1 means that to
@@ -107,13 +107,13 @@ not up-to-date and may contain new stuff. The all-zero sha1 means that to
get the real diff, you need to look at the object in the working directory
directly rather than do an object-to-object diff.
NOTE! As with other commands of this type, "git-diff-index" does not
NOTE: As with other commands of this type, "git-diff-index" does not
actually look at the contents of the file at all. So maybe
`kernel/sched.c` hasn't actually changed, and it's just that you
touched it. In either case, it's a note that you need to
"git-upate-cache" it to make the cache be in sync.
NOTE 2! You can have a mixture of files show up as "has been updated"
NOTE: You can have a mixture of files show up as "has been updated"
and "is still dirty in the working directory" together. You can always
tell which file is in which state, since the "has been updated" ones
show a valid sha1, and the "not in sync with the index" ones will
@ -22,65 +22,69 @@ that point. Their parents are implied. "git-rev-list foo bar ^baz" thus
@@ -22,65 +22,69 @@ that point. Their parents are implied. "git-rev-list foo bar ^baz" thus
means "list all the commits which are included in 'foo' and 'bar', but
not in 'baz'".
If *--pretty* is specified, print the contents of the commit changesets
in human-readable form.
The *--objects* flag causes 'git-rev-list' to print the object IDs of
any object referenced by the listed commits. 'git-rev-list --objects foo
^bar' thus means "send me all object IDs which I need to download if
I have the commit object 'bar', but not 'foo'".
The *--bisect* flag limits output to the one commit object which is
roughly halfway between the included and excluded commits. Thus,
if 'git-rev-list --bisect foo ^bar
^baz' outputs 'midpoint', the output
of 'git-rev-list foo ^midpoint' and 'git-rev-list midpoint
^bar
^baz'
would be of roughly the same length. Finding the change which introduces
a regression is thus reduced to a binary search: repeatedly generate and
test new 'midpoint's until the commit chain is of length one.
If *--merge-order* is specified, the commit history is decomposed into a
unique sequence of minimal, non-linear epochs and maximal, linear epochs.
Non-linear epochs are then linearised by sorting them into merge order, which
is described below.
OPTIONS
-------
--pretty::
Print the contents of the commit changesets in human-readable form.
--objects::
Print the object IDs of any object referenced by the listed commits.
'git-rev-list --objects foo ^bar' thus means "send me all object IDs
which I need to download if I have the commit object 'bar', but
not 'foo'".
--bisect::
Limit output to the one commit object which is roughly halfway
between the included and excluded commits. Thus, if 'git-rev-list
--bisect foo ^bar ^baz' outputs 'midpoint', the output
of 'git-rev-list foo ^midpoint' and 'git-rev-list midpoint
^bar ^baz' would be of roughly the same length. Finding the change
which introduces a regression is thus reduced to a binary search:
repeatedly generate and test new 'midpoint's until the commit chain
is of length one.
--merge-order::
When specified the commit history is decomposed into a unique
sequence of minimal, non-linear epochs and maximal, linear epochs.
Non-linear epochs are then linearised by sorting them into merge
order, which is described below.
+
Maximal, linear epochs correspond to periods of sequential development.
Minimal, non-linear epochs correspond to periods of divergent development
followed by a converging merge. The theory of epochs is described in more
@ -21,35 +21,37 @@ The header of the email is configurable by command line options. If not
@@ -21,35 +21,37 @@ The header of the email is configurable by command line options. If not
specified on the command line, the user will be prompted with a ReadLine
enabled interface to provide the necessary information.
OPTIONS
-------
The options available are:
--to
--to::
Specify the primary recipient of the emails generated.
Generally, this will be the upstream maintainer of the
project involved.
--from
--from::
Specify the sender of the emails. This will default to
the value GIT_COMMITTER_IDENT, as returned by "git-var -l".
The user will still be prompted to confirm this entry.
--compose
--compose::
Use \$EDITOR to edit an introductory message for the
patch series.
--subject
--subject::
Specify the initial subject of the email thread.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
--in-reply-to
--in-reply-to::
Specify the contents of the first In-Reply-To header.
Subsequent emails will refer to the previous email
instead of this if --chain-reply-to is set (the default)
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
--chain-reply-to, --no-chain-reply-to
--chain-reply-to, --no-chain-reply-to::
If this is set, each email will be sent as a reply to the previous
email sent. If disabled with "--no-chain-reply-to", all emails after
the first will be sent as replies to the first email sent. When using
@ -57,7 +59,7 @@ The options available are:
@@ -57,7 +59,7 @@ The options available are:
entire patch series.
Default is --chain-reply-to
--smtp-server
--smtp-server::
If set, specifies the outgoing SMTP server to use. Defaults to
Jonas Fonseca
20 years ago
committed by