On Sat, 24 Nov 2012 17:40:30 +0100, Richard Hipp <d...@sqlite.org> wrote:
On Sat, Nov 24, 2012 at 10:35 AM, j. v. d. hoff
<veedeeh...@googlemail.com>wrote:
On Sat, 24 Nov 2012 16:23:05 +0100, Martin Gagnon <eme...@gmail.com>
wrote:
Le 2012-11-24 10:16, j. v. d. hoff a écrit :
On Sat, 24 Nov 2012 15:43:57 +0100, Stefan Bellon <sbel...@sbellon.de>
wrote:
On Sat, 24 Nov, j. v. d. hoff wrote:
I would like to issue something like `fossil artifact [1234] -f
myfile.txt'
I may be misunderstanding, but isn't
fossil finfo -p -r [1234] myfile.txt
what you want?
yes exactly, thanks a lot!
caught in the act of no reading the help pages thoroughly enough,
damn.
;-)
an alias `fossil cat` would be more intuitive, though...
More intuitive for people that's come from hg. For people that use CVS
I would say for all unix/linux/macos people. I would never have guessed
that I should read completely through the `finfo' help page. but
anyhow...
Your feedback is useful. What is "obvious" to experienced Fossil users
might not be apparent at all to newbies. And there isn't really any way
for us to know where the pitfalls are without getting this kind of
feedback. So please keep complaining.
hope this comes not across as "complaining"...
and I'm of course aware that fossil does not intend to emulate the `svn' or
`mercurial' ui.
Yes, it would be good to improve the documentation. Volunteers?
well that needs people who know the system. -- but here are a few notes
I took today (at least the list of typos in the help pages might be worth
reading ;-)):
8<---------------------------------------------------------------------------------------
fossil 1.24 command line user interface
Remarks concerning the fossil 1.24 command line user interface
Quirks
1. Check in with empty commit message should not be allowed: in my view
empty commit messages should be interpreted as intentional abort of
the check in (and a “commit aborted” message should be issued)
2. Short options: these should not enforce a blank between option
letter
and argument in order to comply with the de facto (maybe not POSIX?)
standard UNIX behavior.
3. There are (one-dash, one-character) short options and (two-dashes,
multiple-character) long options but there are also at least two
one-dash/multiple-character options, namely -showfiles (for
timeline)
and -help (as an option to command instead of using the help command
itself).
In my view the latter should be abolished in order to adhere to more
standard usage (like GNU readline). This, moreover, should allow to
parse short options (one dash/one letter) differently by not
enforcing
blanks between option and argument. Or would it not due to the
presence of hyphenated options such as --date-override? In this case
maybe underscores should replace the hyphen in these commands in
some
future release?
4. Command options are handled not consistently across different
commands
* Many commands only have long options. Some have short options
as
alias of a long option but some short options do not correspond
to a long option. Example of the latter: fossil diff -i
* Where there a equivalent short and long options the help pages
usually list them in the form --long | -l but sometimes the
other
way round (e.g. for ui: -P|--port) which is inconsistent. I
think
short options should always be listed first.
* fsl time -showfile is a no-op (does nothing) instead of
interpreting it as meaning -showfiles or giving an error
message
5. Error messages (or absence thereof)
* fossil time -showfile: Error Message: none (silently ignored)
6. fossil mv/rm: These should act on the files in the checkout as well
by
default.
Typos in the help pages
1. fossil help configuration: “Write to FILENAME exported
>>_configuraton_<< information for AREA.”
2. fossil help revert: “If a file is reverted >>_accidently_<<, it can
be
restored using”
3. fossil help ui: “that contains one or more >>_rspositories_<< with
names ending in ".fossil".”
4. fossil help settings: “https-login Send login >>_creditials_<< using
HTTPS instead of HTTP”
5. fossil help tag: “the tag value >>_propages_<< to all descendants of
CHECK-IN”
6. fossil help wiki: “case→>_insentively_<< by name.”
Wish list
1. Customization via a command alias mechanism, such as
alias cat "finfo -p"
2. Consistent command argument syntax, providing single dash/single
character short options as well as equivalent two dashes/multiple
character long options for all commands/options.
3. Add a fossil help --all option concatenating in alphabetical order
all
help pages in order to make them easily searchable for the user (by
piping them through more, for example)
4. add an enumeration to the timeline of the local repository and make
this enumeration usable as a substitute for the SHA1 hashes of the
checkins in commands like fossil finfo -p -r rev somefile.txt. ‘hg’
does this by prepending the enumeration colon separted to the hash:
changeset: 46:b2008223fa4a Although the enumeration is meaningless
across connected repositories (at least if run with autosync off),
it
is very helpful locally when specifying a revision to some command
(diff, tag, etc).
5. add a syntax fossil diff -r rev1:rev2 to better comply with expected
behaviour (svn, hg, …)
--------------------------------------------------------------------------
Last updated 2012-11-24 18:26:09 CET
8<---------------------------------------------------------------------------------------
I won't rule out having two or more commands that do the same thing. If
"fossil cat" is a useful usability enhancement, then it should be
considered. Similar things have happened before. Ex: we added "fossil
it's sort of marginal but I'd welcome this addition.
init" as a synonym for "fossil new" since "init" seems to be the keyword
that Git users expect.
as would do `hg' users. and `bzr' users.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
