Discussion:
Multi line formatting
(too old to reply)
Baptiste Daroussin
2015-08-29 14:58:25 UTC
Permalink
Hi,

Something which is really strange about fossil and is probably the
number 2 major complaints I heard from user to whom I presented
fossil, is the fact that by default fossil completly ignores the
formatting of the commit logs.

I do think that presenting the log mesages with proper formatting is
important and improves a lot clarity.

I sent long ago a couple of patches which have been integrated and
greatly improved by fossil developers (thanks!) but the default remain
on the non proper formatting without any simple mechanism to change
that default.

for the Web UI one can easily modify the CSS so it is not a big issue,
however on the cli we have to use the non documend fmtflags (or
something like that) with cryptic values :(

Any plan to improved this? at least add a setting where we can define
globally the format of the output? maybe switch by default to respect
the formatting of the log? (fossil is the only vcs I know that is not
respecting the formatting of the logs).

Bapt
Warren Young
2015-08-30 02:27:25 UTC
Permalink
the number 2 major complaints I heard from user
Really? What’s #1 and #3? :)

I find that setting the “block formatting” option in Admin/Settings/Timeline solves most of my problems in this area.

I don’t mind that Fossil’s block formatting rules assume single hard LFs are soft line breaks, or that it only inserts hard paragraph breaks on double LF. This is the same rule used by Markdown, so it’s not even something I have to actively think about any more; it’s just how plain text -> web text works in my brain now.

In fact, I’d welcome a feature that allowed Markdown-formatted checkin comments. Not because I spend a lot of time making my checkin comments pretty, but because it would occasionally [be helpful](http://www.wikihow.com/Be-Helpful). :)

Actually, I think my main use of Markdown-formatted checkin comments would be bullet lists, for those really complicated checkins that do several related things.

And while I’m wishing, an option for Markdown-formatted tickets would be nice, too. Wiki markup is a bit overkill when all you want is the occasional `literal`, and it’s confusing to switch between Markdown and Wiki links, since their order of URL/text is opposite.
Stephan Beal
2015-08-30 02:35:54 UTC
Permalink
On Aug 29, 2015, at 8:58 AM, Baptiste Daroussin <
the number 2 major complaints I heard from user
Really? What’s #1 and #3? :)
+1

In some 20 years (as of this coming winter) of using source control (RCS =>
CVS => SVN => Fossil), i can count on one hand the number of times i've
seen commit messages (in project i work on/contribute to) which span more
than two sentences. (Anything needing a longer explanation simply gets a
ticket number as the commit message.) i can count on 0 fingers the number
of times i have written a formatted-for-management commit message.


Wiki markup is a bit overkill when all you want is the occasional
`literal`, and it’s confusing to switch between Markdown and Wiki links,
since their order of URL/text is opposite.
+1
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"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
Warren Young
2015-08-30 02:43:51 UTC
Permalink
i can count on one hand the number of times i've seen commit messages (in project i work on/contribute to) which span more than two sentences.
Well, you may have noticed that I can be verbose. :)

Also, I think the tendency for a single commit to do multiple things is more common in single-person projects, where the pressure to use branches for complicated changes is lower.

When you’re working on an experimental branch, it’s easy to commit early and often, since you aren’t affecting anything else, whereas when you’re working on the trunk, you tend to wait to commit until the feature is perfect. Functionality accumulates, so that by the time it comes time to check it all in, it takes a bit of work to explain what it all does.
Stephan Beal
2015-08-30 02:49:02 UTC
Permalink
Post by Warren Young
Well, you may have noticed that I can be verbose. :)
This is the first project i've been on where the topic has even come up.
Post by Warren Young
Also, I think the tendency for a single commit to do multiple things is
more common in single-person projects, where the pressure to use branches
for complicated changes is lower.
When you’re working on an experimental branch, it’s easy to commit early
and often, since you aren’t affecting anything else, whereas when you’re
working on the trunk, you tend to wait to commit until the feature is
perfect. Functionality accumulates, so that by the time it comes time to
check it all in, it takes a bit of work to explain what it all does.
In which case something like my two-week-long commit at work last Friday
typically suffices:

"Implemented Jira ticket PROJ-1234."

;)

All other details were attached to the ticket (and, even there, nobody's
ever really gonna read them).
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"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
Baptiste Daroussin
2015-08-30 08:15:52 UTC
Permalink
Post by Stephan Beal
On Aug 29, 2015, at 8:58 AM, Baptiste Daroussin
the number 2 major complaints I heard from user
Really? What’s #1 and #3? :)
+1
Number #1 is the inhability to run "external" hooks easily, like
execute this script each time a sync is done, for before checking in,
run this scripts. (personnally I can live with that)

Number #3 can be related soehow to number #1 is the inability of the
bug tracker to send mails. Which makes the casual reporter never reply
to comments on their bug reports. Making interraction quite
complicated with them. (This one is a huge pain for me and made me
switch some of projects to github when they became popular :()

While I'm here Number #4 is the inhability to have a equivalent of git
am (getting a preformatted checkin which one can directly add on a
repository to preserve the author of the checki) Personnally I do not
feel that is it that important, it is simply sugar IMHO.
Post by Stephan Beal
In some 20 years (as of this coming winter) of using source control (RCS =>
CVS => SVN => Fossil), i can count on one hand the number of times i've seen
commit messages (in project i work on/contribute to) which span more than
two sentences. (Anything needing a longer explanation simply gets a ticket
number as the commit message.) i can count on 0 fingers the number of times
i have written a formatted-for-management commit message.
Well my experience is quite the opposite. Most if not all projects I
have been working relies on multi line logs. On some of them like all
FreeBSD's repositories (svn and git) I cannot even imagine getting
though history without multi time view.

If something is able to do multi-line formatting by default it works
fine with one liners project, but something only able to format one
line is broken for multi-line cases :(

Maybe that could be done via a new "log" which will be a kind of alias
for fossil timeline -t ci ? (seriously when you come from other VCS
the fossil timeline is disturbing :D)

Best regards,
Bapt
Stephan Beal
2015-08-30 08:27:18 UTC
Permalink
On Sun, Aug 30, 2015 at 10:15 AM, Baptiste Daroussin <
Post by Baptiste Daroussin
Number #1 is the inhability to run "external" hooks easily, like
execute this script each time a sync is done, for before checking in,
run this scripts. (personnally I can live with that)
Management summary: that's primarily because (A) it's difficult to do
portably in a small package like Fossil and (B) because it opens up many
more potential failure cases than currently exist. (e.g. what happens to a
commit if an http connection to an external server, used by a trigger,
cannot be established?) Many hosting environments do not allow hosted
scripts/apps to establish outbound connections with external servers, which
inherently castrates such features, as well as your next one...

That said, Fossil does have basic hooks support in the form of TH1/TCL
scripts, but i've never used them. Jan or Joe can certainly say more about
them.
Post by Baptiste Daroussin
Number #3 can be related soehow to number #1 is the inability of the
bug tracker to send mails.
Right - very closely related. Speaking to diverse mail servers reliably is
difficult to implement, and really needs an external mail API provider.
There is no _portable_ external provider API for sending mails. Doing so on
Unix, via sendmail, is simple enough, but fossil aims to provide all of its
features on all of its platforms, insofar as possible. (AFAIK, symlinks is
the only feature which doesn't achieve this ideal.) IMO this is the right
approach - limit fossil to features which are only available on all of its
platforms (AFAIK i'm one of the few here who believes, for that reason,
that fossil should not support symlinks).
Post by Baptiste Daroussin
Well my experience is quite the opposite. Most if not all projects I
have been working relies on multi line logs. On some of them like all
FreeBSD's repositories (svn and git) I cannot even imagine getting
though history without multi time view.
My point was not so much about the multiline support, but the lack (in my
experience) of need for book-length commit messages. Without those, the
lack of multi-line support is moot.

Maybe that could be done via a new "log" which will be a kind of alias
Post by Baptiste Daroussin
for fossil timeline -t ci ? (seriously when you come from other VCS
the fossil timeline is disturbing :D)
Personally, i've always been against Fossil doing _any_ sort of
manipulation of commit message storage or display (e.g. word-wrapping in
the console), as it adds a disproportionate amount of complexity. If
someone can read programming code, they can certainly read commit messages,
regardless of their formatting. But i am likely in the minority on that
point.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"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
Baptiste Daroussin
2015-08-30 08:54:43 UTC
Permalink
Post by Stephan Beal
On Sun, Aug 30, 2015 at 10:15 AM, Baptiste Daroussin
Post by Baptiste Daroussin
Number #1 is the inhability to run "external" hooks easily, like
execute this script each time a sync is done, for before checking in,
run this scripts. (personnally I can live with that)
Management summary: that's primarily because (A) it's difficult to do
portably in a small package like Fossil and (B) because it opens up many
more potential failure cases than currently exist. (e.g. what happens to a
commit if an http connection to an external server, used by a trigger,
cannot be established?) Many hosting environments do not allow hosted
scripts/apps to establish outbound connections with external servers, which
inherently castrates such features, as well as your next one...
That said, Fossil does have basic hooks support in the form of TH1/TCL
scripts, but i've never used them. Jan or Joe can certainly say more about
them.
Well last I tried there were not really useful and as for example in
case of post bug report because of them being run with reporters
(whcih makes sense given how they are designed) they were limited
deeply limited in what they could do... I end it up back in the time
at making them just to a http call to a local cgi which will then run
a bunch complex fossil cli command to be able to grab the information
I need (and send mails) it was in the end so complicated I gave up and
switched the repo to github back in the time :(
Post by Stephan Beal
Post by Baptiste Daroussin
Number #3 can be related soehow to number #1 is the inability of the
bug tracker to send mails.
Right - very closely related. Speaking to diverse mail servers reliably is
difficult to implement, and really needs an external mail API provider.
There is no _portable_ external provider API for sending mails. Doing so on
Unix, via sendmail, is simple enough, but fossil aims to provide all of its
features on all of its platforms, insofar as possible. (AFAIK, symlinks is
the only feature which doesn't achieve this ideal.) IMO this is the right
approach - limit fossil to features which are only available on all of its
platforms (AFAIK i'm one of the few here who believes, for that reason, that
fossil should not support symlinks).
Post by Baptiste Daroussin
Well my experience is quite the opposite. Most if not all projects I
have been working relies on multi line logs. On some of them like all
FreeBSD's repositories (svn and git) I cannot even imagine getting
though history without multi time view.
My point was not so much about the multiline support, but the lack (in my
experience) of need for book-length commit messages. Without those, the lack
of multi-line support is moot.
Post by Baptiste Daroussin
Maybe that could be done via a new "log" which will be a kind of alias
for fossil timeline -t ci ? (seriously when you come from other VCS
the fossil timeline is disturbing :D)
Personally, i've always been against Fossil doing _any_ sort of manipulation
of commit message storage or display (e.g. word-wrapping in the console), as
it adds a disproportionate amount of complexity. If someone can read
programming code, they can certainly read commit messages, regardless of
their formatting. But i am likely in the minority on that point.
I 100% agree with you here, if fossil was not manipulating the message
on display the multiline formatting would work out of box (they are
correctly stored)

Bapt
Matt Welland
2015-08-30 14:50:45 UTC
Permalink
Good support for sending email would be wonderful. We are getting along by
running rss2email, far from ideal but adequate.

On Sun, Aug 30, 2015, 1:55 AM Baptiste Daroussin <
Post by Baptiste Daroussin
Post by Stephan Beal
On Sun, Aug 30, 2015 at 10:15 AM, Baptiste Daroussin
Post by Baptiste Daroussin
Number #1 is the inhability to run "external" hooks easily, like
execute this script each time a sync is done, for before checking in,
run this scripts. (personnally I can live with that)
Management summary: that's primarily because (A) it's difficult to do
portably in a small package like Fossil and (B) because it opens up many
more potential failure cases than currently exist. (e.g. what happens to
a
Post by Stephan Beal
commit if an http connection to an external server, used by a trigger,
cannot be established?) Many hosting environments do not allow hosted
scripts/apps to establish outbound connections with external servers,
which
Post by Stephan Beal
inherently castrates such features, as well as your next one...
That said, Fossil does have basic hooks support in the form of TH1/TCL
scripts, but i've never used them. Jan or Joe can certainly say more
about
Post by Stephan Beal
them.
Well last I tried there were not really useful and as for example in
case of post bug report because of them being run with reporters
(whcih makes sense given how they are designed) they were limited
deeply limited in what they could do... I end it up back in the time
at making them just to a http call to a local cgi which will then run
a bunch complex fossil cli command to be able to grab the information
I need (and send mails) it was in the end so complicated I gave up and
switched the repo to github back in the time :(
Post by Stephan Beal
Post by Baptiste Daroussin
Number #3 can be related soehow to number #1 is the inability of the
bug tracker to send mails.
Right - very closely related. Speaking to diverse mail servers reliably
is
Post by Stephan Beal
difficult to implement, and really needs an external mail API provider.
There is no _portable_ external provider API for sending mails. Doing so
on
Post by Stephan Beal
Unix, via sendmail, is simple enough, but fossil aims to provide all of
its
Post by Stephan Beal
features on all of its platforms, insofar as possible. (AFAIK, symlinks
is
Post by Stephan Beal
the only feature which doesn't achieve this ideal.) IMO this is the right
approach - limit fossil to features which are only available on all of
its
Post by Stephan Beal
platforms (AFAIK i'm one of the few here who believes, for that reason,
that
Post by Stephan Beal
fossil should not support symlinks).
Post by Baptiste Daroussin
Well my experience is quite the opposite. Most if not all projects I
have been working relies on multi line logs. On some of them like all
FreeBSD's repositories (svn and git) I cannot even imagine getting
though history without multi time view.
My point was not so much about the multiline support, but the lack (in my
experience) of need for book-length commit messages. Without those, the
lack
Post by Stephan Beal
of multi-line support is moot.
Post by Baptiste Daroussin
Maybe that could be done via a new "log" which will be a kind of alias
for fossil timeline -t ci ? (seriously when you come from other VCS
the fossil timeline is disturbing :D)
Personally, i've always been against Fossil doing _any_ sort of
manipulation
Post by Stephan Beal
of commit message storage or display (e.g. word-wrapping in the
console), as
Post by Stephan Beal
it adds a disproportionate amount of complexity. If someone can read
programming code, they can certainly read commit messages, regardless of
their formatting. But i am likely in the minority on that point.
I 100% agree with you here, if fossil was not manipulating the message
on display the multiline formatting would work out of box (they are
correctly stored)
Bapt
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Warren Young
2015-08-31 16:40:59 UTC
Permalink
Post by Baptiste Daroussin
Number #1 is the inhability to run "external" hooks easily
it's difficult to do portably
system() is ANSI C.

There are many external programs you can call that way. All that’s needed is some kind of hook-calling protocol, a la CGI.
it opens up many more potential failure cases
I don’t see what’s difficult about failing a transaction if a hook is defined and the external program call fails. All the difficult parts are fobbed off on the person writing the hook script.
what happens to a commit if an http connection to an external server, used by a trigger, cannot be established?
The commit fails, same as if the process of attempting the commit causes any other error, such as a fork without --allow-fork.
Many hosting environments do not allow hosted scripts/apps to establish outbound connections with external servers
If you’re on such a host, you don’t get to use hooks. Switch to a different hosting provider if you need hooks. There are dozens of bare-bones VPS and cloud hosting providers without this restriction.

Also, this restriction only affects those who go out of their way to use hooks. If you don’t define any hooks, Fossil will behave the same as it does today.
Fossil does have basic hooks support in the form of TH1/TCL scripts,
You have to configure Fossil with --with-th1-hooks to enable it.

Also, as far as I can tell, TH1 doesn’t have the power to implement an SMTP client or call out to an external one anyway. (i.e. no equivalent of connect(2) or system(3).)

I was curious how Git handles this, and to a first approximation, it doesn’t. It includes a 1,700 line Perl script which either calls out to sendmail(1) or uses the Perl Net::SMTP library to do all the heavy lifting.

https://github.com/git/git/blob/master/git-send-email.perl

My point above is that even these options aren’t available to TH1.

I see that Fossil has --with-tcl, which might be able to solve this, but I don’t see any documentation explaining it on the Fossil site.
There is no _portable_ external provider API for sending mails.
Not for C, true, but Tcl can do it: http://wiki.tcl.tk/1256

For platforms where linking to Tcl isn’t suitable, TH1 could add the exec and open commands:

https://www.tcl.tk/man/tcl8.5/tutorial/Tcl26.html

Then Fossil proper wouldn’t have to worry about such things as how to send email.
My point was not so much about the multiline support, but the lack (in my experience) of need for book-length commit messages. Without those, the lack of multi-line support is moot.
Straw man. Adding a small bit of markup to a commit message is not writing books. And it’s a good thing, since Markdown is not the right formatting system for book production anyway.

Most of the code needed to do this is in Fossil already.
Stephan Beal
2015-08-31 16:46:28 UTC
Permalink
it opens up many more potential failure cases
I don’t see what’s difficult about failing a transaction if a hook is
defined and the external program call fails. All the difficult parts are
fobbed off on the person writing the hook script.
i make a commit locally. i push. The push fails because a remote hook
disallows it. What then? How do we resolve my repo's discrepancy at that
point? That becomes fossil's problem because people will (rightfully) want
to retain the data they just committed.
what happens to a commit if an http connection to an external server,
used by a trigger, cannot be established?
The commit fails, same as if the process of attempting the commit causes
any other error, such as a fork without --allow-fork.
The _push_ fails. The commit has long-since happened locally.
Many hosting environments do not allow hosted scripts/apps to establish
outbound connections with external servers
If you’re on such a host, you don’t get to use hooks. Switch to a
different hosting provider if you need hooks. There are dozens of
bare-bones VPS and cloud hosting providers without this restriction.
Many commercial/enterprise environments don't allow this. We once, after 8
months of development using 'maven' as a build tool, had to port everything
to ant after discovering that the remote site does not allow external
internet access (in or out).
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"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
Warren Young
2015-08-31 17:27:10 UTC
Permalink
The push fails because a remote hook disallows it. What then?
The same thing that happens when you try to push to a read-only repo, or push while the Internet connection is down, or push to a repo you accidentally cloned anonymously by forgetting user@ in the URL, or push to a server that’s just run out of disk space, or…

Fossil already has to cope with such problems.
That becomes fossil's problem
No, it’s the hook-writer’s problem.

The hook-writer solves that in the normal way: log the problem so that a human can figure out how to solve it, then retry the commit.

This is part of what I was implying when I spoke of a CGI-like hook calling protocol. If you try an HTTP POST to a site you aren’t logged into, it will likely give you a 400-series error along with some error text, which tells you what happened and gives you a clue how to fix it. In the same way, an external Fossil hook program can return some error code and a string that makes its way from the remote host to the local Fossil client.
Many commercial/enterprise environments don't allow this. We once, after 8 months of development using 'maven' as a build tool, had to port everything to ant after discovering that the remote site does not allow external internet access (in or out).
How do you imagine such a problem could bite a Fossil user?

Case 1: They add a hook to the remote server, it fails, so they remove it, and Fossil goes back to running. No 8-month submarine time.

Case 2: They have a perfectly working Fossil setup with hooks, then 8 months later they move it to a new remote site, and it fails immediately because none of the hook scripts will run. Now they get to choose whether to disable hooks or solve the site restriction. If they choose the first option, Fossil goes back to working the same way it does everywhere else, which I think we can agree to summarize as, “Adequate,” at the least. :)

Hooks are optional. They may add site-specific restrictions, but bypassing these restrictions does not harm the Fossil DB.

I imagine some people will try to use hooks to create inviolable constraints, but that’s predicated on those hooks actually running, and not being bypassable. That’s purely a local administration problem, not something that the Fossil project has to solve.
Stephan Beal
2015-08-31 17:39:53 UTC
Permalink
Post by Stephan Beal
That becomes fossil's problem
No, it’s the hook-writer’s problem.
The hook-writer solves that in the normal way: log the problem so that a
human can figure out how to solve it, then retry the commit.
Hooks are not just about emails, but about policy decisions. "Does this
file conform to XYZ." A failure at that level is unrecoverable without
changing the policy.
Post by Stephan Beal
Many commercial/enterprise environments don't allow this. We once, after
8 months of development using 'maven' as a build tool, had to port
everything to ant after discovering that the remote site does not allow
external internet access (in or out).
How do you imagine such a problem could bite a Fossil user?
Now that you mention it... i can't, unless it allows inbound but no
outbound traffic (one bank i worked at has some network segments set up
that way).
Case 2: They have a perfectly working Fossil setup with hooks, then 8
months later they move it to a new remote site, and it fails immediately
because none of the hook scripts will run. Now they get to choose whether
to disable hooks or solve the site restriction.
Solve == remove, as the code is already committed and fossil disallows
history changes.
If they choose the first option, Fossil goes back to working the same
way it does everywhere else, which I think we can agree to summarize as,
“Adequate,” at the least. :)
Adequate, but troubling nonetheless.
Hooks are optional. They may add site-specific restrictions, but
bypassing these restrictions does not harm the Fossil DB.
Not the db, but the constellation. They leave the "violating" user in a
state which is no longer mergeable with the main repo.
I imagine some people will try to use hooks to create inviolable
constraints, but that’s predicated on those hooks actually running, and not
being bypassable. That’s purely a local administration problem, not
something that the Fossil project has to solve.
Agreed, but this list is the first place they'll run when such a policy
forks them from their main repo, asking for advice on how to solve it.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"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
Warren Young
2015-08-31 17:46:48 UTC
Permalink
Hooks are not just about emails, but about policy decisions. "Does this file conform to XYZ." A failure at that level is unrecoverable without changing the policy.
I think we can agree that using hooks to enforce, say, code formatting rules is a bad idea.

Now, maybe a hook could give a *warning* that you’ve just checked a C++ file in with tabs instead of spaces, but it shouldn’t refuse outright, because of the very risk you refer to.

I’m going to guess that if you set hooks on a repo sitting behind “fossil server”, that those hook scripts don’t get sent down to a clone, or may not run of they do, so you can’t count on them being run locally before we get to the push stage?
Warren Young
2015-08-31 17:56:52 UTC
Permalink
Post by Warren Young
Hooks are not just about emails, but about policy decisions. "Does this file conform to XYZ." A failure at that level is unrecoverable without changing the policy.
I think we can agree that using hooks to enforce, say, code formatting rules is a bad idea.
I did a bit of Googling, and this blog article describes what seems to be a well thought out system for Git:

http://causes.github.io/blog/2013/05/30/overcommit-the-opinionated-git-hook-manager/

The key is doing the checks locally, rather than on the central repo server, and offering a way to bypass the checks at need.
Ron W
2015-08-31 19:09:35 UTC
Permalink
Post by Warren Young
Post by Warren Young
I think we can agree that using hooks to enforce, say, code formatting
rules is a bad idea.
I did a bit of Googling, and this blog article describes what seems to be
http://causes.github.io/blog/2013/05/30/overcommit-the-opinionated-git-hook-manager/
The key is doing the checks locally, rather than on the central repo
server, and offering a way to bypass the checks at need.
We put our source code checks into the build process. Yes, that means they
could be easily by-passed, but if some one did that, other team members
would see the failures.
Scott Doctor
2015-08-31 17:46:57 UTC
Permalink
I am new to using Fossil, so I created a dummy project to play
with the various features. For the most part I think Fossil is a
huge improvement over the alternatives. I can see using this as
my support website framework along with handling development
issues., which leads me to the following question.

How do I change the button bar? While the
home-timeline-files-.... entries are fine for the base
operations, what I want is an easy way to customize that bar.
Mainly for the first page or custom wiki pages. I can hack the
pages code, but that is not a preferred way to do that. So
simply, how can I customize the buttons on the button bar at the
top of the page to use my combination of button, or to
add/remove a button?

------------
Scott Doctor
***@scottdoctor.com
------------------
Warren Young
2015-08-31 17:51:21 UTC
Permalink
how can I customize the buttons on the button bar at the top of the page
Admin -> Skins -> Header.

That gets you a text editor containing the current HTML + TH1 code combination that generates the header portion of each page Fossil serves. The footer and CSS files also play into it.

If you want to dig deeper into it, the stock skins are in the skins subidrectory of the Fossil code repo.
Scott Doctor
2015-08-31 18:03:15 UTC
Permalink
_______________________________________________
fossil-users mailing list
fossil-***@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Richard Hipp
2015-08-31 18:16:26 UTC
Permalink
Hmm. I guess that will work. but would be nice to have a simple GUI-ish type
editor where I just have a list in order of appearance that is the name of
the button and its link, instead of basically hacking code, thereby
isolating language syntax from the user.
The default headers use condition code to test whether or not various
menu items are displayed and to change their names based on the users
permissions and login status. That would be difficult to do with a
GUI. So our options are to reduce the capabilities in order to
accommodate a GUI, or keep the current setup.
--
D. Richard Hipp
***@sqlite.org
Ron W
2015-08-31 19:17:49 UTC
Permalink
Post by Warren Young
how can I customize the buttons on the button bar at the top of the page
Admin -> Skins -> Header.
Or just: Admin -> Header

(At least with the out-of-the-box Fossil, the 2 are equivalent.)

Joe Mistachkin
2015-08-31 16:59:29 UTC
Permalink
There are docs on --with-tcl and the commands it provides (see th1.md in the source tree). Also, with Tcl enabled the hooks work perfectly for sending mail and I've personally been doing so for several years on a repository of mine.

Sent from my iPhone
Post by Warren Young
Post by Baptiste Daroussin
Number #1 is the inhability to run "external" hooks easily
it's difficult to do portably
system() is ANSI C.
There are many external programs you can call that way. All that’s needed is some kind of hook-calling protocol, a la CGI.
it opens up many more potential failure cases
I don’t see what’s difficult about failing a transaction if a hook is defined and the external program call fails. All the difficult parts are fobbed off on the person writing the hook script.
what happens to a commit if an http connection to an external server, used by a trigger, cannot be established?
The commit fails, same as if the process of attempting the commit causes any other error, such as a fork without --allow-fork.
Many hosting environments do not allow hosted scripts/apps to establish outbound connections with external servers
If you’re on such a host, you don’t get to use hooks. Switch to a different hosting provider if you need hooks. There are dozens of bare-bones VPS and cloud hosting providers without this restriction.
Also, this restriction only affects those who go out of their way to use hooks. If you don’t define any hooks, Fossil will behave the same as it does today.
Fossil does have basic hooks support in the form of TH1/TCL scripts,
You have to configure Fossil with --with-th1-hooks to enable it.
Also, as far as I can tell, TH1 doesn’t have the power to implement an SMTP client or call out to an external one anyway. (i.e. no equivalent of connect(2) or system(3).)
I was curious how Git handles this, and to a first approximation, it doesn’t. It includes a 1,700 line Perl script which either calls out to sendmail(1) or uses the Perl Net::SMTP library to do all the heavy lifting.
https://github.com/git/git/blob/master/git-send-email.perl
My point above is that even these options aren’t available to TH1.
I see that Fossil has --with-tcl, which might be able to solve this, but I don’t see any documentation explaining it on the Fossil site.
There is no _portable_ external provider API for sending mails.
Not for C, true, but Tcl can do it: http://wiki.tcl.tk/1256
https://www.tcl.tk/man/tcl8.5/tutorial/Tcl26.html
Then Fossil proper wouldn’t have to worry about such things as how to send email.
My point was not so much about the multiline support, but the lack (in my experience) of need for book-length commit messages. Without those, the lack of multi-line support is moot.
Straw man. Adding a small bit of markup to a commit message is not writing books. And it’s a good thing, since Markdown is not the right formatting system for book production anyway.
Most of the code needed to do this is in Fossil already.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Warren Young
2015-08-31 17:39:21 UTC
Permalink
Post by Joe Mistachkin
There are docs on --with-tcl and the commands it provides (see th1.md in the source tree).
Yes, I already saw that, via the web:

http://fossil-scm.org/index.html/doc/tip/www/th1.md

You have to admit, it’s awfully thin on details.

How exactly do you use this to set a hook, for one thing?

If I want to run an external command, does --with-tcl let me call Tcl’s “exec” directly, or do I need to call “tclEval exec”, or something else?

I’m sure I could figure all this out by reading Fossil’s source and experimenting, but I think it’s fair to expect the docs to cover such basics.
Post by Joe Mistachkin
Also, with Tcl enabled the hooks work perfectly for sending mail
I think the mere existence of a tutorial article that builds a basic “send email on each commit” hook would be enough to solve a lot of people’s problems. Just something to riff off of, you know?
Continue reading on narkive:
Loading...