doc: log takes multiple revision ranges
PATCH 1/1 doc: log takes multiple revision ranges
From: Philippe Blain <[email protected]>
git log accepts multiple revision ranges, but makes no mention of that in its documentation. Currently readers have to go to the git rev-list documentation to discover this useful feature.
Mention it and adjust the synopsys in the doc and in the short help for git log.
Also add links to the documentation for git rev-list and git diff instead of simply mentioning them, to make it easier for readers to reach these documentation pages. Let's link to git diff as this is the porcelain command, and the rest of the family (diff-index, diff-tree and diff-files) are mentioned in the "Raw output format" section of the git diff documentation.
---
doc: log takes multiple revision ranges
I hesitated to send this in two patches but decided not to, if it would be preferred I'll split it.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-590%2Fphil-blain%2Fdoc-log-multiple-ranges-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-590/phil-blain/doc-log-multiple-ranges-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/590
Documentation/git-log.txt | 12 ++++++------ builtin/log.c | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-)
Documentation/git-log.txt +6 -6
@@ -9,15 +9,15 @@ git-log - Show commit logs SYNOPSIS -------- [verse] -'git log' [<options>] [<revision range>] [[--] <path>...] +'git log' [<options>] [<revision range>...] [[--] <path>...] DESCRIPTION ----------- Shows the commit logs. -The command takes options applicable to the `git rev-list` +The command takes options applicable to the linkgit:git-rev-list[1] command to control what is shown and how, and options applicable to -the `git diff-*` commands to control how the changes +the linkgit:git-diff[1] family of commands to control how the changes each commit introduces are shown.
@@ -90,9 +90,9 @@ include::line-range-format.txt[] <revision range> is specified, it defaults to `HEAD` (i.e. the whole history leading to the current commit). `origin..HEAD` specifies all the commits reachable from the current commit - (i.e. `HEAD`), but not from `origin`. For a complete list of - ways to spell <revision range>, see the 'Specifying Ranges' - section of linkgit:gitrevisions[7]. + (i.e. `HEAD`), but not from `origin`. You can give more than + one revision range. For a complete list of ways to spell <revision range>, + see the 'Specifying Ranges' section of linkgit:gitrevisions[7]. [--] <path>...:: Show only commits that are enough to explain how the files
builtin/log.c +1 -1
@@ -53,7 +53,7 @@ static const char *fmt_patch_subject_prefix = "PATCH";static const char *fmt_pretty;static const char *const builtin_log_usage[] = { -N_ ("git log [<options>] [<revision-range>] [[--] <path>...]" ), +N_ ("git log [<options>] [<revision-range>...] [[--] <path>...]" ),N_ ("git show [<options>] <object>..." ),NULL };
base-commit: 076cbdcd739aeb33c1be87b73aebae5e43d7bcc5
Signature · 1 line
gitgitgadget
Quoted 5 lines · Philippe Blain via GitGitGadget
From: Philippe Blain <[email protected]>
git logaccepts multiple revision ranges, but makes no mention of that in its documentation. Currently readers have to go to thegit rev-listdocumentation to discover this useful feature.
I have a mixed feeling about this change. Surely you can write
git log v1.0..v2.0 v4.0..v5.0 -- Makefile
and you can explain that the command appears to take two "ranges", but I do not think we want to encourage it to those who do not understand what the above actually *means*.
Specifially, it does *NOT* list commits between v1.0 and v2.0, or between v4.0 and v5.0, that touch the path Makefile. In other words, you didn't really give two ranges with the syntax. What the A..B notation means could be called a range, only when it appears alone.
And we have *no* intention of changing the semantics.
"A..B" is a mere short-hand for ^A B, and it may appear to be a range, but "A..B C..D" does not make "two ranges". It still merely is a short-hand for ^A B ^C D, and if C reaches A and B (in the above example, v4.0 is very likely to reach both v1.0 and v2.0), it means the same thing as "C..D", i.e. "git log v4.0..v5.0 -- Makefile".
So I have a mildly strong opinion against the change to the synopsys and the short-help; it is a bad change that does not help users. If there are not sufficient explanation on the equivalence between A..B and ^A B on "git log" documentation but there is one elsewhere, adding a reference to help users learn is very much appreciated, though, and I initially was hoping that the second hunk of this patch was such a change, but it appears that it is not (it just adds the misleading "you can have more than one" without making readers aware of what it means to write "A..B C..D").
Thanks.
Hi Junio,
Quoted 18 lines · Junio C Hamano
Quoted 5 lines · Philippe Blain via GitGitGadget
From: Philippe Blain <[email protected]>
git logaccepts multiple revision ranges, but makes no mention of that in its documentation. Currently readers have to go to thegit rev-listdocumentation to discover this useful feature.I have a mixed feeling about this change. Surely you can write
git log v1.0..v2.0 v4.0..v5.0 -- Makefileand you can explain that the command appears to take two "ranges", but I do not think we want to encourage it to those who do not understand what the above actually *means*.
Quoted 7 lines
Specifially, it does *NOT* list commits between v1.0 and v2.0, or between v4.0 and v5.0, that touch the path
Makefile. In other words, you didn't really give two ranges with the syntax. What the A..B notation means could be called a range, only when it appears alone.And we have *no* intention of changing the semantics.
Of course, I understand.
Quoted 6 lines
"A..B" is a mere short-hand for ^A B, and it may appear to be a range, but "A..B C..D" does not make "two ranges". It still merely is a short-hand for ^A B ^C D, and if C reaches A and B (in the above example, v4.0 is very likely to reach both v1.0 and v2.0), it means the same thing as "C..D", i.e. "git log v4.0..v5.0 --
Makefile".
Yes, you are right.
Quoted 6 lines
So I have a mildly strong opinion against the change to the synopsys and the short-help; it is a bad change that does not help users. If there are not sufficient explanation on the equivalence between A..B and ^A B on "git log" documentation but there is one elsewhere, adding a reference to help users learn is very much appreciated, though,
So the 'git log' documentation states:
origin..HEAD specifies all the commits reachable from the current commit (i.e. HEAD), but not from origin. For a complete list of ways to spell <revision range>, see the Specifying Ranges section of gitrevisions[7].
What I wanted to achieve with this patch is to make readers aware that they can write e.g.
git log branch1 branch2 branch3 branch4 --not master
to see commits on each of branch1-4, that are not on master, since this is not immediately obvious (at least to me)
in the 'git log' man page. Even following the link to gitrevisions[7], it is not explicitly mentioned in the "Specifying Ranges" section that a range denotes the set of all commits reachable by all given refs, minus the ones reachable by all given refs prefixed by '^' or '--not'. However, this is really clear in the 'git rev-list' documentation, which uses '<commit>...' in the synopsis
and clearly talks about the "set of commits" point of view:
You can think of this as a set operation. Commits given on the command line form a set of commits that are reachable from any of them, and then commits reachable from any of the ones given with ^ in front are subtracted from that set. The remaining commits are what comes out in the command’s output. Various other options and paths parameters can be used to further limit the result.
Do you think it would be appropriate that this explanation could somehow also appear in the 'git log' (and maybe also 'gitrevisions') documentation ?
Thanks for the quick feedback,
Philippe.
Quoted 4 lines · Philippe Blain
However, this is really clear in the 'git rev-list' documentation, which uses '<commit>...' in the synopsis
and clearly talks about the "set of commits" point of view:
Quoted 8 lines
You can think of this as a set operation. Commits given on the command line form a set of commits that are reachable from any of them, and then commits reachable from any of the ones given with ^ in front are subtracted from that set. The remaining commits are what comes out in the command’s output. Various other options and paths parameters can be used to further limit the result.
Do you think it would be appropriate that this explanation could somehow also appear in the 'git log' (and maybe also 'gitrevisions') documentation ?
Thanks for finding that paragraph.
I said in my previous message that I didn't think the synopsis and short-help changes were bad, and I hoped that the other hunk of the patch added reference to "git log" page that existed elsewhere to help readers understand what the positive and negative options do. A reference to the "set operation" is exactly the kind of addition I meant I hoped to see.
By the way, I do not write "git log ab/topic-1 cd/topic-2 --not master", but "git log ^master ab/topic-1 cd/topic-2 ef/topic-3" is something I'd quite often write.
Hi Philippe,
This had been sitting in my inbox..
Quoted 10 lines · Philippe Blain
Hi Junio,
Quoted 9 lines · Junio C Hamano
Quoted 5 lines · Philippe Blain via GitGitGadget
From: Philippe Blain <[email protected]>
git logaccepts multiple revision ranges, but makes no mention of that in its documentation. Currently readers have to go to thegit rev-listdocumentation to discover this useful feature.
I'd concur that sometime the documentation is not as educationally informative as it could be. Often it leaves readers to second guess what is meant, or redirects to other reference sections with similar presumptions that the reader already understands. Documentation is harder than coding because of these differences in writing style. Often Git appears to prefer the normative standard style.
Quoted 35 lines
Quoted 8 lines
I have a mixed feeling about this change. Surely you can write
git log v1.0..v2.0 v4.0..v5.0 -- Makefileand you can explain that the command appears to take two "ranges", but I do not think we want to encourage it to those who do not understand what the above actually *means*.
Quoted 7 lines
Specifially, it does *NOT* list commits between v1.0 and v2.0, or between v4.0 and v5.0, that touch the path
Makefile. In other words, you didn't really give two ranges with the syntax. What the A..B notation means could be called a range, only when it appears alone.And we have *no* intention of changing the semantics.
Of course, I understand.
Quoted 5 lines
"A..B" is a mere short-hand for ^A B, and it may appear to be a range, but "A..B C..D" does not make "two ranges". It still merely is a short-hand for ^A B ^C D, and if C reaches A and B (in the above example, v4.0 is very likely to reach both v1.0 and v2.0), it means the same thing as "C..D", i.e. "git log v4.0..v5.0 --
Makefile".Yes, you are right.
Quoted 5 lines
So I have a mildly strong opinion against the change to the synopsys and the short-help; it is a bad change that does not help users. If there are not sufficient explanation on the equivalence between A..B and ^A B on "git log" documentation but there is one elsewhere, adding a reference to help users learn is very much appreciated, though,
So the 'git log' documentation states:
origin..HEAD specifies all the commits reachable from the current commit (i.e. HEAD), but not from origin. For a complete list of ways to spell <revision range>, see the Specifying Ranges section of gitrevisions[7].
Quoted 8 lines
What I wanted to achieve with this patch is to make readers aware that they can write e.g.
git log branch1 branch2 branch3 branch4 --not masterto see commits on each of branch1-4, that are not on master, since this is not immediately obvious (at least to me) in the 'git log' man page.
The whole revision walk stuff is tricky. Finding the right starting point for explanations is key, along with picking out where 'normal' errors are made, as these do help users who aren't simply 'checking the manual'. (the 20-20 hindsight problem)
For example, your "that are not on master", and what that means, needs to be brought out to the new reader rather than being buried mid-sentence. Most readers will miss those mid-sentence key points and they can't learn until they have some significant problem that points it out to them. Sometime we need to point at the 'wrong' things, not just the right things. (e.g. if branch3 had ben merged a couple of revisions ago...)
Quoted 8 lines
Even following the link to gitrevisions[7],
it is not explicitly mentioned in the "Specifying Ranges" section that a range denotes the set of all commits reachable by all given refs, minus the ones reachable by all given refs prefixed by '^' or '--not'. However, this is really clear in the 'git rev-list' documentation, which uses '<commit>...' in the synopsis
and clearly talks about the "set of commits" point of view:
Quoted 6 lines
You can think of this as a set operation. Commits given on the command line form a set of commits that are reachable from any of them, and then commits reachable from any of the ones given with ^ in front are subtracted from that set. The remaining commits are what comes out in the command’s output. Various other options and paths parameters can be used to further limit the result.
Set operations don't help everyone, just sayin'.
In some cases: The fact that we exclude any commit reachable from any of the "^" commits should be mentioned first, and then we select any left that are reachable from the named tips. This puts a different spin on the understanding, and helps catch those that have not understood the other descriptions. It can then be easily linked to the 'two ranges' case producing otherwise unexpected results.
Quoted 5 lines
Do you think it would be appropriate that this explanation could somehow also appear in the 'git log' (and maybe also 'gitrevisions') documentation ?
Thanks for the quick feedback,
Philippe.
Philip
Hi Philip,
Quoted 5 lines · Philip Oakley
Hi Philippe,
This had been sitting in my inbox..
-----8<-----
Quoted 15 lines
Quoted 9 lines
What I wanted to achieve with this patch is to make readers aware that they can write e.g.
git log branch1 branch2 branch3 branch4 --not masterto see commits on each of branch1-4, that are not on master, since this is not immediately obvious (at least to me) in the 'git log' man page.
The whole revision walk stuff is tricky. Finding the right starting point for explanations is key, along with picking out where 'normal' errors are made, as these do help users who aren't simply 'checking the manual'. (the 20-20 hindsight problem)
Quoted 7 lines
For example, your "that are not on master", and what that means, needs to be brought out to the new reader rather than being buried mid-sentence. Most readers will miss those mid-sentence key points and they can't learn until they have some significant problem that points it out to them. Sometime we need to point at the 'wrong' things, not just the right things. (e.g. if branch3 had ben merged a couple of revisions ago...)
Yes, here I meant "on master" in the "not yet merged into master" sense, of course. I'd be more careful if I was writing a commit message or part of the doc itself.
Quoted 15 lines
Quoted 9 lines
Even following the link to gitrevisions[7],
it is not explicitly mentioned in the "Specifying Ranges" section that a range denotes the set of all commits reachable by all given refs, minus the ones reachable by all given refs prefixed by '^' or '--not'. However, this is really clear in the 'git rev-list' documentation, which uses '<commit>...' in the synopsis
and clearly talks about the "set of commits" point of view:Quoted 6 lines
You can think of this as a set operation. Commits given on the command line form a set of commits that are reachable from any of them, and then commits reachable from any of the ones given with ^ in front are subtracted from that set. The remaining commits are what comes out in the command’s output. Various other options and paths parameters can be used to further limit the result.
Quoted 8 lines
Set operations don't help everyone, just sayin'.
In some cases: The fact that we exclude any commit reachable from any of the "^" commits should be mentioned first, and then we select any left that are reachable from the named tips. This puts a different spin on the understanding, and helps catch those that have not understood the other descriptions. It can then be easily linked to the 'two ranges' case producing otherwise unexpected results.
I'll try to tweak the wording for v3.
Thanks,
Philippe.
Quoted 24 lines · Junio C Hamano
Quoted 5 lines · Philippe Blain via GitGitGadget
From: Philippe Blain <[email protected]>
git logaccepts multiple revision ranges, but makes no mention of that in its documentation. Currently readers have to go to thegit rev-listdocumentation to discover this useful feature.I have a mixed feeling about this change. Surely you can write
git log v1.0..v2.0 v4.0..v5.0 -- Makefileand you can explain that the command appears to take two "ranges", but I do not think we want to encourage it to those who do not understand what the above actually *means*.
Specifially, it does *NOT* list commits between v1.0 and v2.0, or between v4.0 and v5.0, that touch the path
Makefile. In other words, you didn't really give two ranges with the syntax. What the A..B notation means could be called a range, only when it appears alone.And we have *no* intention of changing the semantics.
Quoted 8 lines
"A..B" is a mere short-hand for ^A B, and it may appear to be a range, but "A..B C..D" does not make "two ranges". It still merely is a short-hand for ^A B ^C D, and if C reaches A and B (in the above example, v4.0 is very likely to reach both v1.0 and v2.0), it means the same thing as "C..D", i.e. "git log v4.0..v5.0 --
Makefile".So I have a mildly strong opinion against the change to the synopsys and the short-help; it is a bad change that does not help users.
I second this opinion. I think that reading:
[<revision range> [...]]
is very misleading. It guides the reader to think that they can specify multiple ranges, but does not provide clear guidance about how multiple ranges are interpreted. I think most readers will naturally assume that the interpretation is "take the union of each provided range", but this is not the case as Junio points out.
Quoted 7 lines
If there are not sufficient explanation on the equivalence between A..B and ^A B on "git log" documentation but there is one elsewhere, adding a reference to help users learn is very much appreciated, though, and I initially was hoping that the second hunk of this patch was such a change, but it appears that it is not (it just adds the misleading "you can have more than one" without making readers aware of what it means to write "A..B C..D").
I think the documentation is probably clearer as it is. Having this extra explanation about the difference between the two doesn't guarantee that it will be read, so it may just be adding additional complexity that isn't warranted ;).
Quoted 1 line
Thanks.
Thanks,
Taylor
v2 cover doc: include git rev-list description in git log doc
In reply to Philippe Blain via GitGitGadgetThis series moves the nice explanation in the 'Description' section of the git rev-list man page to a separate file and includes this file in the git log man page.
This goal is to make readers more aware that they can write e.g.
git log branch1 branch2 branch3 branch4 --not master
to see commits on each of branch1-4, that are not on master, since this is not immediately obvious (at least to me) in the git log man page.
Note that I made several commits for ease of reviewing, I'll squash some if this would be preferred.
Changes since v1: took a completely different approach following the comments received from Junio and Taylor.
Philippe Blain (4):
git-log.txt: add links to 'rev-list' and 'diff' docs git-rev-list.txt: move description to separate file git-log.txt: include rev-list-description.txt rev-list-description.txt: fix Asciidoc syntax
Documentation/git-log.txt | 7 ++- Documentation/git-rev-list.txt | 40 +---------------- Documentation/rev-list-description.txt | 61 ++++++++++++++++++++++++++ 3 files changed, 68 insertions(+), 40 deletions(-) create mode 100644 Documentation/rev-list-description.txt
base-commit: a08a83db2bf27f015bec9a435f6d73e223c21c5e
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-590%2Fphil-blain%2Fdoc-log-multiple-ranges-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-590/phil-blain/doc-log-multiple-ranges-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/590
Range-diff vs v1:
1: 16b8cdb55c ! 1: 59c48282a0 doc: log takes multiple revision ranges
@@ Metadata
Author: Philippe Blain <[email protected]>
## Commit message ##
- doc: log takes multiple revision ranges
+ git-log.txt: add links to 'rev-list' and 'diff' docs
- git log accepts multiple revision ranges, but makes no mention of that
- in its documentation. Currently readers have to go to the `git
- rev-list` documentation to discover this useful feature.
-
- Mention it and adjust the synopsys in the doc and in the short
- help for git log.
-
- Also add links to the documentation for git rev-list and git diff
+ Add links to the documentation for git rev-list and git diff
instead of simply mentioning them, to make it easier for readers to reach these documentation pages. Let's link to git diff as this is the porcelain command, and the rest of the family (diff-index, diff-tree and
@@ Commit message
## Documentation/git-log.txt ##
-@@ Documentation/git-log.txt: git-log - Show commit logs
- SYNOPSIS
- --------
- [verse]
--'git log' [<options>] [<revision range>] [[--] <path>...] -+'git log' [<options>] [<revision range>...] [[--] <path>...] -
- DESCRIPTION
+@@ Documentation/git-log.txt: DESCRIPTION
-----------
Shows the commit logs.
@@ Documentation/git-log.txt: git-log - Show commit logs
each commit introduces are shown.
-@@ Documentation/git-log.txt: include::line-range-format.txt[]
- <revision range> is specified, it defaults to HEAD (i.e. the
- whole history leading to the current commit). origin..HEAD
- specifies all the commits reachable from the current commit
-- (i.e. HEAD), but not from origin. For a complete list of
-- ways to spell <revision range>, see the 'Specifying Ranges'
-- section of linkgit:gitrevisions[7].
-+ (i.e. HEAD), but not from origin. You can give more than
-+ one revision range. For a complete list of ways to spell <revision range>,
-+ see the 'Specifying Ranges' section of linkgit:gitrevisions[7].
-
- [--] <path>...::
- Show only commits that are enough to explain how the files
-
- ## builtin/log.c ##
-@@ builtin/log.c: static const char *fmt_patch_subject_prefix = "PATCH";
- static const char *fmt_pretty;
-
- static const char * const builtin_log_usage[] = {
-- N_("git log [<options>] [<revision-range>] [[--] <path>...]"),
-+ N_("git log [<options>] [<revision-range>...] [[--] <path>...]"),
- N_("git show [<options>] <object>..."),
- NULL
- };
-: ---------- > 2: daf00d9398 git-rev-list.txt: move description to separate file -: ---------- > 3: eeaf4fe5dc git-log.txt: include rev-list-description.txt -: ---------- > 4: 3b923780c1 rev-list-description.txt: fix Asciidoc syntax
Signature · 1 line
gitgitgadget
PATCH v2 1/4 git-log.txt: add links to 'rev-list' and 'diff' docs
From: Philippe Blain <[email protected]>
Add links to the documentation for git rev-list and git diff instead of simply mentioning them, to make it easier for readers to reach these documentation pages. Let's link to git diff as this is the porcelain command, and the rest of the family (diff-index, diff-tree and diff-files) are mentioned in the "Raw output format" section of the git diff documentation.
--- Documentation/git-log.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Documentation/git-log.txt +2 -2
@@ -15,9 +15,9 @@ DESCRIPTION ----------- Shows the commit logs. -The command takes options applicable to the `git rev-list` +The command takes options applicable to the linkgit:git-rev-list[1] command to control what is shown and how, and options applicable to -the `git diff-*` commands to control how the changes +the linkgit:git-diff[1] family of commands to control how the changes each commit introduces are shown.
Signature · 1 line
gitgitgadget
Re: [PATCH v2 1/4] git-log.txt: add links to 'rev-list' and 'diff' docs
Quoted 19 lines · Philippe Blain via GitGitGadget
From: Philippe Blain <[email protected]>
Add links to the documentation for
git rev-listandgit diffinstead of simply mentioning them, to make it easier for readers to reach these documentation pages. Let's link togit diffas this is the porcelain command, and the rest of the family (diff-index,diff-treeanddiff-files) are mentioned in the "Raw output format" section of thegit diffdocumentation.Signed-off-by Philippe Blain <[email protected]>--- Documentation/git-log.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)Documentation/git-log.txt +0
-0
Documentation/git-log.txt DESCRIPTION · line 21
Quoted 9 lines
Documentation/git-log.txt +2
-2@@ -15,9 +15,9 @@ DESCRIPTION ----------- Shows the commit logs. -The command takes options applicable to the `git rev-list` +The command takes options applicable to the linkgit:git-rev-list[1] command to control what is shown and how, and options applicable to -the `git diff-*` commands to control how the changes +the linkgit:git-diff[1] family of commands to control how the changes each commit introduces are shown.
The original did mean "git diff-*" family of plumbing commands, but I think it makes more sense these days to just refer to "git diff" Porcelain, which is the single entry point everybody uses. So you would probably want to further replace "family of commands" with just "command" in the text.
Other than that, I think making these into links is a good idea.
Re: [PATCH v2 1/4] git-log.txt: add links to 'rev-list' and 'diff' docs
Hi Junio,
Quoted 6 lines · Junio C Hamano
Quoted 2 lines · Philippe Blain via GitGitGadget
From: Philippe Blain <[email protected]>
---8<---
Quoted 14 lines
Quoted 7 lines
Documentation/git-log.txt +1
-1-The command takes options applicable to the `git rev-list` +The command takes options applicable to the linkgit:git-rev-list[1]command to control what is shown and how, and options applicable to
Documentation/git-log.txt +1
-1-the `git diff-*` commands to control how the changes +the linkgit:git-diff[1] family of commands to control how the changeseach commit introduces are shown.
The original did mean "git diff-*" family of plumbing commands, but I think it makes more sense these days to just refer to "git diff" Porcelain, which is the single entry point everybody uses. So you would probably want to further replace "family of commands" with just "command" in the text.
Right. I'll change that.
Quoted 1 line
Other than that, I think making these into links is a good idea.
Thanks,
Philippe.
P.S. sorry for the resend, I forgot to convert the message to plain text the first time...
PATCH v2 2/4 git-rev-list.txt: move description to separate file
In reply to Philippe Blain via GitGitGadgetFrom: Philippe Blain <[email protected]>
A following commit will reuse the description of the git rev-list command in the git log manpage.
Move this description to a separate file.
--- Documentation/git-rev-list.txt | 39 +------------------------- Documentation/rev-list-description.txt | 38 +++++++++++++++++++++++++ 2 files changed, 39 insertions(+), 38 deletions(-) create mode 100644 Documentation/rev-list-description.txt
Documentation/git-rev-list.txt +1 -38
@@ -14,44 +14,7 @@ SYNOPSIS DESCRIPTION ----------- -List commits that are reachable by following the `parent` links from the -given commit(s), but exclude commits that are reachable from the one(s) -given with a '{caret}' in front of them. The output is given in reverse -chronological order by default. - -You can think of this as a set operation. Commits given on the command -line form a set of commits that are reachable from any of them, and then -commits reachable from any of the ones given with '{caret}' in front are -subtracted from that set. The remaining commits are what comes out in the -command's output. Various other options and paths parameters can be used -to further limit the result. - -Thus, the following command: - ------------------------------------------------------------------------ - $ git rev-list foo bar ^baz ------------------------------------------------------------------------ - -means "list all the commits which are reachable from 'foo' or 'bar', but -not from 'baz'". - -A special notation "'<commit1>'..'<commit2>'" can be used as a -short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of -the following may be used interchangeably: - ------------------------------------------------------------------------ - $ git rev-list origin..HEAD - $ git rev-list HEAD ^origin ------------------------------------------------------------------------ - -Another special notation is "'<commit1>'...'<commit2>'" which is useful -for merges. The resulting set of commits is the symmetric difference -between the two operands. The following two commands are equivalent: - ------------------------------------------------------------------------ - $ git rev-list A B --not $(git merge-base --all A B) - $ git rev-list A...B ------------------------------------------------------------------------ +include::rev-list-description.txt[] 'rev-list' is a very essential Git command, since it provides the ability to build and traverse commit ancestry graphs. For
Documentation/rev-list-description.txt new file +38 -0
@@ -0,0 +1,38 @@ +List commits that are reachable by following the `parent` links from the +given commit(s), but exclude commits that are reachable from the one(s) +given with a '{caret}' in front of them. The output is given in reverse +chronological order by default. + +You can think of this as a set operation. Commits given on the command +line form a set of commits that are reachable from any of them, and then +commits reachable from any of the ones given with '{caret}' in front are +subtracted from that set. The remaining commits are what comes out in the +command's output. Various other options and paths parameters can be used +to further limit the result. + +Thus, the following command: + +----------------------------------------------------------------------- + $ git rev-list foo bar ^baz +----------------------------------------------------------------------- + +means "list all the commits which are reachable from 'foo' or 'bar', but +not from 'baz'". + +A special notation "'<commit1>'..'<commit2>'" can be used as a +short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of +the following may be used interchangeably: + +----------------------------------------------------------------------- + $ git rev-list origin..HEAD + $ git rev-list HEAD ^origin +----------------------------------------------------------------------- + +Another special notation is "'<commit1>'...'<commit2>'" which is useful +for merges. The resulting set of commits is the symmetric difference +between the two operands. The following two commands are equivalent: + +----------------------------------------------------------------------- + $ git rev-list A B --not $(git merge-base --all A B) + $ git rev-list A...B +-----------------------------------------------------------------------
Signature · 1 line
gitgitgadget
PATCH v2 3/4 git-log.txt: include rev-list-description.txt
In reply to Philippe Blain via GitGitGadgetFrom: Philippe Blain <[email protected]>
The git log synopsis mentions <revision range>, and the description of this option links to gitrevisions(7), but a nice explanation of how a revision range can be constructed from individual commits, optionnally prefixed with ^, also exists in rev-list-description.txt.
Include this description in the man page for git log.
Add Asciidoc 'ifdef's to rev-list-description.txt so that either git rev-list or git log appears in the respective man pages.
--- Documentation/git-log.txt | 3 +++ Documentation/git-rev-list.txt | 1 + Documentation/rev-list-description.txt | 23 +++++++++++++++++++++++ 3 files changed, 27 insertions(+)
Documentation/git-log.txt +3 -0
@@ -15,6 +15,9 @@ DESCRIPTION ----------- Shows the commit logs. +:git-log: 1 +include::rev-list-description.txt[] + The command takes options applicable to the linkgit:git-rev-list[1] command to control what is shown and how, and options applicable to the linkgit:git-diff[1] family of commands to control how the changes
Documentation/git-rev-list.txt +1 -0
@@ -14,6 +14,7 @@ SYNOPSIS DESCRIPTION ----------- +:git-rev-list: 1 include::rev-list-description.txt[] 'rev-list' is a very essential Git command, since it
Documentation/rev-list-description.txt +23 -0
@@ -12,9 +12,16 @@ to further limit the result. Thus, the following command: +ifdef::git-rev-list[] ----------------------------------------------------------------------- $ git rev-list foo bar ^baz ----------------------------------------------------------------------- +endif::git-rev-list[] +ifdef::git-log[] +----------------------------------------------------------------------- + $ git log foo bar ^baz +----------------------------------------------------------------------- +endif::git-log[] means "list all the commits which are reachable from 'foo' or 'bar', but not from 'baz'".
@@ -23,16 +30,32 @@ A special notation "'<commit1>'..'<commit2>'" can be used as a short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of the following may be used interchangeably: +ifdef::git-rev-list[] ----------------------------------------------------------------------- $ git rev-list origin..HEAD $ git rev-list HEAD ^origin ----------------------------------------------------------------------- +endif::git-rev-list[] +ifdef::git-log[] +----------------------------------------------------------------------- + $ git log origin..HEAD + $ git log HEAD ^origin +----------------------------------------------------------------------- +endif::git-log[] Another special notation is "'<commit1>'...'<commit2>'" which is useful for merges. The resulting set of commits is the symmetric difference between the two operands. The following two commands are equivalent: +ifdef::git-rev-list[] ----------------------------------------------------------------------- $ git rev-list A B --not $(git merge-base --all A B) $ git rev-list A...B ----------------------------------------------------------------------- +endif::git-rev-list[] +ifdef::git-log[] +----------------------------------------------------------------------- + $ git log A B --not $(git merge-base --all A B) + $ git log A...B +----------------------------------------------------------------------- +endif::git-log[]
Signature · 1 line
gitgitgadget
PATCH v2 4/4 rev-list-description.txt: fix Asciidoc syntax
In reply to Philippe Blain via GitGitGadgetFrom: Philippe Blain <[email protected]>
Using '{caret}' inside double quotes and immediately following with a single quoted word does not create the desired output: '<commit1>' appears verbatim instead of being emphasized.
Use a litteral caret ('^') instead.
Also, remove the leading tabs in shell examples to bring them more in line with the rest of the documentation.
--- Documentation/rev-list-description.txt | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
Documentation/rev-list-description.txt +11 -11
@@ -14,12 +14,12 @@ Thus, the following command: ifdef::git-rev-list[] ----------------------------------------------------------------------- - $ git rev-list foo bar ^baz +$ git rev-list foo bar ^baz ----------------------------------------------------------------------- endif::git-rev-list[] ifdef::git-log[] ----------------------------------------------------------------------- - $ git log foo bar ^baz +$ git log foo bar ^baz ----------------------------------------------------------------------- endif::git-log[]
@@ -27,19 +27,19 @@ means "list all the commits which are reachable from 'foo' or 'bar', but not from 'baz'". A special notation "'<commit1>'..'<commit2>'" can be used as a -short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of +short-hand for "^'<commit1>' '<commit2>'". For example, either of the following may be used interchangeably: ifdef::git-rev-list[] ----------------------------------------------------------------------- - $ git rev-list origin..HEAD - $ git rev-list HEAD ^origin +$ git rev-list origin..HEAD +$ git rev-list HEAD ^origin ----------------------------------------------------------------------- endif::git-rev-list[] ifdef::git-log[] ----------------------------------------------------------------------- - $ git log origin..HEAD - $ git log HEAD ^origin +$ git log origin..HEAD +$ git log HEAD ^origin ----------------------------------------------------------------------- endif::git-log[]
@@ -49,13 +49,13 @@ between the two operands. The following two commands are equivalent: ifdef::git-rev-list[] ----------------------------------------------------------------------- - $ git rev-list A B --not $(git merge-base --all A B) - $ git rev-list A...B +$ git rev-list A B --not $(git merge-base --all A B) +$ git rev-list A...B ----------------------------------------------------------------------- endif::git-rev-list[] ifdef::git-log[] ----------------------------------------------------------------------- - $ git log A B --not $(git merge-base --all A B) - $ git log A...B +$ git log A B --not $(git merge-base --all A B) +$ git log A...B ----------------------------------------------------------------------- endif::git-log[]
Signature · 1 line
gitgitgadget
Re: [PATCH v2 4/4] rev-list-description.txt: fix Asciidoc syntax
Quoted 10 lines · Philippe Blain via GitGitGadget
From: Philippe Blain <[email protected]>
Using '{caret}' inside double quotes and immediately following with a single quoted word does not create the desired output: '<commit1>' appears verbatim instead of being emphasized.
Use a litteral caret ('^') instead.
Also, remove the leading tabs in shell examples to bring them more in line with the rest of the documentation.
These should be done _before_ 2/4 as a preliminary clean-up, I think.
Thanks for a pleasant read.
Re: [PATCH v2 4/4] rev-list-description.txt: fix Asciidoc syntax
Quoted 11 lines · Junio C Hamano
Quoted 6 lines · Philippe Blain via GitGitGadget
From: Philippe Blain <[email protected]>
Using '{caret}' inside double quotes and immediately following with a single quoted word does not create the desired output: '<commit1>' appears verbatim instead of being emphasized.
Quoted 7 lines
Quoted 4 lines
Use a litteral caret ('^') instead.
Also, remove the leading tabs in shell examples to bring them more in line with the rest of the documentation.
These should be done _before_ 2/4 as a preliminary clean-up, I think.
I agree. I'll reorder that for v3.
v3 cover doc: include git rev-list description in git log doc
In reply to Philippe Blain via GitGitGadgetChanges since v2:
* applied Junio's suggestions
* added a preparatory commit tweaking the wording of one sentence in the git rev-list description
* added a new commit adding a sentence in revisions.txt to mention explicitly what it means to list several revisions to form a range.
v2: This series moves the nice explanation in the 'Description' section of the git rev-list man page to a separate file and includes this file in the git log man page.
This goal is to make readers more aware that they can write e.g.
git log branch1 branch2 branch3 branch4 --not master
to see commits on each of branch1-4, that are not on master, since this is not immediately obvious (at least to me) in the git log man page.
Note that I made several commits for ease of reviewing, I'll squash some if this would be preferred.
Changes since v1: took a completely different approach following the comments received from Junio and Taylor.
Philippe Blain (6):
git-log.txt: add links to 'rev-list' and 'diff' docs revisions.txt: describe 'rev1 rev2 ...' meaning for ranges git-rev-list.txt: fix Asciidoc syntax git-rev-list.txt: tweak wording in set operations git-rev-list.txt: move description to separate file git-log.txt: include rev-list-description.txt
Documentation/git-log.txt | 7 ++- Documentation/git-rev-list.txt | 40 +---------------- Documentation/rev-list-description.txt | 61 ++++++++++++++++++++++++++ Documentation/revisions.txt | 3 ++ 4 files changed, 71 insertions(+), 40 deletions(-) create mode 100644 Documentation/rev-list-description.txt
base-commit: a08a83db2bf27f015bec9a435f6d73e223c21c5e
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-590%2Fphil-blain%2Fdoc-log-multiple-ranges-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-590/phil-blain/doc-log-multiple-ranges-v3
Pull-Request: https://github.com/gitgitgadget/git/pull/590
Range-diff vs v2:
1: 59c48282a0 ! 1: 59027b0f6a git-log.txt: add links to 'rev-list' and 'diff' docs
@@ Documentation/git-log.txt: DESCRIPTION
+The command takes options applicable to the linkgit:git-rev-list[1]
command to control what is shown and how, and options applicable to
-the git diff-* commands to control how the changes
-+the linkgit:git-diff[1] family of commands to control how the changes ++the linkgit:git-diff[1] command to control how the changes
each commit introduces are shown.
-: ---------- > 2: 3c573695a8 revisions.txt: describe 'rev1 rev2 ...' meaning for ranges 4: 3b923780c1 ! 3: b8ee4a743c rev-list-description.txt: fix Asciidoc syntax
@@ Metadata
Author: Philippe Blain <[email protected]>
## Commit message ##
- rev-list-description.txt: fix Asciidoc syntax
+ git-rev-list.txt: fix Asciidoc syntax
Using '{caret}' inside double quotes and immediately following with a single quoted word does not create the desired output: '<commit1>'
@@ Commit message
- ## Documentation/rev-list-description.txt ##
-@@ Documentation/rev-list-description.txt: Thus, the following command:
+ ## Documentation/git-rev-list.txt ##
+@@ Documentation/git-rev-list.txt: to further limit the result.
+ Thus, the following command:
- ifdef::git-rev-list[]
-----------------------------------------------------------------------
- $ git rev-list foo bar ^baz
+$ git rev-list foo bar ^baz
-----------------------------------------------------------------------
- endif::git-rev-list[]
- ifdef::git-log[]
- -----------------------------------------------------------------------
-- $ git log foo bar ^baz
-+$ git log foo bar ^baz
- -----------------------------------------------------------------------
- endif::git-log[]
-@@ Documentation/rev-list-description.txt: means "list all the commits which are reachable from 'foo' or 'bar', but
+ means "list all the commits which are reachable from 'foo' or 'bar', but
not from 'baz'".
A special notation "'<commit1>'..'<commit2>'" can be used as a
@@ Documentation/rev-list-description.txt: means "list all the commits which are re
+short-hand for "^'<commit1>' '<commit2>'". For example, either of
the following may be used interchangeably:
- ifdef::git-rev-list[]
-----------------------------------------------------------------------
- $ git rev-list origin..HEAD
- $ git rev-list HEAD ^origin
+$ git rev-list origin..HEAD
+$ git rev-list HEAD ^origin
-----------------------------------------------------------------------
- endif::git-rev-list[]
- ifdef::git-log[]
- -----------------------------------------------------------------------
-- $ git log origin..HEAD
-- $ git log HEAD ^origin
-+$ git log origin..HEAD
-+$ git log HEAD ^origin
- -----------------------------------------------------------------------
- endif::git-log[]
-@@ Documentation/rev-list-description.txt: between the two operands. The following two commands are equivalent:
+ Another special notation is "'<commit1>'...'<commit2>'" which is useful
+@@ Documentation/git-rev-list.txt: for merges. The resulting set of commits is the symmetric difference
+ between the two operands. The following two commands are equivalent:
- ifdef::git-rev-list[]
-----------------------------------------------------------------------
- $ git rev-list A B --not $(git merge-base --all A B)
- $ git rev-list A...B
+$ git rev-list A B --not $(git merge-base --all A B)
+$ git rev-list A...B
-----------------------------------------------------------------------
- endif::git-rev-list[]
- ifdef::git-log[]
- -----------------------------------------------------------------------
-- $ git log A B --not $(git merge-base --all A B)
-- $ git log A...B
-+$ git log A B --not $(git merge-base --all A B)
-+$ git log A...B
- -----------------------------------------------------------------------
- endif::git-log[]
+
+ 'rev-list' is a very essential Git command, since it
-: ---------- > 4: cf934ddf33 git-rev-list.txt: tweak wording in set operations 2: daf00d9398 ! 5: f61bbb57cb git-rev-list.txt: move description to separate file
@@ Documentation/git-rev-list.txt: SYNOPSIS
-given with a '{caret}' in front of them. The output is given in reverse -chronological order by default.
-
--You can think of this as a set operation. Commits given on the command --line form a set of commits that are reachable from any of them, and then --commits reachable from any of the ones given with '{caret}' in front are --subtracted from that set. The remaining commits are what comes out in the --command's output. Various other options and paths parameters can be used --to further limit the result.
+-You can think of this as a set operation. Commits reachable from any of +-the commits given on the command line form a set, and then commits reachable +-from any of the ones given with '{caret}' in front are subtracted from that +-set. The remaining commits are what comes out in the command's output. +-Various other options and paths parameters can be used to further limit the +-result.
-
-Thus, the following command:
-
------------------------------------------------------------------------
-- $ git rev-list foo bar ^baz
+-$ git rev-list foo bar ^baz
------------------------------------------------------------------------
-
-means "list all the commits which are reachable from 'foo' or 'bar', but -not from 'baz'".
-
-A special notation "'<commit1>'..'<commit2>'" can be used as a
--short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of +-short-hand for "^'<commit1>' '<commit2>'". For example, either of
-the following may be used interchangeably:
-
------------------------------------------------------------------------
-- $ git rev-list origin..HEAD
-- $ git rev-list HEAD ^origin
+-$ git rev-list origin..HEAD
+-$ git rev-list HEAD ^origin
------------------------------------------------------------------------
-
-Another special notation is "'<commit1>'...'<commit2>'" which is useful
@@ Documentation/git-rev-list.txt: SYNOPSIS
-between the two operands. The following two commands are equivalent:
-
------------------------------------------------------------------------
-- $ git rev-list A B --not $(git merge-base --all A B)
-- $ git rev-list A...B
+-$ git rev-list A B --not $(git merge-base --all A B)
+-$ git rev-list A...B
------------------------------------------------------------------------
+include::rev-list-description.txt[]
@@ Documentation/rev-list-description.txt (new)
+given with a '{caret}' in front of them. The output is given in reverse +chronological order by default.
+
-+You can think of this as a set operation. Commits given on the command -+line form a set of commits that are reachable from any of them, and then -+commits reachable from any of the ones given with '{caret}' in front are -+subtracted from that set. The remaining commits are what comes out in the -+command's output. Various other options and paths parameters can be used -+to further limit the result.
++You can think of this as a set operation. Commits reachable from any of ++the commits given on the command line form a set, and then commits reachable ++from any of the ones given with '{caret}' in front are subtracted from that ++set. The remaining commits are what comes out in the command's output. ++Various other options and paths parameters can be used to further limit the ++result.
+
+Thus, the following command:
+
+-----------------------------------------------------------------------
-+ $ git rev-list foo bar ^baz
++$ git rev-list foo bar ^baz
+-----------------------------------------------------------------------
+
+means "list all the commits which are reachable from 'foo' or 'bar', but +not from 'baz'".
+
+A special notation "'<commit1>'..'<commit2>'" can be used as a
-+short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of ++short-hand for "^'<commit1>' '<commit2>'". For example, either of
+the following may be used interchangeably:
+
+-----------------------------------------------------------------------
-+ $ git rev-list origin..HEAD
-+ $ git rev-list HEAD ^origin
++$ git rev-list origin..HEAD
++$ git rev-list HEAD ^origin
+-----------------------------------------------------------------------
+
+Another special notation is "'<commit1>'...'<commit2>'" which is useful
@@ Documentation/rev-list-description.txt (new)
+between the two operands. The following two commands are equivalent:
+
+-----------------------------------------------------------------------
-+ $ git rev-list A B --not $(git merge-base --all A B)
-+ $ git rev-list A...B
++$ git rev-list A B --not $(git merge-base --all A B)
++$ git rev-list A...B
+-----------------------------------------------------------------------
3: eeaf4fe5dc ! 6: d04b6c62a3 git-log.txt: include rev-list-description.txt
@@ Documentation/git-log.txt: DESCRIPTION
+
The command takes options applicable to the linkgit:git-rev-list[1] command to control what is shown and how, and options applicable to
- the linkgit:git-diff[1] family of commands to control how the changes
+ the linkgit:git-diff[1] command to control how the changes
## Documentation/git-rev-list.txt ##
@@ Documentation/git-rev-list.txt: SYNOPSIS
@@ Documentation/git-rev-list.txt: SYNOPSIS
'rev-list' is a very essential Git command, since it
## Documentation/rev-list-description.txt ##
-@@ Documentation/rev-list-description.txt: to further limit the result. +@@ Documentation/rev-list-description.txt: result.
Thus, the following command:
+ifdef::git-rev-list[]
-----------------------------------------------------------------------
- $ git rev-list foo bar ^baz
+ $ git rev-list foo bar ^baz
-----------------------------------------------------------------------
+endif::git-rev-list[]
+ifdef::git-log[]
+-----------------------------------------------------------------------
-+ $ git log foo bar ^baz
++$ git log foo bar ^baz
+-----------------------------------------------------------------------
+endif::git-log[]
means "list all the commits which are reachable from 'foo' or 'bar', but
not from 'baz'".
@@ Documentation/rev-list-description.txt: A special notation "'<commit1>'..'<commit2>'" can be used as a
- short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of
+ short-hand for "^'<commit1>' '<commit2>'". For example, either of
the following may be used interchangeably:
+ifdef::git-rev-list[]
-----------------------------------------------------------------------
- $ git rev-list origin..HEAD
- $ git rev-list HEAD ^origin
+ $ git rev-list origin..HEAD
+ $ git rev-list HEAD ^origin
-----------------------------------------------------------------------
+endif::git-rev-list[]
+ifdef::git-log[]
+-----------------------------------------------------------------------
-+ $ git log origin..HEAD
-+ $ git log HEAD ^origin
++$ git log origin..HEAD
++$ git log HEAD ^origin
+-----------------------------------------------------------------------
+endif::git-log[]
@@ Documentation/rev-list-description.txt: A special notation "'<commit1>'..'<commi
+ifdef::git-rev-list[]
-----------------------------------------------------------------------
- $ git rev-list A B --not $(git merge-base --all A B)
- $ git rev-list A...B
+ $ git rev-list A B --not $(git merge-base --all A B)
+ $ git rev-list A...B
-----------------------------------------------------------------------
+endif::git-rev-list[]
+ifdef::git-log[]
+-----------------------------------------------------------------------
-+ $ git log A B --not $(git merge-base --all A B)
-+ $ git log A...B
++$ git log A B --not $(git merge-base --all A B) ++$ git log A...B
+-----------------------------------------------------------------------
+endif::git-log[]
Signature · 1 line
gitgitgadget
PATCH v3 1/6 git-log.txt: add links to 'rev-list' and 'diff' docs
From: Philippe Blain <[email protected]>
Add links to the documentation for git rev-list and git diff instead of simply mentioning them, to make it easier for readers to reach these documentation pages. Let's link to git diff as this is the porcelain command, and the rest of the family (diff-index, diff-tree and diff-files) are mentioned in the "Raw output format" section of the git diff documentation.
--- Documentation/git-log.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Documentation/git-log.txt +2 -2
@@ -15,9 +15,9 @@ DESCRIPTION ----------- Shows the commit logs. -The command takes options applicable to the `git rev-list` +The command takes options applicable to the linkgit:git-rev-list[1] command to control what is shown and how, and options applicable to -the `git diff-*` commands to control how the changes +the linkgit:git-diff[1] command to control how the changes each commit introduces are shown.
Signature · 1 line
gitgitgadget
PATCH v3 2/6 revisions.txt: describe 'rev1 rev2 ...' meaning for ranges
In reply to Philippe Blain via GitGitGadgetFrom: Philippe Blain <[email protected]>
The "Specifying ranges" section does not mention explicitly that several commits can be specified to form a range.
Add a mention to that effect.
--- Documentation/revisions.txt | 3 +++ 1 file changed, 3 insertions(+)
Documentation/revisions.txt +3 -0
@@ -254,6 +254,9 @@ specifying a single revision, using the notation described in the previous section, means the set of commits `reachable` from the given commit. +Specifying several revisions means the set of commits reachable from +any of the given commits. + A commit's reachable set is the commit itself and the commits in its ancestry chain.
Signature · 1 line
gitgitgadget
PATCH v3 3/6 git-rev-list.txt: fix Asciidoc syntax
In reply to Philippe Blain via GitGitGadgetFrom: Philippe Blain <[email protected]>
Using '{caret}' inside double quotes and immediately following with a single quoted word does not create the desired output: '<commit1>' appears verbatim instead of being emphasized.
Use a litteral caret ('^') instead.
Also, remove the leading tabs in shell examples to bring them more in line with the rest of the documentation.
--- Documentation/git-rev-list.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
Documentation/git-rev-list.txt +6 -6
@@ -29,19 +29,19 @@ to further limit the result. Thus, the following command: ----------------------------------------------------------------------- - $ git rev-list foo bar ^baz +$ git rev-list foo bar ^baz ----------------------------------------------------------------------- means "list all the commits which are reachable from 'foo' or 'bar', but not from 'baz'". A special notation "'<commit1>'..'<commit2>'" can be used as a -short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of +short-hand for "^'<commit1>' '<commit2>'". For example, either of the following may be used interchangeably: ----------------------------------------------------------------------- - $ git rev-list origin..HEAD - $ git rev-list HEAD ^origin +$ git rev-list origin..HEAD +$ git rev-list HEAD ^origin ----------------------------------------------------------------------- Another special notation is "'<commit1>'...'<commit2>'" which is useful
@@ -49,8 +49,8 @@ for merges. The resulting set of commits is the symmetric difference between the two operands. The following two commands are equivalent: ----------------------------------------------------------------------- - $ git rev-list A B --not $(git merge-base --all A B) - $ git rev-list A...B +$ git rev-list A B --not $(git merge-base --all A B) +$ git rev-list A...B ----------------------------------------------------------------------- 'rev-list' is a very essential Git command, since it
Signature · 1 line
gitgitgadget
PATCH v3 4/6 git-rev-list.txt: tweak wording in set operations
In reply to Philippe Blain via GitGitGadgetFrom: Philippe Blain <[email protected]>
Tweak a sentence to make it a little more readable.
--- Documentation/git-rev-list.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
Documentation/git-rev-list.txt +6 -6
@@ -19,12 +19,12 @@ given commit(s), but exclude commits that are reachable from the one(s) given with a '{caret}' in front of them. The output is given in reverse chronological order by default. -You can think of this as a set operation. Commits given on the command -line form a set of commits that are reachable from any of them, and then -commits reachable from any of the ones given with '{caret}' in front are -subtracted from that set. The remaining commits are what comes out in the -command's output. Various other options and paths parameters can be used -to further limit the result. +You can think of this as a set operation. Commits reachable from any of +the commits given on the command line form a set, and then commits reachable +from any of the ones given with '{caret}' in front are subtracted from that +set. The remaining commits are what comes out in the command's output. +Various other options and paths parameters can be used to further limit the +result. Thus, the following command:
Signature · 1 line
gitgitgadget
PATCH v3 5/6 git-rev-list.txt: move description to separate file
In reply to Philippe Blain via GitGitGadgetFrom: Philippe Blain <[email protected]>
A following commit will reuse the description of the git rev-list command in the git log manpage.
Move this description to a separate file.
--- Documentation/git-rev-list.txt | 39 +------------------------- Documentation/rev-list-description.txt | 38 +++++++++++++++++++++++++ 2 files changed, 39 insertions(+), 38 deletions(-) create mode 100644 Documentation/rev-list-description.txt
Documentation/git-rev-list.txt +1 -38
@@ -14,44 +14,7 @@ SYNOPSIS DESCRIPTION ----------- -List commits that are reachable by following the `parent` links from the -given commit(s), but exclude commits that are reachable from the one(s) -given with a '{caret}' in front of them. The output is given in reverse -chronological order by default. - -You can think of this as a set operation. Commits reachable from any of -the commits given on the command line form a set, and then commits reachable -from any of the ones given with '{caret}' in front are subtracted from that -set. The remaining commits are what comes out in the command's output. -Various other options and paths parameters can be used to further limit the -result. - -Thus, the following command: - ------------------------------------------------------------------------ -$ git rev-list foo bar ^baz ------------------------------------------------------------------------ - -means "list all the commits which are reachable from 'foo' or 'bar', but -not from 'baz'". - -A special notation "'<commit1>'..'<commit2>'" can be used as a -short-hand for "^'<commit1>' '<commit2>'". For example, either of -the following may be used interchangeably: - ------------------------------------------------------------------------ -$ git rev-list origin..HEAD -$ git rev-list HEAD ^origin ------------------------------------------------------------------------ - -Another special notation is "'<commit1>'...'<commit2>'" which is useful -for merges. The resulting set of commits is the symmetric difference -between the two operands. The following two commands are equivalent: - ------------------------------------------------------------------------ -$ git rev-list A B --not $(git merge-base --all A B) -$ git rev-list A...B ------------------------------------------------------------------------ +include::rev-list-description.txt[] 'rev-list' is a very essential Git command, since it provides the ability to build and traverse commit ancestry graphs. For
Documentation/rev-list-description.txt new file +38 -0
@@ -0,0 +1,38 @@ +List commits that are reachable by following the `parent` links from the +given commit(s), but exclude commits that are reachable from the one(s) +given with a '{caret}' in front of them. The output is given in reverse +chronological order by default. + +You can think of this as a set operation. Commits reachable from any of +the commits given on the command line form a set, and then commits reachable +from any of the ones given with '{caret}' in front are subtracted from that +set. The remaining commits are what comes out in the command's output. +Various other options and paths parameters can be used to further limit the +result. + +Thus, the following command: + +----------------------------------------------------------------------- +$ git rev-list foo bar ^baz +----------------------------------------------------------------------- + +means "list all the commits which are reachable from 'foo' or 'bar', but +not from 'baz'". + +A special notation "'<commit1>'..'<commit2>'" can be used as a +short-hand for "^'<commit1>' '<commit2>'". For example, either of +the following may be used interchangeably: + +----------------------------------------------------------------------- +$ git rev-list origin..HEAD +$ git rev-list HEAD ^origin +----------------------------------------------------------------------- + +Another special notation is "'<commit1>'...'<commit2>'" which is useful +for merges. The resulting set of commits is the symmetric difference +between the two operands. The following two commands are equivalent: + +----------------------------------------------------------------------- +$ git rev-list A B --not $(git merge-base --all A B) +$ git rev-list A...B +-----------------------------------------------------------------------
Signature · 1 line
gitgitgadget
PATCH v3 6/6 git-log.txt: include rev-list-description.txt
In reply to Philippe Blain via GitGitGadgetFrom: Philippe Blain <[email protected]>
The git log synopsis mentions <revision range>, and the description of this option links to gitrevisions(7), but a nice explanation of how a revision range can be constructed from individual commits, optionnally prefixed with ^, also exists in rev-list-description.txt.
Include this description in the man page for git log.
Add Asciidoc 'ifdef's to rev-list-description.txt so that either git rev-list or git log appears in the respective man pages.
--- Documentation/git-log.txt | 3 +++ Documentation/git-rev-list.txt | 1 + Documentation/rev-list-description.txt | 23 +++++++++++++++++++++++ 3 files changed, 27 insertions(+)
Documentation/git-log.txt +3 -0
@@ -15,6 +15,9 @@ DESCRIPTION ----------- Shows the commit logs. +:git-log: 1 +include::rev-list-description.txt[] + The command takes options applicable to the linkgit:git-rev-list[1] command to control what is shown and how, and options applicable to the linkgit:git-diff[1] command to control how the changes
Documentation/git-rev-list.txt +1 -0
@@ -14,6 +14,7 @@ SYNOPSIS DESCRIPTION ----------- +:git-rev-list: 1 include::rev-list-description.txt[] 'rev-list' is a very essential Git command, since it
Documentation/rev-list-description.txt +23 -0
@@ -12,9 +12,16 @@ result. Thus, the following command: +ifdef::git-rev-list[] ----------------------------------------------------------------------- $ git rev-list foo bar ^baz ----------------------------------------------------------------------- +endif::git-rev-list[] +ifdef::git-log[] +----------------------------------------------------------------------- +$ git log foo bar ^baz +----------------------------------------------------------------------- +endif::git-log[] means "list all the commits which are reachable from 'foo' or 'bar', but not from 'baz'".
@@ -23,16 +30,32 @@ A special notation "'<commit1>'..'<commit2>'" can be used as a short-hand for "^'<commit1>' '<commit2>'". For example, either of the following may be used interchangeably: +ifdef::git-rev-list[] ----------------------------------------------------------------------- $ git rev-list origin..HEAD $ git rev-list HEAD ^origin ----------------------------------------------------------------------- +endif::git-rev-list[] +ifdef::git-log[] +----------------------------------------------------------------------- +$ git log origin..HEAD +$ git log HEAD ^origin +----------------------------------------------------------------------- +endif::git-log[] Another special notation is "'<commit1>'...'<commit2>'" which is useful for merges. The resulting set of commits is the symmetric difference between the two operands. The following two commands are equivalent: +ifdef::git-rev-list[] ----------------------------------------------------------------------- $ git rev-list A B --not $(git merge-base --all A B) $ git rev-list A...B ----------------------------------------------------------------------- +endif::git-rev-list[] +ifdef::git-log[] +----------------------------------------------------------------------- +$ git log A B --not $(git merge-base --all A B) +$ git log A...B +----------------------------------------------------------------------- +endif::git-log[]
Signature · 1 line
gitgitgadget