doc: include `git rev-list` description in `git log` doc #590

phil-blain · 2020-03-28T21:08:47Z

Changes 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.

CC: Lawrence Siebert lawrencesiebert@gmail.com, Denton Liu liu.denton@gmail.com, Junio C Hamano gitster@pobox.com, Taylor Blau me@ttaylorr.com, Philip Oakley philipoakley@iee.email

phil-blain · 2020-03-28T21:10:17Z

/submit

gitgitgadget · 2020-03-28T21:11:46Z

Submitted as pull.590.git.1585429894378.gitgitgadget@gmail.com

gitgitgadget · 2020-03-29T01:37:49Z

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Philippe Blain <levraiphilippeblain@gmail.com>
>
> `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.

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.

gitgitgadget · 2020-03-30T12:56:53Z

On the Git mailing list, Philippe Blain wrote (reply to this):

Hi Junio, 
> Le 28 mars 2020 Ã  21:34, Junio C Hamano <gitster@pobox.com> a Ã©crit :
> 
> "Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>> From: Philippe Blain <levraiphilippeblain@gmail.com>
>> 
>> `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.
> 
> 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.

Of course, I understand.

> 
> "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.

> 
> 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.

gitgitgadget · 2020-03-30T17:12:30Z

On the Git mailing list, Junio C Hamano wrote (reply to this):

Philippe Blain <levraiphilippeblain@gmail.com> writes:

> 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 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.

gitgitgadget · 2020-03-31T21:56:52Z

On the Git mailing list, Taylor Blau wrote (reply to this):

On Sat, Mar 28, 2020 at 06:34:14PM -0700, Junio C Hamano wrote:
> "Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: Philippe Blain <levraiphilippeblain@gmail.com>
> >
> > `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.
>
> 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.

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.

> 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 ;).

> Thanks.

Thanks,
Taylor

phil-blain · 2020-07-03T03:37:42Z

/submit

gitgitgadget · 2020-07-03T03:38:42Z

Submitted as pull.590.v2.git.1593747509.gitgitgadget@gmail.com

gitgitgadget · 2020-07-05T20:43:54Z

On the Git mailing list, Philip Oakley wrote (reply to this):

Hi Philippe,
This had been sitting in my inbox..

On 30/03/2020 13:52, Philippe Blain wrote:
> Hi Junio, 
>> Le 28 mars 2020 à 21:34, Junio C Hamano <gitster@pobox.com> a écrit :
>>
>> "Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes:
>>
>>> From: Philippe Blain <levraiphilippeblain@gmail.com>
>>>
>>> `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.

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.

>> 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.
> Of course, I understand.
>
>> "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.
>
>> 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. 

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...)

> 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.
>
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.
> 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

gitgitgadget · 2020-07-07T00:56:37Z

Documentation/git-log.txt

@@ -15,9 +15,9 @@ DESCRIPTION
 -----------


On the Git mailing list, Junio C Hamano wrote (reply to this):

"Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes: > From: Philippe Blain <levraiphilippeblain@gmail.com> > > 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. > > Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> > --- > Documentation/git-log.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt > index 20e6d21a74..04ea18d1c0 100644 > --- a/Documentation/git-log.txt > +++ b/Documentation/git-log.txt > @@ -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.

On the Git mailing list, Philippe Blain wrote (reply to this):

Hi Junio, > Le 6 juil. 2020 à 20:55, Junio C Hamano <gitster@pobox.com> a écrit : > > "Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> From: Philippe Blain <levraiphilippeblain@gmail.com> >> ---8<--- >> >> -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. > Right. I'll change that. > 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...

gitgitgadget · 2020-07-07T01:02:40Z

Documentation/rev-list-description.txt

@@ -0,0 +1,61 @@
+List commits that are reachable by following the `parent` links from the


On the Git mailing list, Junio C Hamano wrote (reply to this):

"Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes: > From: Philippe Blain <levraiphilippeblain@gmail.com> > > 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.

On the Git mailing list, Philippe Blain wrote (reply to this):

> Le 6 juil. 2020 à 20:59, Junio C Hamano <gitster@pobox.com> a écrit : > > "Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> From: Philippe Blain <levraiphilippeblain@gmail.com> >> >> 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. I agree. I'll reorder that for v3.

gitgitgadget · 2020-07-07T05:00:54Z

This branch is now known as pb/log-rev-list-doc.

gitgitgadget · 2020-07-07T05:00:55Z

This patch series was integrated into seen via git@6ca1fdc.

gitgitgadget · 2020-07-07T05:57:44Z

This patch series was integrated into seen via git@d9855b4.

gitgitgadget · 2020-07-07T13:09:07Z

On the Git mailing list, Philippe Blain wrote (reply to this):

Hi Philip,

> Le 5 juil. 2020 à 16:42, Philip Oakley <philipoakley@iee.email> a écrit :
> 
> Hi Philippe,
> This had been sitting in my inbox..
> 
-----8<-----
>> 
>> 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. 
> 
> 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...)

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.

> 
>> 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.
>> 
> 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.

gitgitgadget · 2020-07-07T21:17:27Z

This patch series was integrated into seen via git@e824c73.

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. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>

gitgitgadget · 2020-07-09T00:03:42Z

This patch series was integrated into seen via git@e34a351.

The "Specifying ranges" section does not mention explicitly that several commits can be specified to form a range. Add a mention to that effect. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>

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. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>

Tweak a sentence to make it a little more readable. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>

phil-blain · 2020-07-15T01:25:25Z

@dscho when I get CI failures like this, that are not caused by my commits (this series only changes files underDocumentation/) do you want to know about them ? or should I assume you already know ?

dscho · 2020-07-15T05:23:29Z

I didn't find a way to subscribe to all workflow failures... So yes, I appreciate a ping. The build is now running again.

gitgitgadget · 2020-07-15T18:24:32Z

This patch series was integrated into seen via git@2e682d4.

gitgitgadget · 2020-07-15T22:38:29Z

This patch series was integrated into seen via git@a6ca601.

gitgitgadget · 2020-07-16T00:36:02Z

This patch series was integrated into seen via git@78c9c63.

gitgitgadget · 2020-07-16T21:19:30Z

This patch series was integrated into seen via git@abf8c2d.

gitgitgadget · 2020-07-16T23:14:31Z

This patch series was integrated into seen via git@e4f3761.

gitgitgadget · 2020-07-17T00:54:57Z

This patch series was integrated into seen via git@3984bfa.

gitgitgadget · 2020-07-17T20:25:32Z

This patch series was integrated into seen via git@db5f7e8.

gitgitgadget · 2020-07-18T23:31:45Z

This patch series was integrated into seen via git@cb96896.

gitgitgadget · 2020-07-19T01:24:12Z

This patch series was integrated into seen via git@59c3925.

gitgitgadget · 2020-07-20T21:18:34Z

This patch series was integrated into seen via git@e9101b7.

gitgitgadget · 2020-07-21T05:19:28Z

This patch series was integrated into seen via git@9377aae.

gitgitgadget · 2020-07-21T22:12:06Z

This patch series was integrated into seen via git@a29735c.

gitgitgadget · 2020-07-22T17:36:37Z

This patch series was integrated into seen via git@27d8d09.

gitgitgadget · 2020-07-22T22:42:52Z

This patch series was integrated into seen via git@773afbc.

gitgitgadget · 2020-07-24T21:38:36Z

This patch series was integrated into seen via git@9107889.

gitgitgadget · 2020-07-24T23:24:11Z

This patch series was integrated into seen via git@b79c1d0.

gitgitgadget · 2020-07-26T20:21:22Z

This patch series was integrated into seen via git@8af2155.

gitgitgadget · 2020-07-27T16:53:45Z

This patch series was integrated into seen via git@e7fd9f0.

gitgitgadget · 2020-07-30T21:38:49Z

This patch series was integrated into seen via git@5ca82e3.

gitgitgadget · 2020-07-30T21:38:50Z

This patch series was integrated into next via git@5ca82e3.

gitgitgadget · 2020-07-30T21:38:51Z

This patch series was integrated into master via git@5ca82e3.

gitgitgadget · 2020-07-30T21:38:53Z

Closed via 5ca82e3.

phil-blain force-pushed the doc-log-multiple-ranges branch 2 times, most recently from 2e9afad to cdf282f Compare July 3, 2020 03:26

phil-blain changed the title ~~doc: log takes multiple revision ranges~~ doc: factor out git rev-list description and include it in git log doc Jul 3, 2020

phil-blain changed the title ~~doc: factor out git rev-list description and include it in git log doc~~ doc: include git rev-list description in git log doc Jul 3, 2020

phil-blain force-pushed the doc-log-multiple-ranges branch from cdf282f to 3b92378 Compare July 3, 2020 03:36

weekly-digest bot mentioned this pull request Jul 5, 2020

Weekly Digest (28 June, 2020 - 5 July, 2020) #672

Closed

gitgitgadget bot reviewed Jul 7, 2020

View reviewed changes

gitgitgadget bot added the seen label Jul 7, 2020

phil-blain force-pushed the doc-log-multiple-ranges branch from 3b92378 to f035949 Compare July 8, 2020 00:41

phil-blain force-pushed the doc-log-multiple-ranges branch from f035949 to 0aa9026 Compare July 9, 2020 01:58

phil-blain added 3 commits July 8, 2020 21:59

revisions.txt: describe 'rev1 rev2 ...' meaning for ranges

3c57369

The "Specifying ranges" section does not mention explicitly that several commits can be specified to form a range. Add a mention to that effect. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>

git-rev-list.txt: tweak wording in set operations

cf934dd

Tweak a sentence to make it a little more readable. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>

gitgitgadget bot added the next label Jul 14, 2020

This was referenced Jul 26, 2020

Weekly Digest (19 July, 2020 - 26 July, 2020) #682

Closed

Weekly Digest (19 July, 2020 - 26 July, 2020) #683

Closed

gitgitgadget bot added the master label Jul 30, 2020

gitgitgadget bot closed this Jul 30, 2020

phil-blain deleted the doc-log-multiple-ranges branch August 3, 2020 22:54

		@@ -0,0 +1,61 @@
		List commits that are reachable by following the `parent` links from the

doc: include git rev-list description in git log doc #590

doc: include git rev-list description in git log doc #590

Uh oh!

Conversation

phil-blain commented Mar 28, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

phil-blain commented Mar 28, 2020

Uh oh!

gitgitgadget bot commented Mar 28, 2020

Uh oh!

gitgitgadget bot commented Mar 29, 2020

Uh oh!

gitgitgadget bot commented Mar 30, 2020

Uh oh!

gitgitgadget bot commented Mar 30, 2020

Uh oh!

gitgitgadget bot commented Mar 31, 2020

Uh oh!

phil-blain commented Jul 3, 2020

Uh oh!

gitgitgadget bot commented Jul 3, 2020

Uh oh!

gitgitgadget bot commented Jul 5, 2020

Uh oh!

gitgitgadget bot Jul 7, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jul 7, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jul 7, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot Jul 7, 2020

Choose a reason for hiding this comment

Uh oh!

gitgitgadget bot commented Jul 7, 2020

Uh oh!

gitgitgadget bot commented Jul 7, 2020

Uh oh!

gitgitgadget bot commented Jul 7, 2020

Uh oh!

gitgitgadget bot commented Jul 7, 2020

Uh oh!

gitgitgadget bot commented Jul 7, 2020

Uh oh!

gitgitgadget bot commented Jul 9, 2020

Uh oh!

phil-blain commented Jul 15, 2020

Uh oh!

dscho commented Jul 15, 2020

Uh oh!

gitgitgadget bot commented Jul 15, 2020

Uh oh!

gitgitgadget bot commented Jul 15, 2020

Uh oh!

gitgitgadget bot commented Jul 16, 2020

Uh oh!

gitgitgadget bot commented Jul 16, 2020

Uh oh!

gitgitgadget bot commented Jul 16, 2020

Uh oh!

gitgitgadget bot commented Jul 17, 2020

Uh oh!

gitgitgadget bot commented Jul 17, 2020

Uh oh!

gitgitgadget bot commented Jul 18, 2020

Uh oh!

gitgitgadget bot commented Jul 19, 2020

Uh oh!

gitgitgadget bot commented Jul 20, 2020

Uh oh!

gitgitgadget bot commented Jul 21, 2020

Uh oh!

gitgitgadget bot commented Jul 21, 2020

Uh oh!

gitgitgadget bot commented Jul 22, 2020

Uh oh!

gitgitgadget bot commented Jul 22, 2020

doc: include `git rev-list` description in `git log` doc #590

doc: include `git rev-list` description in `git log` doc #590

phil-blain commented Mar 28, 2020 •

edited

Loading