cvs log -r1.x shows the log entry for HEAD, instead of the log entry
for 1.x as cvs -r 1.x does. As a result I end up looking at the wrong
log message rather often.
The hysterical raisin is a quirk in rlog(1):
Without argument, the -r option means the latest revision of the
default branch.
Which cvs emulates in 'cvs rlog' (comment from log.c):
/* Unfortunately, rlog accepts -r without an argument to mean that
latest revision on the default branch, so we must support that
for compatibility. */
I don't see a reason to keep this in 'cvs log' since it is not documented.
This behaviour is annoying because it differs from 'cvs diff' and other
cvs commands, and also other tools which support -r (e.g. Subversion and
Mercurial).
Alternatively, we could remove this quirk from 'cvs rlog' as well and make
it incompatible with rlog(1). I never use cvs rlog so I don't really care.
One downside is that a mistyped 'cvs log -r FILENAME' now runs cvs log
on the entire directory looking for tag FILENAME, instead of showing
the HEAD revision for FILENAME. That tends to produce a lot of output.
I'd rather refrain from trying to catch this case and perhaps breaking
something in unexpected ways.
Index: log.c
===================================================================
RCS file: /cvs/src/gnu/usr.bin/cvs/src/log.c,v
retrieving revision 1.3
diff -u -p -r1.3 log.c
--- log.c 3 Jun 2013 17:02:36 -0000 1.3
+++ log.c 15 Jul 2014 09:40:39 -0000
@@ -218,6 +218,7 @@ cvslog (argc, argv)
int err = 0;
int local = 0;
struct option_revlist **prl;
+ const char *optstring;
is_rlog = (strcmp (command_name, "rlog") == 0);
@@ -228,7 +229,8 @@ cvslog (argc, argv)
prl = &log_data.revlist;
optind = 0;
- while ((c = getopt (argc, argv, "+bd:hlNRr::s:tw::")) != -1)
+ optstring = is_rlog ? "+bd:hlNRr::s:tw::" : "+bd:hlNRr:s:tw::";
+ while ((c = getopt (argc, argv, optstring)) != -1)
{
switch (c)
{
