Hello,
Recent discussion of private branches led me to discover one interesting
detail about private branches.
When merging in the private branch, Fossil does not add a P-card for the
private branch, which seems sensible to me, however, it does add a
T-card to close the private branch. Here
On Wed, May 11, 2016 at 8:26 PM, Andy Bradford
wrote:
>
> What happens when you merge a private branch into trunk?
You get a single commit that represents all the changes from the branch.
This is unlike "git merge --fast-forward".
(I don't know what just "git merge" would do. I only know abou
On Wed, May 11, 2016 at 6:24 PM, Marko Käning
wrote:
> How to achieve a git'ish squash when merging a (private) branch into trunk?
>
> Is this deliberately missing functionality following fossil's mission to
> keep all history?
>
I think you are misunderstanding how a merge works in Fossil. The
Thus said =?windows-1252?Q?Marko_K=E4ning?= on Thu, 12 May 2016 00:24:20 +0200:
> How to achieve a git'ish squash when merging a (private) branch into
> trunk?
What happens when you merge a private branch into trunk?
Thanks,
Andy
--
TAI64 timestamp: 40005733cde2
__
On May 11, 2016, at 4:39 PM, Marko Käning wrote:
>
> On 12 May 2016, at 00:26 , Warren Young wrote:
>
>> I volunteer you. :)
>
> Oh. I never had a look inside Fossil so far…
Fossil’s code is uncommonly well structured and fairly straightforward to
follow.
The worst I can say about the code
On Wed, May 11, 2016 at 4:24 PM, Marko Käning
wrote:
> How to achieve a git'ish squash when merging a (private) branch into trunk?
>
https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki seems to
document this use case. You merge the private branch into a public branch.
The private branch r
On May 11, 2016, at 4:24 PM, Marko Käning wrote:
>
> Is this deliberately missing functionality following fossil's mission to keep
> all history?
I suspect it’s more likely the case that fossil private branches are a subset
of the functionality of regular branches, and we’re philosophically op
On May 11, 2016, at 3:57 PM, Marko Käning wrote:
>
> An auto-closing of tickets if the commit comment contains stg like "closed
> [TICKETID]", "closes [TICKETID]", "fixed [TICKETID]", "fixes [TICKETID]",
> would be nice.
Agreed. The only problem is the perennial one: Someone has to do it. Ar
On May 11, 2016, at 3:56 PM, Marko Käning wrote:
>
> It would be nice if ticket comments would use Markdown formatting as well.
It’s been requested many times. All that’s wanted is for someone to get around
to writing the code and submitting it, I suspect.
On May 11, 2016, at 3:54 PM, Marko Käning wrote:
>
> Why does "fossil timeline" show HTML tags around ticket titles, like this:
>
> Ticket test
>
> ???
Because the command line implementation of “fossil ticket” is basically just
dumping a subset of the contents of the event table in th
On 12 May 2016, at 00:38 , Warren Young wrote:
> On May 11, 2016, at 3:52 PM, Marko Käning wrote:
>>
>> Referring to tickets on a wiki page like this: [968eb6376d] doesn't work,
>> where one would have to use [968eb6376d](tktview?name=968eb6376d).
>>
>> Is this intended, or am I missing somet
On May 11, 2016, at 4:38 PM, Richard Hipp wrote:
>
> On 5/11/16, Marko Käning wrote:
>> Referring to tickets on a wiki page like this: [968eb6376d] doesn't work,
>> where one would have to use [968eb6376d](tktview?name=968eb6376d).
>>
>
> This is only a problem with Markdown, because Markdown
On 12 May 2016, at 00:26 , Warren Young wrote:
> On May 11, 2016, at 3:51 PM, Marko Käning wrote:
>>
>> Timestamps in ticket overview pages
>
> I think I see what you mean. Both the mtime column in /rptview URLs and the
> User Comments boxes in ticket /info pages use UTC.
>
> But, if you un
On May 11, 2016, at 3:52 PM, Marko Käning wrote:
>
> Referring to tickets on a wiki page like this: [968eb6376d] doesn't work,
> where one would have to use [968eb6376d](tktview?name=968eb6376d).
>
> Is this intended, or am I missing something?
Yes, it’s a known limitation.
This missing featu
On 5/11/16, Marko Käning wrote:
> Referring to tickets on a wiki page like this: [968eb6376d] doesn't work,
> where one would have to use [968eb6376d](tktview?name=968eb6376d).
>
This is only a problem with Markdown, because Markdown uses the
Markdown spec for hyperlinks, and that's the way Markd
On May 11, 2016, at 3:51 PM, Marko Käning wrote:
>
> Timestamps in ticket overview pages
I think I see what you mean. Both the mtime column in /rptview URLs and the
User Comments boxes in ticket /info pages use UTC.
But, if you uncheck Admin > Timeline > Use Universal Coordinated Time (UTC),
How to achieve a git'ish squash when merging a (private) branch into trunk?
Is this deliberately missing functionality following fossil's mission to keep
all history?
Well, especially in case of a _private_ branch it might make sense to have such
a feature: assume one wants to work locally on s
An auto-closing of tickets if the commit comment contains stg like "closed
[TICKETID]", "closes [TICKETID]", "fixed [TICKETID]", "fixes [TICKETID]", would
be nice.
This is possible to set up in Trac for instance...
___
fossil-users mailing list
fossil-
It would be nice if ticket comments would use Markdown formatting as well.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Why does "fossil timeline" show HTML tags around ticket titles, like this:
Ticket test
???
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Referring to tickets on a wiki page like this: [968eb6376d] doesn't work, where
one would have to use [968eb6376d](tktview?name=968eb6376d).
Is this intended, or am I missing something?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
ht
Timestamps in ticket overview pages aren't local time (as in the ticket view
page), but UTC, which is irritating. Can this be configured differently
someplace?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8
Hi devs,
while using Fossil’s web-UI I noticed some things regarding the display of
branches.
1) It would be nice, if private branches were marked in /brlist somehow,
preferably
by introducing a new column entitled “Private”, or stg similar.
2) /brlist should NOT show closed branches (but coul
On May 11, 2016, at 1:58 PM, Piotr Orzechowski
wrote:
>
> "At this stage, the standalone server (e.g. "fossil server") does not support
> SSL.”
The standard advice is to tell the fossil server to bind to localhost (as
you’re already doing) and put it behind stunnel or an HTTPS-capable reverse
Ah, I didn't read the:
"At this stage, the standalone server (e.g. "fossil server") does not support
SSL."
here: https://www.fossil-scm.org/xfer/doc/trunk/www/server.wiki.
Still, online help should mention that as well, IMHO.
Regards,
Orzech
Dnia 11 maja 2016 21:08 Piotr Orzechowski
napisa
Hello,
when I try to run fossil server behind https proxy with:
HOME=//fossil //fossil server --https --localhost --port
//fossil/
I get the following error:
unrecognized command-line option, or missing argument: --https
Am I doing something wrong? --https is listed as valid "server" option
On May 11, 2016, at 9:27 AM, bch wrote:
>
> Interesting discussion going on at Hacker News currently.
>
> https://news.ycombinator.com/item?id=11667494
Thanks. I think I adequately-addressed the one anti-Fossil comment there.
Slashdot’s take on this article was kind of odd. I saw a couple of
Interesting discussion going on at Hacker News currently.
https://news.ycombinator.com/item?id=11667494
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
28 matches
Mail list logo
