Hi Junio, On Mon, 18 Mar 2019, Junio C Hamano wrote: > Duy Nguyen <pclouds@xxxxxxxxx> writes: > > >> - This is synonymous to the previous form. If <commit> on > >> + This is synonymous to the previous form. However, > >> + users should prefer the previous form over this form > >> + as this form may be more confusing due to the same > >> + notation having a logically conflicting meaning in > >> + linkgit:git-rev-list[1]-ish commands. If <commit> on > >> one side is omitted, it will have the same effect as > >> using HEAD instead. > > > > This is fine as-is. But another option to reduce even more exposure of > > these forms (both <commit>..[<commit>] and <commit>...[<commit>]) is > > to delete these forms in "DESCRIPTION" section and add maybe "EXOTIC > > SYNTAX" (or something) section after "OPTIONS" for just them. > > There is no other way to express A...B (well, short of spelling it > out as "$(git merge-base A B) B"), so while it makes quite a lot of > sense to discourage A..B (simply because .. is unnecessary and can > be replace with a string with one fewer letter in it, namely " "), > I am not sure if it is wise to throw the three-dot form into the > same basket. I just happened to come upon a use case where the `A..B` way is not actually useless: just after fetching a branch, I got the usual update lines, and it is pretty convenient to be able to use them not only for `git log`, but also for `git diff` invocations, to see what actually changed (from two angles). So maybe you could register this as a vote to not totally strike the A..B notation from the manual. Ciao, Dscho
