Re: [PATCH] doc: log takes multiple revision ranges

[Philippe Blain <levraiphilippeblain@gmail.com>]

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.