On 8 October 2013 00:27, Joseph R. Justice wrote:
I note that there are people who *do* put their home directories, .rc
> files, etc under source control.
Indeed, see for example
http://episodes.gitminutes.com/2013/06/gitminutes-13-richard-hartmann-on.html
- Erlend
On Mon, Oct 7, 2013 at 3:27 PM, Joseph R. Justice wrote:
> On Mon, Sep 23, 2013 at 7:05 AM, Alaric Snell-Pym > wrote:
>
>
>> I've written a backup/archival tool based on content-addressible
>> storage, and a common question people ask is "So why don't I just put my
>> home directory/entire filesy
On Mon, Oct 7, 2013 at 11:31 AM, Matt Welland wrote:
>
> Applying constraints as receiver end filtering could be very useful and I
> think it could fit the sync model if not needed blobs were not necessarily
> dropped but a record was kept so that they wouldn't be sync'd and they are
> kept out o
On Mon, Sep 23, 2013 at 7:05 AM, Alaric Snell-Pym
wrote:
> I've written a backup/archival tool based on content-addressible
> storage, and a common question people ask is "So why don't I just put my
> home directory/entire filesystem in git, then?", and I have to raise
> this aspect of the quite
On Mon, Oct 7, 2013 at 3:54 PM, Matt Welland wrote:
> Losing the username in annotate command line is a big hit for me. I don't
> understand why that would be removed.
>
>From Richard's comment, I surmise he (and others) mostly use the web
version of annotate, where clicking on a link is relati
Losing the username in annotate command line is a big hit for me. I don't
understand why that would be removed. Is this driven by Windows users who
are stuck with limited terminal width? You could shave off some characters
by only printing the first 4 letters of the node id. Also the : at the end
o
On Mon, Oct 7, 2013 at 12:18 PM, Ron Wilson wrote:
> On Mon, Oct 7, 2013 at 2:37 PM, Andreas Kupries
> wrote:
>>
>> (*) With bisect we have the change, and this know who made it. However
>> sometimes it is possible to determine a problematic line without
>> having bisected during investigation, a
On Mon, Oct 7, 2013 at 2:37 PM, Andreas Kupries wrote:
> On Mon, Oct 7, 2013 at 6:38 AM, Richard Hipp wrote:
> > Most people are more interested in the fact that the line changed. The
> > identity of the editor is of secondary importance,
>
> Not when you have tracked a bug to a specific line, o
On Mon, Oct 7, 2013 at 1:40 PM, Jakob Eriksson wrote:
> Of course you have no obligations but I think Fossil is getting more
> popular. That means you will break more people's scripts and expectations.
> Just something to consider.
>
There is tension between preserving backwards compatibility on
On Mon, Oct 7, 2013 at 6:38 AM, Richard Hipp wrote:
> On Mon, Oct 7, 2013 at 9:12 AM, Stefan Bellon wrote:
>> But more severely, the information
>> who changed the line is now not present anymore at all.
>
>
> Most people are more interested in the fact that the line changed. The
> identity of t
For each person taking that time, there will be 1000 more not taking that time.
That said, you are intentionally leaving a gap between human interaction and a
library, and that gap is classic Unix scripting with stdout and stdin.
Of course one could build a stable text interface automation frien
On Mon, Oct 7, 2013 at 7:40 PM, Jakob Eriksson wrote:
> Of course you have no obligations but I think Fossil is getting more
> popular. That means you will break more people's scripts and expectations.
> Just something to consider.
>
OTOH, anyone who takes the time to ask on the list what they ca
Of course you have no obligations but I think Fossil is getting more popular.
That means you will break more people's scripts and expectations. Just
something to consider.
Best regards,
Jakob
Stephan Beal skrev:
>On Mon, Oct 7, 2013 at 4:26 PM, Stefan Bellon wrote:
>
>> On Mon, 07 Oct, R
Very nice.
My initial thoughts were to reproduce the existing fossil cmds but you are
correct that this should not be the library's sole purpose.
On Mon, Oct 7, 2013 at 11:59 AM, Stephan Beal wrote:
> On Mon, Oct 7, 2013 at 5:27 PM, wrote:
>
>> I guess the library interface is the target movin
On Mon, Oct 7, 2013 at 5:27 PM, wrote:
> I guess the library interface is the target moving forward instead of
> forcing standardized output?
>
Good question. Ideally the library will produce _no_ text output other than
the propagation of error messages from lower levels (e.g. messages from the
Applying constraints as receiver end filtering could be very useful and I
think it could fit the sync model if not needed blobs were not necessarily
dropped but a record was kept so that they wouldn't be sync'd and they are
kept out of the list of blobs. Essentially something similar to what the
sh
"Fossil has never guaranteed specific output for any given command, ...~
The output of any and all commands is subject to change without notice
between any given versions. As a general rule, whoever hacks the feature
determines the output format. i would go so far as to say that Fossil's
output has
On Mon, Oct 7, 2013 at 10:26 AM, Stefan Bellon wrote:
>
> > The username was therefore removed from the primary display in order
> > to reduce the amount of clutter and to make the output easier for
> > humans to read.
>
> Was this discussed on the mailing list and I missed it? Or was this
> just
On Mon, Oct 7, 2013 at 4:26 PM, Stefan Bellon wrote:
> On Mon, 07 Oct, Richard Hipp wrote:> Most people are more interested in
> the fact that the line changed.
> > The identity of the editor is of secondary importance,
>
> I beg to differ strongly. The command is called "annotate" and not
> "cat
On Mon, 07 Oct, Richard Hipp wrote:
> On Mon, Oct 7, 2013 at 9:12 AM, Stefan Bellon
> wrote:
>
> > Previously, with fossil 1.24, the third column of the "annotate"
> > output was the author who did the most recent change to the line.
> > Now, with fossil 1.27, it's just the line number being dis
Hello,
There's a jan-httpsproxytunnel (work-in-progress) branch with support
for tunneling https over a http proxy.
I have done a few https-over-http-proxy clones, and I also made some
https (without proxy) clones to see if I broke anything. I have however
not done extensive testing, so ..
On Mon, Oct 7, 2013 at 9:12 AM, Stefan Bellon wrote:
>
> Previously, with fossil 1.24, the third column of the "annotate" output
> was the author who did the most recent change to the line. Now, with
> fossil 1.27, it's just the line number being displayed.
>
> First of all, this information is a
Hi all,
we've been using Fossil 1.24 as storage system for generated files in
our environment for quite some time now.
Recently, we decided to update from 1.24 to 1.27. When deciding whether
to do the update or not, I read through all the ChangeLogs on the
website and I made sure that all command
On Sun, Oct 6, 2013 at 9:55 PM, Joseph R. Justice wrote:
> During the push, it is noticed that R(N) says bug B2 is closed while R'
> says it is open and blocked by B1 (and that A specified the block), which
> is open both in R' and R(N). N should be notified of this as it is
> something which can
24 matches
Mail list logo
