On Tue, 10 Feb 2015 10:06:57 +0100, Stephan Beal <sgb...@googlemail.com>
wrote:
> On Tue, Feb 10, 2015 at 7:17 AM, j. van den hoff
> <veedeeh...@googlemail.com>
> wrote:
>
>> this seems a rather special/remote problem, no? I don't know
>> javascript/jason
>> but would presume, that it would be easy to enforce correct
>> interpretation
>> in this case (enforcing interpretation as string format by
concatenation
>> with empty string
>> or some such)?
>
>
> A remote problem, yes, but i consider it to be a hardening of the code
> against a remote problem.
as pointed out in another post, the principal possibility of getting
pure-digits sha1 hashes still is there,
so there is no 100% solution by incrementing the displayed string length
anyway ...
>
>
>>
>>> and makes parsing by scripts slightly more complicated.
>>>>
>>>
>> depends, at least: not being able to rely on a fixed format/regex
>> pattern
>> matching
>> the sha1 substring seems a potentially rather widespread problem
>> affecting
>> many scripts.
>>
>
> We'll continue to disagree there. i'd rather have robust scripts than
> simpler field length detection (and i'm not convinced a regex is more
> complicated one way or the other).
>
>
>> to be sure it can be fixed (I did so in my case, too, of course, in
>> order
>> to make it work again)
>> but I would maintain that it is desirable to have a fixed sha1
format in
>> the output of
>> fossil.
>>
>
> In the general case, yes, but why risk robustness just for that?
well, "robust" for the case you have in mind, "fragile" for mine...
>
>
>> and if one cannot agree on whether this is good or bad when using 10
>> char
>> substrings (or whatever length), I would like to have a flag/option
>> enforcing the use of the full 40 char hashes in the generated
>>
>
> As Richard said, a 40-char hash in all contexts in tremendous overkill
> (and
> plays havok on the CLI formatting of the timeline, which does
automatic
> word-wrapping).
yes. I was proposing an option (or something in `fsl set') to fix the
displayed sha1 length if so desired to the
full 40 chars (or possibly to some other user-specified value including
10
...). if the output of the timeline
command is piped through a script anyway (the whole point of my request
to
possibly have such an option) it is irrelevant
what happens to the usual CLI formatting.
>
>
>> output (notably timeline and finfo). that for sure would solve your
JS
>> example as it would my "does not match a fixed regex and messess up
>> keys in
>> tcl dictionary" problem.
>>
>
> A regex can catch either case just as easily. A fixed-width tool like
> 'cut'
> cannot.
sure, getting the regex to match both is easy but the specific problem I
have is a bit different. the script in question
(http://fossil.0branch.com/fsl/home) is a wrapper around fossil to
facilitate command line interaction with fossil. I modified that
script at a few places to a) tweak the timeline output in a way I like
and
b) to be able to use for my personal local interaction
with the repo incremental checkin numbers
instead of the sha1 hashes. now, for that purpose the script scans the
timeline once and builds up a tcl dictionary with
key/value pairs containing sha1/incremental_number pairs (or vice
versa).
the problem I ran into does _not_ occur because of the variable length
of the displayed hashes per se, but because `finfo -b' does _not_ use
those, but rather stays with exactly 10 digits no matter what. so
obviously at that point a problem occurs because the sha1 "key" is
different for `timeline' and simple `finfo' on the one hand and `finfo
-b'
on the other. this is not good in my view.
for sure one can fix this in the script, too (I did), but one should not
need to have to. rather, I would agree with richard (that's how
I understood his response) that the whole thing would benefit from a
clean
up (resulting in some fossil-wide consistent behaviour of how the sha1
hashes are displayed).
>
--
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
