On Fri, Jan 22, 2021 at 12:27:10PM -0800, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> > writes: > > > From: Johannes Schindelin <johannes.schindelin@xxxxxx> > > > > Currently, when called with exactly two arguments, `git range-diff` > > tests for a literal `..` in each of the two. Likewise, the argument > > provided via `--range-diff` to `git format-patch` is checked in the same > > manner. > > > > However, `<commit>^!` is a perfectly valid commit range, equivalent to > > `<commit>^..<commit>` according to the `SPECIFYING RANGES` section of > > gitrevisions[7]. > > > > In preparation for allowing more sophisticated ways to specify commit > > ranges, let's refactor the check into its own function. > > I think the sharing between the two makes sense, but the helper > function should make it clear in its name that this is "the kind of > commit range range-diff wants to take". Among the commit range "git > log" and friends can take, range-diff can take only a subset of it, > and only a subset of it is meaningful to range-diff (e.g. HEAD^@ is > still a commit range you can give to "git log", but it would not > make much sense to give it to range-diff). Does it make so little sense to forbid passing HEAD^@ as a range to range-diff? I can imagine situations where is would make sense, e.g. I often create customer patch stacks from a set of topic branches using octopus merge. To compare two of these ^@ might be handy. My POV is that if it's easy to use the same function (and so the same set of range descriptors) for git log and git range-diff then do so. This yields a consistent behaviour which is IMHO better than preventing people to do things that are considered strange today. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
