for completeness sake: did not hit 'reply all' the first time (thus
skipped replying to the list), so here it is.
On Wed, 16 Jan 2013 20:55:48 +0100, Eric <e...@deptj.eu> wrote:
On Wed, 16 Jan 2013 17:48:52 +0100, "j. van den hoff"
<veedeeh...@googlemail.com> wrote:
hi,
incidentally (when calling fossil from with a script constructing the
suitable call) I noted that
+fossil timeline ''+
(i.e. appending an empty string '' after `timeline') shows the timeline
below (and including *CURRENT*) instead of below the most recent
checkin.
therefore, output is different
if *CURRENT* is not identical to leave.
is this a bug or a feature? I do hope the former since it's really bad
behaviour when driving `fossil' with a script.
I don't get it. No-one would ever put that on the commandline, and if
you are writing a script to construct and run the command, why would you
ever construct that? If it's a consequence of having no other parameters
just make your script check for that and avoid putting in an empty
string.
It makes no sense to me that you are generating something that makes no
what makes not sense to you is that you don't know the use case. the rest
(whether what I do makes sense or not) is not for you to judge, given this
information deficit, I'd say. anyway, I _know_ that I can
catch the exception, thank you very much. it's just an annoyance to have
to when the command line parser could/should do it.
so,
maybe the developers can decide whether it's worth to fix this behaviour
which
I tend to call a bug (which is not altered by the fact that one can work
around it).
there is a difference between a working CLI interface and a nice one. and
fossil's CLI
is not its strongest point I'd say. I believe quite some people have
observed
that already. the GUI seemingly has been given much more "love and
attention", since
it _is_ really nice.
some random examples:
-- fossil timeline -n11 (silently fails)
-- fossil timeline -n 11 does by no means show the last 11 checkins
-- fossil timeline -showfile (silently fails)
-- no chance to keep track of the DAG in the `timeline' output
-- sometimes revisions need a -r flag, sometimes they don't
-- fossil timeline does show a finite subset of revisions but `fossil
finfo filename' does show them all
-- `-n' of `timeline' is called (sort of) `--limit' by `finfo'
-- etc. etc. etc.
for me there are loads of individually small (but cumulative
non-negligible) annoyances which it would be nice _not_ to have. and
observing that this is so should not trigger "knee-jerk" defenses of the
status quo along the line
"what you do makes no sense therefore the current behaviour is good". and
"fix it yourself" is not _that_ helpful either ;-)
j.
sense.
Eric
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
