Hi,
Is there any thought on supporting markdown as a wiki format for fossil?
For information there is a fast, simple and easy to use library
(license BSD 2 clauses) that maybe used for that:
http://fossil.instinctive.eu/libupskirt/home it is easy to bundle if desired.
Markdown is a really simple
On Mon, May 23, 2011 at 4:46 PM, Florian Weimer wrote:
> This doesn't look right:
>
> fw@deneb:~/src/fossil$ ./fossil update
> Autosync: http://www.fossil-scm.org/
>Bytes Cards Artifacts Deltas
> Sent: 177 2 0 0
> Received:
On Mon, May 23, 2011 at 3:25 PM, Stephan Beal wrote:
> The most significant caveat, i think, is that because it's 100%
> client-rendered, and fetching the pages requires processing JSON fetched via
> AJAX, it does not degrade gracefully (at all) for "lesserly capable"
> clients.
Very interesting
This doesn't look right:
fw@deneb:~/src/fossil$ ./fossil update
Autosync: http://www.fossil-scm.org/
Bytes Cards Artifacts Deltas
Sent: 177 2 0 0
Received:3620 79 0 0
Total network traffic: 322 byte
Hello, fossilers,
The past six weeks or so i've been hacking and re-hacking a custom wiki
back-end which runs as a CGI and serves wiki pages in arbitrary wiki
syntaxes (as JSON objects which hold the page content and other metadata),
for rendering on the client side. The original goal of the proje
Richard's question regarding a multi level undo, and when to purge, got
me thinking; and I apologize for posting mid - thought stream ...
What if fossil kept track of all the commands issued that change either
the repository or the working files.
Obviously, it already does this at some level
A multi-level stash could end up performing the one feature of git I
like over fossil: that I can do nonsense commits onto a branch I don't
push, then "git rebase -i" them into beautiful sense before I commit...
I've wondered if that should be available as a feature on fossil's
private branches (
On Mon, May 23, 2011 2:44 pm, Konstantin Khomoutov wrote:
> On Sun, 22 May 2011 06:50:56 -0400
> Richard Hipp wrote:
>
> [...]
>> > >>> Does anybody have any other suggestions on how to prevent the
>> > >>> lose of uncommitted work?
>> > >>
>> > >> Maybe not suggestion to prevent losing of uncomm
On Sun, 22 May 2011 06:50:56 -0400
Richard Hipp wrote:
[...]
> > >>> Does anybody have any other suggestions on how to prevent the
> > >>> lose of uncommitted work?
> > >>
> > >> Maybe not suggestion to prevent losing of uncommitted work, but
> > >> I'm thinking about using 'stash' in such situat
Hi,
is the 'Contact Info' field (set in user registration/editing screen)
available for hte current user via the ticket (and other) templates?
> This bit of code will get rid of the "email" field entry for logged-in
> users. Since we know the user's information, we don't have to ask for
> it.
10 matches
Mail list logo
