[fossil-users] cmdline arguments for repopsitory are inconsequent
on some commands one has to use -R repo e.g. sync pull push and others not clone ui server -R seems redundant. -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] cmdline arguments for repopsitory are inconsequent
On Thu, Aug 8, 2013 at 10:47 AM, Rene renew...@xs4all.nl wrote:
-R seems redundant.
It's not _entirely_ redundant - in some cases it changes how the arguments
are processed. Yes, there are inconsistencies there, but some of the
argument handling relies on one or the other approach. When the app looks
for a CLI flag, e.g. -R, fossil actually removes that flag and its argument
from the global argument list, which changes the argument count, and many
of the commands use logic like if(g.argc==3){...}, so there non-obvious
side effects when changing whether a command expects -R or not. It the
context of libfossil, that's been one of the minor points on the list of
things to consider, and while i don't much care for inconsistency in
software, i _think_ that i'll end up doing it similar to how it is done
now. e.g. a clone implies a -R (but normally in the form of a URL), and
doesn't need a flag. The commands you listed where -R is optional almost
always derive their repo db from the current checkout (which is why -R is
not required). i'm not sure why ui/server don't require -R, but instead
take their repo filename as a non-flag argument. Historical in nature, i
guess.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] cmdline arguments for repopsitory are inconsequent
On Thu, 08 Aug 2013 10:58:58 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Thu, Aug 8, 2013 at 10:47 AM, Rene renew...@xs4all.nl wrote:
-R seems redundant.
It's not _entirely_ redundant - in some cases it changes how the
arguments
are processed. Yes, there are inconsistencies there, but some of the
argument handling relies on one or the other approach. When the app looks
for a CLI flag, e.g. -R, fossil actually removes that flag and its
argument
from the global argument list, which changes the argument count, and many
of the commands use logic like if(g.argc==3){...}, so there non-obvious
side effects when changing whether a command expects -R or not. It the
context of libfossil, that's been one of the minor points on the list of
things to consider, and while i don't much care for inconsistency in
software, i _think_ that i'll end up doing it similar to how it is done
just my 2c: I _do_ care for inconsistencies in the CL user interface and
the
-R thing is one of them: I always can only partly remember when it's
required
and when not. I'm sure there are reasons why it is the way it is. but I at
least
would consider it a relevant step forward if the CLI would be made more
consistent.
by and then I have complained about this in the past already.
e.g, the mixing of
-c
--c
-word
--word
style options was/partly is another issue. I would argue for reducing it
to -c and --word, probably, which would
also allow to tolerate omission of the blank between short option letter
and its argument
as in fossil diff -r1234 (just like with most unix commands). I've just
checked: it seems (is this true?) that this
problem is now only present with `fossil help' where in fact you have
`--c' and `-word' type options
while otherwise it seems to be already `-c' and `--word'.
a further small issue is that
on the one hand fossil has the necessary logic to accept unique partial
matches of commands
(e.g. `fossil info' vs. `fossil inf' (both OK) vs `fossil in' (ambiguous))
but apparently
none to do the same for long options. could the partial match logic not be
extended to long options?
overall, for some people I'm sure these sort of things are not less
important than a nice GUI. ;-)
j.
now. e.g. a clone implies a -R (but normally in the form of a URL), and
doesn't need a flag. The commands you listed where -R is optional almost
always derive their repo db from the current checkout (which is why -R is
not required). i'm not sure why ui/server don't require -R, but instead
take their repo filename as a non-flag argument. Historical in nature, i
guess.
--
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
Re: [fossil-users] cmdline arguments for repopsitory are inconsequent
On Thu, 08 Aug 2013 12:23:56 +0200, Stephan Beal sgb...@googlemail.com wrote: On Thu, Aug 8, 2013 at 12:14 PM, Stephan Beal sgb...@googlemail.com wrote: Sorry for the confusion: don't much care for is another way of saying do not like, and we agree completely that these inconsistencies are not ideal. Minor clarification for the non-native speakers: don't care FOR' means do not like, but do not care ABOUT means do not have strong feelings regarding... thanks. must have been sleeping in school when that difference was explained ;-) so, sorry for the noise. -- 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
Re: [fossil-users] cmdline arguments for repopsitory are inconsequent
On 2013-08-08 10:58, Stephan Beal wrote:
On Thu, Aug 8, 2013 at 10:47 AM, Rene renew...@xs4all.nl wrote:
-R seems redundant.
It's not _entirely_ redundant - in some cases it changes how the
arguments are processed. Yes, there are inconsistencies there, but
some of the argument handling relies on one or the other approach.
When the app looks for a CLI flag, e.g. -R, fossil actually removes
that flag and its argument from the global argument list, which
changes the argument count, and many of the commands use logic like
if(g.argc==3){...}, so there non-obvious side effects when changing
whether a command expects -R or not. It the context of libfossil,
that's been one of the minor points on the list of things to consider,
and while i don't much care for inconsistency in software, i _think_
that i'll end up doing it similar to how it is done now. e.g. a clone
implies a -R (but normally in the form of a URL), and doesn't need a
flag. The commands you listed where -R is optional almost always
derive their repo db from the current checkout (which is why -R is not
required). i'm not sure why ui/server don't require -R, but instead
take their repo filename as a non-flag argument. Historical in nature,
i guess.
--
- stephan beal
http://wanderinghorse.net/home/stephan/ [1]
http://gplus.to/sgbeal [2]
Links:
--
[1] http://wanderinghorse.net/home/stephan/
[2] http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Well lets go the other way a repo, if not in an checkout, must always
be specified with -R.
and maybe if a -R repo is specified in a checkout the -R takes
precedent.
--
Rene
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] cmdline arguments for repopsitory are inconsequent
On Thu, Aug 8, 2013 at 10:29 PM, Rene renew...@xs4all.nl wrote: Well lets go the other way a repo, if not in an checkout, must always be specified with -R. and maybe if a -R repo is specified in a checkout the -R takes precedent. When a checkout is opened, its corresponding repo db is automatically opened as well. Checkout-open fails if the corresponding repo cannot be opened, e.g. it's been moved or deleted. Commands which require a checkout do not explicitly look for -R, but that they instead do this: http://fossil-scm.org/index.html/artifact/770bdc0bc0647650f1c9b59d229964082c4d61f1?ln=1373 Commands which (indirectly) use -R (meaning they do not require a checkout) do this: http://fossil-scm.org/index.html/artifact/770bdc0bc0647650f1c9b59d229964082c4d61f1?ln=866 and that routine then checks for -R before looking for a checkout/repo combination, which, in essence, implements what you suggest: http://fossil-scm.org/index.html/artifact/0adc1aa79c24d8bc88b32e2ef7a8f29d32619d79?ln=1054-1084 FWIW: the the new/prototype libfossil code follows that same heuristic, but that's only a happy accident - it just seemed like the most logical choice. - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
