[fossil-users] Extra code in autosetup/local.tcl

2017-03-26 Thread Steve Bennett
Hi Joe,

I was just looking at autosetup/local.tcl and I see back in 2014 you committed 
3a5c9b34f39be09b 
contain a bunch of extra code. It looks like this is copied from jim local.tcl

I suggest deleting everything from '# The complex extension checking is done 
here.' onwards
to avoid confusion.

Cheers,
Steve


--
Embedded Systems Specialists - http://workware.net.au/
WorkWare Systems Pty Ltd
W: www.workware.net.au  P: +61 434 921 300
E: ste...@workware.net.au







___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

2017-03-26 Thread John P. Rouillard
Hi all:

In message <787dd2f8-edf8-4caf-5d8c-b63cac39a...@marples.name>,
Roy Marples writes:
>On 26/03/2017 22:19, Joerg Sonnenberger wrote:
>> On Sun, Mar 26, 2017 at 07:49:30PM +0200, Tomasz Konojacki wrote:
>>> For someone with a different background, there is *nothing* nice about
>>> fossil dumping thousands of lines to the terminal. In fact, I think it
>>> scares off newbies who only used git before.
>>
>> I quite disagree. Terminal output is C&P friendly. Pager output tends to
>> disappear with the pager. That's a real world UX issue I have with the
>> git default settings.
>
>Pager output disappearing with the pager (I assume when asking the pager 
>to exit) is an issue with the pager.
>
>As Fossil is a single binary to do everything approach, I'm sure that a 
>Fossil pager would not suffer this defect.

IIRC the patch is using an external pager right? There is not a pager
being build into fossil.

>Yes, terminals have scroll bars and can page up, but that's the wrong 
>approach as well.
>
>When viewing a diff I want to start at the top and scroll down, not 
>start at the bottom and scroll up, hence a pager makes perfect sense.

As long as it can be turned off so wrappers around fossil (fsl, emacs
vc mode, other programs using the cli as a fossil interface) are not
broken if terminal detection fails, I'm meh about it.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.


On 26/03/2017 22:19, Joerg Sonnenberger wrote:
> On Sun, Mar 26, 2017 at 07:49:30PM +0200, Tomasz Konojacki wrote:
>> For someone with a different background, there is *nothing* nice about
>> fossil dumping thousands of lines to the terminal. In fact, I think it
>> scares off newbies who only used git before.
>
> I quite disagree. Terminal output is C&P friendly. Pager output tends to
> disappear with the pager. That's a real world UX issue I have with the
> git default settings.

Pager output disappearing with the pager (I assume when asking the pager 
to exit) is an issue with the pager.

As Fossil is a single binary to do everything approach, I'm sure that a 
Fossil pager would not suffer this defect.

Yes, terminals have scroll bars and can page up, but that's the wrong 
approach as well.

When viewing a diff I want to start at the top and scroll down, not 
start at the bottom and scroll up, hence a pager makes perfect sense.

Roy
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

2017-03-26 Thread Roy Marples



On 26/03/2017 22:19, Joerg Sonnenberger wrote:

On Sun, Mar 26, 2017 at 07:49:30PM +0200, Tomasz Konojacki wrote:

For someone with a different background, there is *nothing* nice about
fossil dumping thousands of lines to the terminal. In fact, I think it
scares off newbies who only used git before.


I quite disagree. Terminal output is C&P friendly. Pager output tends to
disappear with the pager. That's a real world UX issue I have with the
git default settings.


Pager output disappearing with the pager (I assume when asking the pager 
to exit) is an issue with the pager.


As Fossil is a single binary to do everything approach, I'm sure that a 
Fossil pager would not suffer this defect.


Yes, terminals have scroll bars and can page up, but that's the wrong 
approach as well.


When viewing a diff I want to start at the top and scroll down, not 
start at the bottom and scroll up, hence a pager makes perfect sense.


Roy
___
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] Endless loop in fossil merge (legacy version)

2017-03-26 Thread Jan Nijtmans
2017-03-26 20:02 GMT+02:00 Francois Vogel:
> So it works with fossil-1.33 but not with 1.35.
>
> Is this problem known? It looks fixed with 2.1 (but it's much slower than
> with 1.33):

Yes, this was a known bug fixed here:


[fossil-users] Newbie Fossil Hosting and Culture

2017-03-26 Thread Martin Vahi
>...
> Date: Sun, 26 Mar 2017 13:18:08 -0400
> From: Richard Hipp 
>...
> Subject: [fossil-users] GitLab v. Fossil. Was: Eric Raymond (a.k.a.
>   ESR) haspublished an SCM
> Message-ID:
>   
>...
> What can Fossil and/or GitLab do to make it easier for newbies to set
> up new project instances on their own private servers?  (See
> https://www.fossil-scm.org/fossil/doc/trunk/www/server.wiki for the
> documentation on how to create a server instance for Fossil.)
>...

I can't speak for others, but as a person/freelancer, who
has created my own PHP-webapp for hosting/semi-hiding
client project specific Fossil repositories, along my
open source project repositories,
some pre-made wrapper that allows the Fossil
to be used at cheap PHP-hosting sites might be very practical.
Link to my webapp that I wrote only for
my personal use (me + my clients)
and which is currently too big of a mess to be shared:

http://business.softf1.com/flaws/en/
(The semi-hiding part is based on hard-to-guess, long, URLs.
 For demo, please compare redirection URLs
 of projects with the project IDs:
  silktorrent{my open, non-hidden, repo}
  testrepo_1 {tests the semi-hiding feature}

The few-second-delay is a security related,
intentional, sleep call at my PHP code.
)

My current version, at my site, which I have been using for years,
uses some hack that uses some mixture of PHP, CGI, but
I remember that once upon a time I made some experiment, where
a plain PHP-program executed "a console program"(fossil binary)
and then dumped the output of that "console program"
as the reply to the query that the PHP program received.
However, I haven't tested that PHP-wrapper extensively
and as nobody really asked for it, I postponed that task, because it
takes some effort to document it and package it all properly.
I remember that a thing that I needed to test and that
I left untested was that the PHP interpreter has a parameter
which determines the maximum upload size of a file and
I wanted to find out, whether the chunks that the Fossil
uses for uploading files greater than the PHP upload limit
are kept, or at least can be configured to be kept,
"small enough" to be below the upload limits of the PHP interpreter.

I offer my clients, without any extra charge,
an opportunity to download their project's repository.
The idea behind the wrapper is that the PHP-wrapper
was supposed to simplify A CHEAP re-hosting of that repository.
For example, in Estonia there's even a web hosting service
that offers a PHP based hosting service for a price
that is literally about 1EUR/month:

https://www.planet.ee/
(It targets only Estonian market, so their web page
 does not even have English texts, but in practice
 literally all of the younger generation of Estonians
 speaks/reads/writes English, so anybody can send
 an e-mail in English to any Estonian company,
 even, when the use of English is not advertised.)

As a matter of fact, the main reason, why I ended
up using Fossil at all, is that I wished to host/create
private repositories CHEAPLY for every client,
without being dependent on any American or
Western-European hosting providers.

The possibility to give to a client everything,
the wiki, the bug-reports, all of the project history,
in one easily re-hostable file PERFECTLY matches my use case.
I also love the idea that the Fossil is created CAREFULLY,
WITH CARE, not slammed together sloppily and forgotten to bitrot.
(Read: I like the development/work discipline of the Fossil developers,
specially that of the Richard Hipp)

The background story, why I want to host the repositories myself,
instead of using a paid private repository hosting service like GitHub,
consists of mainly 2 points:

x) 5$/month for every GitHub-or-alike private repository
   for years for a micro-project that
   only has a whole stage-1 budget of 300$ is absurdly expensive.

x) I want my client repositories to be outside of the
   grasp of American style censorship.
   (Privacy is currently missing, because I'm buying the hosting
service and the hosting service provider has access to the
repository files and internet traffic.)

A few words about the American/Wester-European style censorship:

Hosting service quality, at least according to my
very subjective view, includes
the upload/download speeds, HDD-speeds and UPTIME.
The UPTIME literally APPROACHES ZERO,
if the hosting service provider
TAKES THE HOSTED MATERIAL/PROCESSES/VirtualAppliances OFFLINE.
All those fancy redundant power supplies and
redundant internet connections that the hosting provider
has at its data center become TOTALLY USELESS,
if the hosting provider takes its clients' material offline,
including the cases, where the hosting provider does it
due to Censorship. For example, one 

Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager

2017-03-26 Thread Joerg Sonnenberger
On Sun, Mar 26, 2017 at 07:49:30PM +0200, Tomasz Konojacki wrote:
> For someone with a different background, there is *nothing* nice about
> fossil dumping thousands of lines to the terminal. In fact, I think it
> scares off newbies who only used git before.

I quite disagree. Terminal output is C&P friendly. Pager output tends to
disappear with the pager. That's a real world UX issue I have with the
git default settings.

Joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


[fossil-users] Push transfer script

2017-03-26 Thread Ryan Dingman

I’m working on setting up my Fossil server so that certain tasks are kicked off 
after someone pushes changes to it. Push transfer scripts seem like the right 
tool for this. Because of the nature of the work that needs to happen after a 
push, I have my TH1 script ‘tclInvoke exec’ an external script that takes the 
hash of a checkin contained in the push. Something like:

tclInvoke exec /bin/sh -c “foo.sh $hash" >> /tmp/commit_hook.log

Where $uuid is a TH1 variable containing the hash of a checkin.

My script needs to collect some information about the checkin so it does the 
following to get the manifest:

echo "select content(‘${hash}');" | fossil sql -R foo.fossil

When testing the script in isolation, this works great. However, when run from 
a push transfer script, the artifact identified by the hash isn’t found.

Looking through the source to Fossil it looks like the push transfer script 
gets executed before the database transaction for the push has been committed. 
So, it makes sense that my script wouldn’t find the artifact in question.

The Fossil UI describes the Push transfer script as: 'Specific TH1 code to run 
after "push" transfer requests.’ I was reading the “after” to mean after the 
push had been committed to the Fossil database, but this isn’t how it is 
implemented.

This leaves me with the following questions:

- Is it intentional that the push transfer script is executed before the push 
has been committed or is this a bug? (I can see the utility of a script 
executes before a push is committed in order to give it the chance to reject 
the push, but I’m not sure if this is the intent here).
- If it is intentional, would a patch implementing a “post-push” transfer 
script that only gets executed after the push has been committed be acceptable?
- Are there other suggestions that I haven’t though of?

Thanks,

--
Ryan


___
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] Fossil Captchas

2017-03-26 Thread Stephan Beal
On Sun, Mar 26, 2017 at 9:06 PM, Richard Hipp  wrote:

> I am also now reminded that there is an option on the Setup/Access
> page that adds a button to the CAPTCHA that completes the captcha
> automatically.  That would nicely facility access via screen readers.
>

i was about to say the same thing (Admin ==> Setup ==> auto-captcha), but
it appears to have been broken. On my recently-update site it's not
working, anyway (the button doesn't appear). i haven't looked into why (i'm
still limited to how much i can operate a keyboard), but speculate that it
"might" have been purposely removed, as bots can mostly understand
JavaScript nowadays.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Fossil Captchas

2017-03-26 Thread Richard Hipp
On 3/26/17, Damien Sykes-Lindley  wrote:
> Hi Richard,
> Forgive me if I'm mistaken, but I think the anonymous password shows itself
> as a captcha. The following quote from the antibot article would seem to
> confirm this:
>
> "The "anonymous" user is also available for humans who do not wish to
> identify themselves. The difference is that "anonymous" requires a login
> (using a password supplied via a CAPTCHA)"

Hmm...  I suppose you do have to enter the CAPTCHA if you want to log
in as anonymous.  My point is, though, that sites like Fossil and
SQLite are configured such that anonymous log-in is not required.

I am also now reminded that there is an option on the Setup/Access
page that adds a button to the CAPTCHA that completes the captcha
automatically.  That would nicely facility access via screen readers.

>
> Below that there are several lines of underscores and bars, I'm assuming
> this is an ascii-based captcha or some other method of obscurity, since I
> can't find any clear 8-digit hexadecimal sequence.

Correct.  The CAPTCHA is an ascii-art rendering of the 8-digit hex key.

-- 
D. Richard Hipp
d...@sqlite.org
___
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] Fossil Captchas

2017-03-26 Thread Damien Sykes-Lindley

Hi Richard,
Forgive me if I'm mistaken, but I think the anonymous password shows itself 
as a captcha. The following quote from the antibot article would seem to 
confirm this:


"The "anonymous" user is also available for humans who do not wish to 
identify themselves. The difference is that "anonymous" requires a login 
(using a password supplied via a CAPTCHA)"


The login page states:
"Visitors may enter anonymous as the user-ID with the 8-character 
hexadecimal password shown below:"


Below that there are several lines of underscores and bars, I'm assuming 
this is an ascii-based captcha or some other method of obscurity, since I 
can't find any clear 8-digit hexadecimal sequence.

Cheers.
Damien.
-Original Message- 
From: Richard Hipp

Sent: Sunday, March 26, 2017 7:38 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Fossil Captchas

On 3/26/17, Damien Sykes-Lindley  wrote:

Hi there,
Is there any chance an option can be added in Fossil whereby, when/where a
captcha is required, the task is to answer a question instead?



That could be done, in theory, but augmenting a few routines in the
captcha.c source file.  Consider sending in patches.

But, I thought the design of Fossil had moved past the need for
captchas for robot control.  See
http://localhost:591/fossil/doc/trunk/www/antibot.wiki for details.  I
just now logged off and went surfing about on the canonical Fossil
repo and did not find any pages requesting a captcha.  Do you have an
example that I have overlooked?
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 


___
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] fossil 1.2->2.1 - hash policy "auto" doesn't seem to work and gives SQL error.

2017-03-26 Thread Richard Hipp
On 3/26/17, arnoldemu  wrote:
>>fossil update
> Autosync: http:///arnold
> Autosync failed.
> This fossil repository is not compatible with the version of your client.
> You need version 2.1 or later. Please visit http://www.fossil-scm.org and
> download a new client.

The difficulty there is that when the older version of Fossil that is
running the "update" was written, we didn't know about version 2.1 and
so there wasn't any way for us to add an error message about needing
2.1.  :-)
-- 
D. Richard Hipp
d...@sqlite.org
___
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] GitLab v. Fossil. Was: Eric Raymond (a.k.a. ESR) has published an SCM

2017-03-26 Thread Jan Danielsson
On 03/26/17 19:18, Richard Hipp wrote:
[---]
> (i)  With Fossil, one can click on two nodes of the graph to see a
> diff between those two nodes.  With GitLab, you apparently have to go
> to the separate "Compare" screen, then many type in (or paste in) hash
> name prefixes of the two check-ins you want to compare.  This seems
> rather clumsy.  But maybe I'm missing something.

   This is the same in Bitbucket.

   I use the version compare feature in the timeline in Fossil *a lot*;
I'd almost be willing to stretch to say "literally daily", but I'm sure
there's been a day when I haven't used it -- but you get the point.

   When I helped install a development environment based on the
Atlassian products a while ago I was quite shocked that Bitbucket didn't
support the feature.  Considering how useful it is, I had never occurred
to me that a modern UI _wouldn't_ have it.

   Anyway, I searched around to see if it was available in an alpha
version or something somewhere, and quickly realized others wanted the
feature as well.  However, no good news on that front:  The idea was
apparently "No, you use tool X for that.".  (As it happens, this tool X
was a desktop application for the local checkout, which - in my mind -
kind of defeated the purpose).

   Maybe this is tangentially related to the cathedral vs bazaar
discussion; with Fossil, you typically have a central point where "all"
the useful checkins end up.

-- 
Kind regards,
Jan Danielsson

___
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] fossil 1.2->2.1 - hash policy "auto" doesn't seem to work and gives SQL error.

2017-03-26 Thread arnoldemu

Hi Richard,

>The "auto" hash-policy automatically flips to "sha3" as soon as Fossil
>sees one or more SHA3 artifacts in the repo.  Since your repo contains
>SHA3 artifacts, you won't be able to set the policy to "auto" because
>it will immediately and automatically flip to "sha3".
>
>That is the way "auto" is designed to work.
I expected it to automatically do that when I did a "fossil update" and get the 
files provided I had fossil 2.1 installed.
I have autosync set and I thought that would then sync from the server and 
automatically switch to sha3 and get the new files.

>How were you expecting it to work?  How can the documentation be improved?
Setting the hash policy was fine that worked without confusion.

When I then accessed the remote repository from another machine I expected it 
to automatically see the change
and automatically switch the client to the new policy. If the client needed to 
be updated then ideally fossil client should tell me.

It would have been great if this is what had happened:

>fossil update
Autosync: http:///arnold
Autosync failed.
This fossil repository is not compatible with the version of your client. You 
need version 2.1 or later. Please visit http://www.fossil-scm.org and download 
a new client.

Then after installing the new client and with the hash-policy set to auto:

>fossil update
Autosync: http:///arnold
Hash-policy on server has been updated to sha3. Switching to sha3 for client.
... <- normal sync here with cards and files listed.

If I had set the policy to sha1 or other:
>fossil update
Autosync: http:///arnold
Autosync failed.
The fossil repository is using sha3 hash policy. Please set hash-policy to sha3 
or use auto.

Maybe for now, instead of (or in addition) to the errors I saw it could give a 
command to try to resolve the issue such as one that causes the database to 
update.

Thank you

Kevin


___
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] Fossil Captchas

2017-03-26 Thread Richard Hipp
On 3/26/17, Damien Sykes-Lindley  wrote:
> Hi there,
> Is there any chance an option can be added in Fossil whereby, when/where a
> captcha is required, the task is to answer a question instead?


That could be done, in theory, but augmenting a few routines in the
captcha.c source file.  Consider sending in patches.

But, I thought the design of Fossil had moved past the need for
captchas for robot control.  See
http://localhost:591/fossil/doc/trunk/www/antibot.wiki for details.  I
just now logged off and went surfing about on the canonical Fossil
repo and did not find any pages requesting a captcha.  Do you have an
example that I have overlooked?
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


[fossil-users] Endless loop in fossil merge (legacy version)

2017-03-26 Thread Francois Vogel

Hi,

FYI, this is on Windows in the Tk repository:

http://core.tcl.tk/tk/

I get an endless loop in fossil as follows:

C:\Users\francois\Documents\Development\tcltk-fossil\tk>fossil version
This is fossil version 1.35 [3aa86af6aa] 2016-06-14 11:10:39 UTC

C:\Users\francois\Documents\Development\tcltk-fossil\tk>fossil status
repository: 
C:/Users/francois/Documents/Development/tcltk-fossil/tk/../tk.fossil

local-root: C:/Users/francois/Documents/Development/tcltk-fossil/tk/
config-db:C:/Users/francois/AppData/Local/_fossil
checkout: 44e27f3e7b8f6b7e2916193fa35edb5c6d34dab3 2017-01-25 
22:05:51 UTC
parent:   bfb8e49e36e348536b46afb72fa0029645dc921d 2017-01-23 
09:45:18 UTC
child:b20b6d95b46553a7eb856529faf5d3d440fcde0b 2017-03-26 
15:14:51 UTC
merged-into:  8912c3c5a73ccd7b684e52403094e5c8d0903cb0 2017-01-25 
22:08:59 UTC

tags: core-8-5-branch
comment:  Fix [140ea8ab38]: Long text lines are not drawn on 
Windows. (user: pspjuth)


C:\Users\francois\Documents\Development\tcltk-fossil\tk>fossil merge 
--dry-run --baseline 1896a918 tip-464

^C

(I had to cancel it manually: 100% CPU for many many minutes)

C:\Users\francois\Documents\Development\tcltk-fossil\tk>fossil-1.33.exe 
merge --dry-run --baseline 1896a918 tip-464

UPDATE generic/ks_names.h
UPDATE xlib/X11/keysymdef.h
MERGE doc/keysyms.n
MERGE win/tkWinKey.c
REMINDER: this was a dry run - no files were actually changed.

(processed the command lickity split, with correct output)

So it works with fossil-1.33 but not with 1.35.

Is this problem known? It looks fixed with 2.1 (but it's much slower 
than with 1.33):


C:\Users\francois\Documents\Development\tcltk-fossil\tk>fossil-2.1.exe 
merge --dry-run --baseline 1896a918 tip-464

UPDATE generic/ks_names.h
UPDATE xlib/X11/keysymdef.h
MERGE doc/keysyms.n
MERGE win/tkWinKey.c
REMINDER: this was a dry run - no files were actually changed.

You can try it on the above given repo.

Thanks,
Francois

___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

2017-03-26 Thread Tomasz Konojacki
On Sun, 26 Mar 2017 19:25:25 +0200
Christophe Gouiran  wrote:

> I see that most of you complain about this proposed feature.

TBH, many members of this list live in the UNIX greybeard bubble, and
that's why there is so much opposition to this feature. They're used to
the original UNIX way and they have different expectations than most of
users.

For someone with a different background, there is *nothing* nice about
fossil dumping thousands of lines to the terminal. In fact, I think it
scares off newbies who only used git before.

Anyway, there's no point in arguing about it. This feature will be
optional, no one is forcing anyone to change their habits.


___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

2017-03-26 Thread Scott Robison
On Mar 26, 2017 11:25 AM, "Christophe Gouiran" 
wrote:

Please find as attached file another patch which:

   1. First test for a real terminal before spawning the pager command.
   2. No more paginate json command.

I see that most of you complain about this proposed feature.

It was only a proposition, if it is not accepted I won't care.

However, it would be possible to make both world happy:

   1. Those who don't like this feature simply don't set a pager-command
   setting.
   2. Those who want to use it set a pager-command setting.

And, IMHO adding or removing a '|' at the end of command names is not a
maintenance nightmare.

I'm sorry if I've offended. My point was that one code path that works with
all future commands or changes to commands is not bad, even if it is not
something I will personally use. Needing to tweak code paths unrelated to
DVCS functionality to maintain this feature going forward seems less than
ideal.

I do commend you for stepping forward to implement it. I just disagree with
the idea of making it command specific.
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

2017-03-26 Thread Christophe Gouiran
Please find as attached file another patch which:

   1. First test for a real terminal before spawning the pager command.
   2. No more paginate json command.

I see that most of you complain about this proposed feature.

It was only a proposition, if it is not accepted I won't care.

However, it would be possible to make both world happy:

   1. Those who don't like this feature simply don't set a pager-command
   setting.
   2. Those who want to use it set a pager-command setting.

And, IMHO adding or removing a '|' at the end of command names is not a
maintenance nightmare.


Note : provided patch can be applied against latest version of the trunk
([a0ce33c90b] at the time of this writing).
Index: src/allrepo.c
==
--- src/allrepo.c
+++ src/allrepo.c
@@ -418,15 +418,15 @@
 if( showLabel ){
   int len = (int)strlen(zFilename);
   int nStar = 80 - (len + 15);
   if( nStar<2 ) nStar = 1;
   fossil_print("%.13c %s %.*c\n", '*', zFilename, nStar, '*');
-  fflush(stdout);
+  fflush(our_stdout);
 }
 if( !quiet || dryRunFlag ){
   fossil_print("%s\n", zSyscmd);
-  fflush(stdout);
+  fflush(our_stdout);
 }
 rc = dryRunFlag ? 0 : fossil_system(zSyscmd);
 free(zSyscmd);
 free(zQFilename);
 if( stopOnError && rc ){

Index: src/blob.c
==
--- src/blob.c
+++ src/blob.c
@@ -859,17 +859,17 @@
   if( zFilename[0]==0 || (zFilename[0]=='-' && zFilename[1]==0) ){
 blob_is_init(pBlob);
 #if defined(_WIN32)
 nWrote = fossil_utf8_to_console(blob_buffer(pBlob), blob_size(pBlob), 0);
 if( nWrote>=0 ) return nWrote;
-fflush(stdout);
-_setmode(_fileno(stdout), _O_BINARY);
+fflush(our_stdout);
+_setmode(_fileno(our_stdout), _O_BINARY);
 #endif
-nWrote = fwrite(blob_buffer(pBlob), 1, blob_size(pBlob), stdout);
+nWrote = fwrite(blob_buffer(pBlob), 1, blob_size(pBlob), our_stdout);
 #if defined(_WIN32)
-fflush(stdout);
-_setmode(_fileno(stdout), _O_TEXT);
+fflush(our_stdout);
+_setmode(_fileno(our_stdout), _O_TEXT);
 #endif
   }else{
 file_mkfolder(zFilename, 1, 0);
 out = fossil_fopen(zFilename, "wb");
 if( out==0 ){

Index: src/branch.c
==
--- src/branch.c
+++ src/branch.c
@@ -261,11 +261,11 @@
   );
 }
 
 
 /*
-** COMMAND: branch
+** COMMAND: branch|
 **
 ** Usage: %fossil branch SUBCOMMAND ... ?OPTIONS?
 **
 ** Run various subcommands to manage branches of the open repository or
 ** of the repository identified by the -R or --repository option.

Index: src/bundle.c
==
--- src/bundle.c
+++ src/bundle.c
@@ -716,11 +716,11 @@
   }
   db_end_transaction(0);
 }
 
 /*
-** COMMAND: bundle
+** COMMAND: bundle|
 **
 ** Usage: %fossil bundle SUBCOMMAND ARGS...
 **
 **   fossil bundle append BUNDLE FILE...
 **

Index: src/checkin.c
==
--- src/checkin.c
+++ src/checkin.c
@@ -350,12 +350,12 @@
   if( relPathOption ){ relativePaths = 1; }
   return relativePaths;
 }
 
 /*
-** COMMAND: changes
-** COMMAND: status
+** COMMAND: changes|
+** COMMAND: status|
 **
 ** Usage: %fossil changes|status ?OPTIONS? ?PATHS ...?
 **
 ** Report the change status of files in the current checkout.  If one or
 ** more PATHS are specified, only changes among the named files and
@@ -644,11 +644,11 @@
   }
   db_finalize(&q);
 }
 
 /*
-** COMMAND: ls
+** COMMAND: ls|
 **
 ** Usage: %fossil ls ?OPTIONS? ?PATHS ...?
 **
 ** List all files in the current checkout.  If PATHS is included, only the
 ** named files (or their children if directories) are shown.
@@ -802,11 +802,11 @@
   }
   db_finalize(&q);
 }
 
 /*
-** COMMAND: extras
+** COMMAND: extras|
 **
 ** Usage: %fossil extras ?OPTIONS? ?PATH1 ...?
 **
 ** Print a list of all files in the source tree that are not part of the
 ** current checkout. See also the "clean" command. If paths are specified,
@@ -872,11 +872,11 @@
   }
   blob_reset(&report);
 }
 
 /*
-** COMMAND: clean
+** COMMAND: clean|
 **
 ** Usage: %fossil clean ?OPTIONS? ?PATH ...?
 **
 ** Delete all "extra" files in the source tree.  "Extra" files are files
 ** that are not officially part of the checkout.  If one or more PATH

Index: src/clone.c
==
--- src/clone.c
+++ src/clone.c
@@ -209,14 +209,14 @@
 db_open_repository(g.argv[3]);
   }
   db_begin_transaction();
   fossil_print("Rebuilding repository meta-data...\n");
   rebuild_db(0, 1, 0);
-  fossil_print("Extra delta compression... "); fflush(stdout);
+  fossil_print("Extra delta compression... "); fflush(our_stdout);
   extra_deltification();
   db_end_transaction(0);
-  fossil_print("\nVacuuming the database... "); fflush(stdout);
+  fossil_print("\nVacuuming the database... "); fflu

Re: [fossil-users] fossil 1.2->2.1 - hash policy "auto" doesn't seem to work and gives SQL error.

2017-03-26 Thread Richard Hipp
On 3/26/17, arnoldemu  wrote:
>
> So it seems that hash-policy of auto is not working?
>

The "auto" hash-policy automatically flips to "sha3" as soon as Fossil
sees one or more SHA3 artifacts in the repo.  Since your repo contains
SHA3 artifacts, you won't be able to set the policy to "auto" because
it will immediately and automatically flip to "sha3".

That is the way "auto" is designed to work.

How were you expecting it to work?  How can the documentation be improved?


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


[fossil-users] GitLab v. Fossil. Was: Eric Raymond (a.k.a. ESR) has published an SCM

2017-03-26 Thread Richard Hipp
On 3/26/17, Stephan Beal  wrote:
> It seems that ESR has published his own SCM:
>
> http://esr.ibiblio.org/?p=7448
> http://www.catb.org/esr/src/

Thanks for pointing this out, Stephan.

What intrigues me most here is not ESR's python-script wrapper around
RCS/SCCS, but rather the GitLab interface.  I had heard of GitLab, but
had never before taken the time to look into it.  My first impression
is that it seems much nicer than GitHub.

I mirrored a snapshot of ESR's GitLab repo using Fossil here:

https://www.fossil-scm.org/tmp/esr-src

(As you might infer from the "/tmp/" term in the URL, this is not a
permanent link.)  I think it is useful to compare the two interfaces,
GitLab vs. Fossil.   In particular, compare:

https://www.fossil-scm.org/tmp/esr-src
https://gitlab.com/esr/src/tree/master

Two big questions:

(1) What can Fossil learn from GitLab's interface?  What ideas are
there that can be copied from GitLab in order to improve Fossil?

(2) What can GitLab learn from Fossil's interface?  What ideas are
there in Fossil that GitLab might copy for its benefit.

I CC'ed "commun...@gitlab.com" on this reply with the hopes that they
might join in the discussion.

Under question (2) I'd like to make the following suggestions, in case
somebody from gitlab actually reads this:

(i)  With Fossil, one can click on two nodes of the graph to see a
diff between those two nodes.  With GitLab, you apparently have to go
to the separate "Compare" screen, then many type in (or paste in) hash
name prefixes of the two check-ins you want to compare.  This seems
rather clumsy.  But maybe I'm missing something.

(ii)  The timeline in Fossil is a lot faster than the graph of GitLab.

(iii)  I could not find any way to download tarballs of specific
check-ins.  Maybe I'm just not seeing it, but I could not find a way
to get at the source code without cloning the repository.

Under question (1) I offer the following:

(iv) The "Branches" page seems to be busted.  I think this is probably
due to some kind of problem with the "fossil import" command that was
used to convert the original Git repo.

A general question to which I do not know the answer:  How difficult
would it be to stand up a GitLab community-edition instance for ESR's
project?  How does this compare with standing up a Fossil instance.
I, of course, find Fossil a lot easier since I am familiar with it.
But what do people say who do not have a bias one way or the other.
What can Fossil and/or GitLab do to make it easier for newbies to set
up new project instances on their own private servers?  (See
https://www.fossil-scm.org/fossil/doc/trunk/www/server.wiki for the
documentation on how to create a server instance for Fossil.)

-- 
D. Richard Hipp
d...@sqlite.org
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

2017-03-26 Thread Richie Adler
Sergei Gavrikov decía, en el mensaje "Re: [fossil-users] [PROPOSED FEATURE]
Fossil commands output sent through a pager" del 25/3/2017 14:09:57:
> My 2 cents.  Many of us use f-alias to deal with fossil in a terminal,
> right? Then why not f-function?

Maybe because not everybody uses Unix-like operating systems?


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


[fossil-users] fossil 1.2->2.1 - hash policy "auto" doesn't seem to work and gives SQL error.

2017-03-26 Thread arnoldemu
Hi All,

i downloaded windows version of fossil 2.1 - after initial problems crashing 
when I ran it (see other thread) and rebuilding it was fine.

I used fossil hash-policy to set it to sha3 and forced a commit to the server 
because I didn't have files in my changes at that time.

From then on commits were using sha3 fine on windows.

So I went to my linux machine. It was using fossil 1.2.

I got this:

kevin@kevin:~/arnold$ fossil update
Autosync: http://kev@xxx/arnold
Round-trips: 1 Artifacts sent: 0 received: 0
unknown command: [igot]

Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 353 received: 2161 ip: x
Autosync failed.
continue in spite of sync failure (y/N)? n
update abandoned due to sync failure

I then downloaded linux x64 pre-compiled 2.1

kevin@kevin:~/arnold$ fossil version
This is fossil version 2.1 [83e3445f67] 2017-03-10 17:07:08 UTC
kevin@kevin:~/arnold$ fossil hash-policy
auto
kevin@kevin:~/arnold$ fossil update
Autosync: http://kev@xxx/arnold
Round-trips: 1 Artifacts sent: 0 received: 0
SQLITE_CONSTRAINT: abort at 14 in [INSERT INTO 
blob(rcvid,size,uuid,content)VALUES(0,-1,:uuid,NULL)]: CHECK constraint failed: 
blob
fossil: SQL error: CHECK constraint failed: blob
kevin@kevin:~/arnold$ fossil hash-policy sha3
sha3
kevin@kevin:~/arnold$ fossil update
Autosync: http://kev@xx/arnold
Round-trips: 3 Artifacts sent: 0 received: 202
Pull done, sent: 8806 received: 157107 ip: xxx
UPDATE changes.txt
...

So it seems that hash-policy of auto is not working?

This is a rough sequence of events:
* fossil 1.2 exe on windows and on linux
* fossil server updated to 2.1
* I updated windows binary to 2.1
* on windows I used hash-policy to set sha3 and used force because there were 
no more changes
* committed some files on windows
* I tried to update with linux 1.2 binary
* I then updated to linux 2.1 binary
* I then had to set sha3 policy (auto didn't work - see error)
* update succeeded.

Thanks

Kevin





___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


[fossil-users] Fossil Captchas

2017-03-26 Thread Damien Sykes-Lindley
Hi there,
Is there any chance an option can be added in Fossil whereby, when/where a 
captcha is required, the task is to answer a question instead? I say this 
because, as a totally blind screen reader user, captchas are generally 
inaccessible to us.
Ordinarily, most sites have an audio captcha feature (I fully appreciate that 
would possibly be difficult to add). Where this isn’t an option, there are 
helpers out there that OCR and clear the image to give us the answer (Again, I 
appreciate that helps us but totally undermines the reason for the existence of 
the captcha in the first place). Fossil seems not to employ either of these 
methods but instead represents it with bars and underscores (I actually thought 
it was some sort of bug when I found it, until I read that it used a 
captcha-style password representation). This is why I thought of the idea of a 
question (such as a calculation, or even a user supplied one), as an 
alternative option.
Just my thoughts.
Cheers.
Damien.
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

2017-03-26 Thread j. van den hoff
On Sun, 26 Mar 2017 16:00:11 +0200, Scott Robison  
 wrote:



On Mar 26, 2017 7:13 AM, "Christophe Gouiran" 
wrote:

Hi all,

First of all many thanks for all your feedback.

I come back to you with an implemented solution.

After many thinking, for me not all commands need to send their outputs  
to

a pager.
Only ones which may output a big amount of lines in a bunch.
Therefore, I selected only some of them to be candidate for a pager:


{snipped list of commands}

I appreciate what you're trying to do here, but what you've done (based  
on

your description) is create a maintenance nightmare (or headache at
minimum). Your implementation will forever need to be tweaked when new
commands are added or existing commands changed in some way that changes
their amount of output, perhaps based on some extra parameter. DRH
suggested that it should be based on any output, which would avoid the
worry about how fossil changes over time.

I'm coming around to the position that, given the ease of typing "|  
pager"

when desired, or defining an alias or using a wrapper of sorts, this
feature may be a mistake. I've never once wished that fossil had done  
this

for me, though I could be in the minority.


+1

--
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

2017-03-26 Thread Stephan Beal
On Sun, Mar 26, 2017 at 4:00 PM, Scott Robison 
wrote:

> their amount of output, perhaps based on some extra parameter. DRH
> suggested that it should be based on any output, which would avoid the
> worry about how fossil changes over time.
>

corner case: json output should arguably never be paged.

FWIW, i consider built-in paging (and symlinks support and fossil-side
terminal line-wrapping, for that matter) to be a bad idea (read as: "can of
worms"). i can count on one hand the number of times i've pager'd fossil
output since 2007.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

2017-03-26 Thread Scott Robison
On Mar 26, 2017 7:13 AM, "Christophe Gouiran" 
wrote:

Hi all,

First of all many thanks for all your feedback.

I come back to you with an implemented solution.

After many thinking, for me not all commands need to send their outputs to
a pager.
Only ones which may output a big amount of lines in a bunch.
Therefore, I selected only some of them to be candidate for a pager:


{snipped list of commands}

I appreciate what you're trying to do here, but what you've done (based on
your description) is create a maintenance nightmare (or headache at
minimum). Your implementation will forever need to be tweaked when new
commands are added or existing commands changed in some way that changes
their amount of output, perhaps based on some extra parameter. DRH
suggested that it should be based on any output, which would avoid the
worry about how fossil changes over time.

I'm coming around to the position that, given the ease of typing "| pager"
when desired, or defining an alias or using a wrapper of sorts, this
feature may be a mistake. I've never once wished that fossil had done this
for me, though I could be in the minority.
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

2017-03-26 Thread Martin S. Weber
On 2017-03-26 15:13:53, Christophe Gouiran wrote:
> I come back to you with an implemented solution.
> 

Your solution doesn't check whether stdout is actually pointing to a terminal.
You should never invoke a pager if it's not.

I also think this is a horrible idea in general.

Regards,
-Martin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


[fossil-users] Eric Raymond (a.k.a. ESR) has published an SCM

2017-03-26 Thread Stephan Beal
It seems that ESR has published his own SCM:

http://esr.ibiblio.org/?p=7448
http://www.catb.org/esr/src/

"Simple Revision Control is RCS/SCCS reloaded with a modern UI, designed to
manage single-file solo projects kept more than one to a directory. Use it
for FAQs, ~/bin directories, config files, and the like. Features integer
sequential revision numbers, a command set that will seem familiar to
Subversion/Git/hg users, and no binary blobs anywhere."

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

2017-03-26 Thread Christophe Gouiran
Hi all,

First of all many thanks for all your feedback.

I come back to you with an implemented solution.

After many thinking, for me not all commands need to send their outputs to
a pager.
Only ones which may output a big amount of lines in a bunch.
Therefore, I selected only some of them to be candidate for a pager:

   1. branch
   2. bundle
   3. changes
   4. status
   5. ls
   6. extras
   7. clean
   8. artifact
   9. descendants
   10. leaves
   11. annotate
   12. blame
   13. praise
   14. diff
   15. finfo
   16. cat
   17. json
   18. search
   19. tag
   20. timeline
   21. ticket
   22. undo
   23. redo
   24. unversioned
   25. wiki

To achieve that, I modified mkindex.c and, in all relevant source files, I
appended a pipe '|' to the commands which are candidates for a pager.


Now, when fossil is launched, it decides whether to use a pager according
to following conditions in this order of priority:

   1. Fossil command is candidate for a pager.
   2. PAGER environment variable is set to a non empty value.
   3. pager-command setting is set to a non empty value.


Then, technically, when there is pager to use it is launched as a child
process and Fossil standard output stream is piped to pager standard input.

And Fossil waits for pager to quit before quitting itself.


Just give it a try : it works pretty well under Linux with pager-command
"less -FRX".

It does not work yet under Windows as I'm a complete newbie with its
programming API.

If someone wants to contribute for the Windows, it would be welcome.


As usual, waiting for your feedback ...

Note : provided patch can be applied against latest version of the trunk
([a0ce33c90b] at the time of this writing).
Index: src/allrepo.c
==
--- src/allrepo.c
+++ src/allrepo.c
@@ -418,15 +418,15 @@
 if( showLabel ){
   int len = (int)strlen(zFilename);
   int nStar = 80 - (len + 15);
   if( nStar<2 ) nStar = 1;
   fossil_print("%.13c %s %.*c\n", '*', zFilename, nStar, '*');
-  fflush(stdout);
+  fflush(our_stdout);
 }
 if( !quiet || dryRunFlag ){
   fossil_print("%s\n", zSyscmd);
-  fflush(stdout);
+  fflush(our_stdout);
 }
 rc = dryRunFlag ? 0 : fossil_system(zSyscmd);
 free(zSyscmd);
 free(zQFilename);
 if( stopOnError && rc ){

Index: src/blob.c
==
--- src/blob.c
+++ src/blob.c
@@ -859,17 +859,17 @@
   if( zFilename[0]==0 || (zFilename[0]=='-' && zFilename[1]==0) ){
 blob_is_init(pBlob);
 #if defined(_WIN32)
 nWrote = fossil_utf8_to_console(blob_buffer(pBlob), blob_size(pBlob), 0);
 if( nWrote>=0 ) return nWrote;
-fflush(stdout);
-_setmode(_fileno(stdout), _O_BINARY);
+fflush(our_stdout);
+_setmode(_fileno(our_stdout), _O_BINARY);
 #endif
-nWrote = fwrite(blob_buffer(pBlob), 1, blob_size(pBlob), stdout);
+nWrote = fwrite(blob_buffer(pBlob), 1, blob_size(pBlob), our_stdout);
 #if defined(_WIN32)
-fflush(stdout);
-_setmode(_fileno(stdout), _O_TEXT);
+fflush(our_stdout);
+_setmode(_fileno(our_stdout), _O_TEXT);
 #endif
   }else{
 file_mkfolder(zFilename, 1, 0);
 out = fossil_fopen(zFilename, "wb");
 if( out==0 ){

Index: src/branch.c
==
--- src/branch.c
+++ src/branch.c
@@ -261,11 +261,11 @@
   );
 }
 
 
 /*
-** COMMAND: branch
+** COMMAND: branch|
 **
 ** Usage: %fossil branch SUBCOMMAND ... ?OPTIONS?
 **
 ** Run various subcommands to manage branches of the open repository or
 ** of the repository identified by the -R or --repository option.

Index: src/bundle.c
==
--- src/bundle.c
+++ src/bundle.c
@@ -716,11 +716,11 @@
   }
   db_end_transaction(0);
 }
 
 /*
-** COMMAND: bundle
+** COMMAND: bundle|
 **
 ** Usage: %fossil bundle SUBCOMMAND ARGS...
 **
 **   fossil bundle append BUNDLE FILE...
 **

Index: src/checkin.c
==
--- src/checkin.c
+++ src/checkin.c
@@ -350,12 +350,12 @@
   if( relPathOption ){ relativePaths = 1; }
   return relativePaths;
 }
 
 /*
-** COMMAND: changes
-** COMMAND: status
+** COMMAND: changes|
+** COMMAND: status|
 **
 ** Usage: %fossil changes|status ?OPTIONS? ?PATHS ...?
 **
 ** Report the change status of files in the current checkout.  If one or
 ** more PATHS are specified, only changes among the named files and
@@ -644,11 +644,11 @@
   }
   db_finalize(&q);
 }
 
 /*
-** COMMAND: ls
+** COMMAND: ls|
 **
 ** Usage: %fossil ls ?OPTIONS? ?PATHS ...?
 **
 ** List all files in the current checkout.  If PATHS is included, only the
 ** named files (or their children if directories) are shown.
@@ -802,11 +802,11 @@
   }
   db_finalize(&q);
 }
 
 /*
-** COMMAND: extras
+** COMMAND: extras|
 **
 ** Usage: %fossil extras ?OPTIONS? ?PATH1 ...?
 **
 ** Print a list of all files i

Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager

2017-03-26 Thread Stefan Bellon
On Sat, 25 Mar, Andy Bradford wrote:

> Thus said Roy Keene on Thu, 23 Mar 2017 17:36:37 -0500:
> 
> > I vote that the pagination be  off by default to preserve the
> > existing behaviour -- terminals  have been able to scroll for
> > decades now so I don't know why systemd/git like to do this by
> > default but it is REALLY annoying having to pipe EVERYTHING through
> > "cat" to defeat it.  
> 
> I'll add my voice to this as well and it's not just to preserve
> existing behavior. I think  git's default (is it even configurable
> with git?) to automatically page everything is one of its most
> annoying features. If I want a  pager, I'll pipe it  to a pager.
> Otherwise, just dump it  to my terminal, thank you.

+1 for everything said by Roy and Andy.

-- 
Stefan Bellon
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users