On Tue, 28 Mar 2017 00:33:02 +
"Matija Čupić (GitLab, Inc.)" wrote:
> > > > 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
Thus said Warren Young on Mon, 27 Mar 2017 10:21:42 -0600:
> Explain to me how someone deciding between Fossil and Git gets down to
> automatic pagination as the key differentiator, the one that seals
> their decision.
While it may not be used as a determining factor in deciding between Git
a
That was it!
I ran the command and received the output:
Starts with UTF-8 BOM: no
Starts with UTF-16 BOM: no
Looks like UTF-8: no
Has flag LOOK_NUL: yes
Has flag LOOK_CR: no
Has flag LOOK_LONE_CR: no
Has flag LOOK_LF: yes
Has flag LOOK_LONE_LF: yes
Has flag LOOK_CRLF: no
Has flag LOOK_LONG: no
Ha
On 3/27/17, Ross Berteig wrote:
>
> I believe that a line is too long if it is more than about 8191 ASCII
> characters, a restriction based on the size of the buffer used in the
> diff engine.
Technically, that restriction is due to the way hashes are computed on
individual lines during the diff.
On 3/27/2017 5:44 PM, Byron Sanchez wrote:
I'm tracking several plain-text files in a repository. These are emacs
org-mode files.
Fossil sees most of the files in this repo as normal plain-text files
and as such, they can be diffed via the fossil web interface.
Recently, however, fossil has
On Mar 27, 2017 6:44 PM, "Byron Sanchez" wrote:
Recently, however, fossil has started interpreting one of these org-mode
files as a binary file. Now, fossil prompts with it's binary-file warning
each time I update the file. In addition, this file can no longer be diffed
in the web interface, sinc
I'm tracking several plain-text files in a repository. These are emacs
org-mode files.
Fossil sees most of the files in this repo as normal plain-text files and
as such, they can be diffed via the fossil web interface.
Recently, however, fossil has started interpreting one of these org-mode
files
On Sun, Mar 26, 2017 at 2:56 PM,
wrote:
>
> Date: Sun, 26 Mar 2017 20:50:38 +0200
> From: Jan Danielsson
> To: fossil-users@lists.fossil-scm.org
> Subject: Re: [fossil-users] GitLab v. Fossil. Was: Eric Raymond
> (a.k.a. ESR) has published an SCM
> Message-ID: <45ad044c-1bcd-3a67-bfb3-4e
On 3/27/2017 2:29 PM, Christophe Gouiran wrote:
Someone wanting to get the list or current branch without relying on
raw Fossil output could use "fossil json branch list" for that purpose.
But only if fossil was configured with JSON support. Which is not
configured by default, or in the
>
>
> While the addition of a subcommand seems like a good idea, changing
> default behaviour will no doubt break existing workflows.
>
I agree on this point.
However I have learned (where possible) to never rely on raw commands
outputs in my wrappers.
Indeed, I took over several years ago a Pytho
On Mar 27, 2017, at 12:07 PM, Warren Young wrote:
>
> It isn’t always clue to newbies
s/clue/clear/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On Mon, Mar 27, 2017 at 10:40 AM, Christophe Gouiran
wrote:
>
> please find an attached patch which implements a new "current" subcommand for
> "branch".
> This is now the default subcommand if one executes "fossil branch" without
> any subcommand.
While the addition of a subcommand seems like
On Mar 27, 2017, at 11:50 AM, bch wrote:
>
> > executing "fossil branch" to get the current branch is not very convenient
> > to me.
>
> Note that "fossil info" gives information about the current checkout,
> including the branch name.
That info is also given in “fossil status”, a command you
On Mar 27, 2017 10:40, "Christophe Gouiran" wrote:
Hello everybody,
Amount of branches may be quite important (in Fossil code itself, there are
now about 100 branches).
In this case, executing "fossil branch" to get the current branch is not
very convenient to me.
Note that "fossil info" gives
Nice!
--
//twitter: @umgeher
//xmpp: m...@umgeher.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Hello everybody,
Amount of branches may be quite important (in Fossil code itself, there are
now about 100 branches).
In this case, executing "fossil branch" to get the current branch is not
very convenient to me.
please find an attached patch which implements a new "current" subcommand
for "bran
On 03/27/17 01:55, Roy Marples wrote:
Pager output disappearing with the pager (I assume when asking the
pager to exit) is an issue with the pager.
I disagree. Disappearing output uses the "alternate screen" of a
terminal so that the pager's output does not interfere with your
non-reading s
On Mar 27, 2017, at 10:19 AM, Martin S. Weber wrote:
>
> On 03/27/17 01:55, Roy Marples wrote:
>> Pager output disappearing with the pager (I assume when asking the pager to
>> exit) is an issue with the pager.
>
> I disagree. Disappearing output uses the "alternate screen" of a terminal so
>
On Mar 26, 2017, at 11:49 AM, Tomasz Konojacki wrote:
>
> 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 opp
On Mon, Mar 27, 2017 at 9:19 AM, Stefan Bellon wrote:
> would have to take a backup of the fossil in version 1 state? Or is
> there any "go back to version 1 format" emergency way?
>
fossil 1 has a strict "artifact" format which v2 breaks (in that the hash
lengths differ), so v1 cannot read arti
On Sun, 26 Mar 2017 13:18:08 -0400
Richard Hipp wrote:
> > 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 hea
On Mon, 13 Mar, Richard Hipp wrote:
>
> The upgrade is simple. Just replace your current fossil executable
> with a new one. Everything should work exactly as it did before.
> There are no incompatibilities. The only difference is that Fossil
> 2.1 will read and write the latest repositories whe
22 matches
Mail list logo