On Mar 18, 2015, at 5:08 PM, Abilio Marques abili...@gmail.com wrote:
HOME=. ./fossil command
Here’s a thought: Someone on this list gave me the idea of aliasing “fossil” to
“f”. I do it with a symlink instead of a shell alias so that it works even in
places like a Vim :! command.
If you
Actually they do allow (and sometimes encourage) you to connect over ssh,
and they have bash with history... but the file is written inside a
directory called $HOME/data (which is writeable).
Openshift is a nice service. I've used it for some time now, no issues
whatsoever, but (there is always a
[Default] On Thu, 19 Mar 2015 19:22:14 -0430, Abilio Marques
abili...@gmail.com wrote:
Having said these things, I must confess that in my mind, I find the
staging area a difference that's not easily solved. Perhaps some of you
have thought about this before, and have ideas on how to simulate
On 3/19/15, Abilio Marques abili...@gmail.com wrote:
Actually they do allow (and sometimes encourage) you to connect over ssh,
and they have bash with history... but the file is written inside a
directory called $HOME/data (which is writeable).
In your .bashrc script (wherever that is) can you
On 3/19/15, Abilio Marques abili...@gmail.com wrote:
Yes indeed, and that's something new for me. It was documented just a few
weeks ago. Thanks a lot! Looks cleaner that way.
So someone was in my same situation, or is there another useful reason for
having that var?
I remembered that change
I wasn't sure if my attachment made it through the mailing list. Is there an
issue/report/task created for this which I can continue following instead of
through the mailing list? I couldn't figure out how to create an issue on the
fossil-scm site.
On Mar 18, 2015, at 10:30 AM, die.drachen
Yes indeed, and that's something new for me. It was documented just a few
weeks ago. Thanks a lot! Looks cleaner that way.
So someone was in my same situation, or is there another useful reason for
having that var?
On Thu, Mar 19, 2015 at 6:39 PM, Richard Hipp d...@sqlite.org wrote:
On
On Thu, Mar 19, 2015 at 6:32 PM, Richard Hipp d...@sqlite.org wrote:
On 3/19/15, Scott Robison sc...@casaderobison.com wrote:
I can't answer for Abilio, but given my recent increased experience with
git due to workplace changes: the git folk seem to prefer the staging
area
because
Here’s a thought: Someone on this list gave me the idea of aliasing
“fossil” to “f”. I do it with a symlink instead of a shell alias so that
it works even in places like a Vim :! command.
Yeah,
After writing yesterday's email, I worked another half hour, and ended up
frustrated, so I did
Presumably they don't expect users to use the shell, as the shell history
is also (normally) saved in the home dir (except in some ultra-pedantic
setups where the history is stored in a place where the user cannot
access/edit it).
- stephan
Sent from a mobile device, possibly from bed. Please
On Thu, Mar 19, 2015 at 6:14 PM, Richard Hipp d...@sqlite.org wrote:
On 3/19/15, Abilio Marques abili...@gmail.com wrote:
Most of the friends I've shown fossil to love the idea of having SCM,
wiki
and tickets in the same, tiny place. Looks promising for them... but then
they miss the
On 3/19/15, Scott Robison sc...@casaderobison.com wrote:
I can't answer for Abilio, but given my recent increased experience with
git due to workplace changes: the git folk seem to prefer the staging area
because you're less likely to accidentally commit something you didn't mean
to.
On Thu, Mar 19, 2015 at 6:14 PM, Abilio Marques abili...@gmail.com wrote:
But you're right, now that I think about it, is the only time I've ever
seen a home directory not owned by the corresponding user but by root.
Does the hosting service provide special commands for creating directories
On Mar 19, 2015, at 4:14 PM, Abilio Marques abili...@gmail.com wrote:
I actually didn't know about the ALL command. That changes the things. I
believe I've gone over it every time I run fossil help, but never stopped to
learn more about it, so thanks for opening my eyes.
Yeah, “fossil all
Not that I'm aware of. I did some googling, and only found upset people,
but no justification, nor any kind of special commands.
On Thu, Mar 19, 2015 at 5:54 PM, Ron W ronw.m...@gmail.com wrote:
On Thu, Mar 19, 2015 at 6:14 PM, Abilio Marques abili...@gmail.com
wrote:
But you're right, now
On Thu, Mar 19, 2015 at 5:45 PM, Richard Hipp d...@sqlite.org wrote:
I remembered that change as having occurred years and years ago. But
upon consulting the timeline, I see that Joe put it in two months ago.
I don't recall the exact reason.
Thanks Joe! This solves an annoyance for me.
--
On 3/19/15, Abilio Marques abili...@gmail.com wrote:
Most of the friends I've shown fossil to love the idea of having SCM, wiki
and tickets in the same, tiny place. Looks promising for them... but then
they miss the git staging area.
Fossil does give you the ability to do a partial commit
This email has two motivations.
First:
Through the years I've evangelized about several subjects. Most of them go
hand in hand with my philosophy that software tools (well, this is
applicable to everything in life) should be as simple as possible for the
task they are intended to be used.
I was cooking dinner, so Scott wrote it first. Basically I agree with his
point of view. I must confess that historically, I first used fossil, then
git, so staging was actually weird for me at the beginning.
Then I kinda liked it for no apparent reason. It felt like it simplified
the partial
On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp d...@sqlite.org wrote:
On 3/19/15, Abilio Marques abili...@gmail.com wrote:
Most of the friends I've shown fossil to love the idea of having SCM, wiki
and tickets in the same, tiny place. Looks promising for them... but then
they miss the git
On 3/19/15, Andreas Kupries andre...@activestate.com wrote:
On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp d...@sqlite.org wrote:
On 3/19/15, Abilio Marques abili...@gmail.com wrote:
Most of the friends I've shown fossil to love the idea of having SCM,
wiki
and tickets in the same, tiny
Starting several fossil servers with ui increments port from 8080 onwards.
Starting several fossil servers with server increments port ditto.
Mixing ui and server instances results in double-bound ports.
Don't know whether that's a Windows-only issue.
Example: When running `fossil server REPO_A`
I hope you don't mind that I got up an Ubuntu PPA for current fossil
releases. This was merely a testing thing for me, to build learn how to
handle a personal package archive - addiotionally it nagged me, that the
currently shipped version of fossil in ubuntu is failry outdated.
This PPA uses
Nice! Btw where can I see the build script that is fed to Launchpad's
automated build services?
Cheers.
- Vikrant
On 19 March 2015 at 17:01, Oliver Friedrich
redtalonof+mailingl...@gmail.com wrote:
I hope you don't mind that I got up an Ubuntu PPA for current fossil
releases. This was merely
These scripts are called recipes. I checked it in into my second branch
that keeps the packaging information.
The recipes that are actually used are only in launchpad and not stored in
the repository itself, anyway, you can look at it here:
On 3/19/15, Tontyna tont...@ultrareal.de wrote:
Starting several fossil servers with ui increments port from 8080 onwards.
Starting several fossil servers with server increments port ditto.
Mixing ui and server instances results in double-bound ports.
Don't know whether that's a Windows-only
By doing git commit -a, your doing an implicit
git add -A before the commit, which stages all the uncommitted changes, and
then you're working close to what you would in fossil.
But we're talking about the Linus dream:
You do some changes, then you select the files (not it seems that even line
Thus said Abilio Marques on Thu, 19 Mar 2015 21:25:05 -0430:
By doing git commit -a, your doing an implicit
git add -A before the commit, which stages all the uncommitted
changes, and then you're working close to what you would in fossil.
I see, this is totally foreign to how I use
Really? didn't know that... I'm impressed by that. There've been times when
I've needed it, then proceeded to stash, then stash apply, then modified,
then committed, then stash popped and so on...
Unless you mean that you do a git add, the modify the same file, and commit
as is, without doing git
Thus said Abilio Marques on Thu, 19 Mar 2015 19:22:14 -0430:
Having said these things, I must confess that in my mind, I find the
staging area a difference that's not easily solved. Perhaps some of
you have thought about this before, and have ideas on how to simulate
it in a clean way.
I think I missed you here, or you missed me, but I know you got the fact
that by doing:
git commit -a or git commit filename, you're skipping the staging area.
For example, by doing git commit -a -m this is a test, what git is
internally doing is the equivalent to:
git add -A
git commit -m this
will only commit changes in 1, and if you do git status, will tell you
about the modifications done in 3.
On Thu, Mar 19, 2015 at 8:38 PM, Richard Hipp d...@sqlite.org wrote:
Further questions about staging area:
If I do this:
(1) Edit file xyzzy.txt
(2) git add xyzzy.txt
On Thu, Mar 19, 2015 at 06:22:52PM -0600, Scott Robison wrote:
I can't answer for Abilio, but given my recent increased experience with
git due to workplace changes: the git folk seem to prefer the staging area
because you're less likely to accidentally commit something you didn't mean
to.
After reading Mr. Hipp answer to some previous email about git saying:
So the staging area is being used as a way of working around the fact
that Git does not allow multiple independent check-outs against the
same repository? Am I understanding that correctly?
I started to think: what does it
I'm brand new to fossil but have used git some and mercurial even longer. When
I'm working on a project I tend to poke around in the areas of code nearby to
what my task directly involves - as a manner of investigating and learning.
The git staging area is useful to my workflow because I am
Further questions about staging area:
If I do this:
(1) Edit file xyzzy.txt
(2) git add xyzzy.txt
(3) More edits to xyzzy.txt
(4) git commit
Then does only the first set of edits to xyzzy.txt get committed, or
do both edits (1) and (3) get committed?
--
D. Richard Hipp
Further questions about staging area:
If I do this:
(1) Edit file xyzzy.txt
(2) git add xyzzy.txt
(3) More edits to xyzzy.txt
(4) git commit
Then does only the first set of edits to xyzzy.txt get committed, or
do both edits (1) and (3) get committed?
Only
Do you follow the traditional?:
(1) modify a file or files
(2) add the files (every single time... this sucks sometimes, as Joerg said)
(3) commit
If the answer is yes, you're using the staging area... Cool things about
that... yes, you can select what to include (seems that line by line). See
Yes, I realized you seem to be right and nobody told me (I learnt git on my
own), but in git, you can run git add --interactive (and it allows you to
selectively work with each uncommitted add you did) and there is also git
add --edit, which allows you to directly edit the unified patch in your
On Mar 19, 2015, at 5:52 PM, Abilio Marques abili...@gmail.com wrote:
I've toyed with the idea of writing a shim so fossil can be used in place
of git or subversion.
I speak only pidgin Git, so I wouldn’t like to speculate about how difficult
such a shim would be to write.
I can, however,
On 3/19/15, Abilio Marques abili...@gmail.com wrote:
After reading Mr. Hipp answer to some previous email about git saying:
So the staging area is being used as a way of working around the fact
that Git does not allow multiple independent check-outs against the
same repository? Am I
On 3/19/15, Abilio Marques abili...@gmail.com wrote:
PS: after running my quick test in fossil 1.31, I ended with two separate
artifacts, both on trunk, but without a common ancestor. I'm running
Ubuntu, and I haven't compiled the 1.32. I believe that version was
released as a patch for this
die.drachen wrote:
The git staging area is useful to my workflow because I am often
making changes and testing something, but later decide to have
separate commits within all the changes. This helps preserve a nicer
history where commits usually have single-responsibility. For example,
Abilio Marques wrote:
Cool things about
that... yes, you can select what to include (seems that line by line).
This does not require a staging area. Darcs, for example, had such
selective commits since its inception (in fact, it was and is the
default mode of operation for Darcs, for better
On Thu, Mar 19, 2015 at 6:10 PM, Abilio Marques abili...@gmail.com wrote:
Really? didn't know that... I'm impressed by that. There've been times when
I've needed it, then proceeded to stash, then stash apply, then modified,
then committed, then stash popped and so on...
Unless you mean that
Thus said Abilio Marques on Thu, 19 Mar 2015 22:10:41 -0430:
git commit -a or git commit filename, you're skipping the staging
area.
Yes, that's right---thanks to your explanation. I haven't needed it and
now that I understand it (at least according what has been discussed)
I'm
I imagined some of those scenarios right away after my experiment... Some
are great... Until today, I was doing a fossil clone file:// or ssh:// ...
Now I can deal with just a single copy of the repo.
I only see it quickly and indirectly mentioned in section 2.3 here:
Thus said Abilio Marques on Thu, 19 Mar 2015 21:08:55 -0430:
(1) modify a file or files
(2) add the files (every single time... this sucks sometimes, as Joerg said)
(3) commit
I'm not sure what (2) is unless you mean that I create new files in the
working checkout and then use ``git add''
Thus said Abilio Marques on Thu, 19 Mar 2015 21:29:28 -0430:
As a side note, one of the reasons I dislike git is because the
commands don't do (do as in never) what their name imply, and some are
hidden as subcommands inside commands that are meant for other
purposes.
You mean
Hi,
I wonder why there isn't a command for simplifying the process of marking a
commit as a mistake. So with a single command, fossil will:
*Move the commit and its derived commits to mistake branch.
*If there is a leaf in the branch, the leaf will be closed.
*The
Yeah, I know home directory MUST be writable. I do fight with that all the
time. I've always guessed is some sort of weird security thing. Never
asked. I'm not asking fossil to change because of that. As you say, is an
OpenShift issue.
Just thought fossil was of better use without global config
On Thu, Mar 19, 2015 at 11:53 AM, Richard Hipp d...@sqlite.org wrote:
On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Thu, Mar 19, 2015 at 10:16:18AM -0400, Richard Hipp wrote:
On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Thu, Mar 19, 2015 at
On 3/19/15, a...@gmx-topmail.de a...@gmx-topmail.de wrote:
Content-Encoding: gzip
Content-Length: 1516
So the question becomes: Should the Content-Length be the length of
the content before or after compression?
Fossil inherited the code for this from CVSTrac, which has always set
the
On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote:
On 3/19/15, a...@gmx-topmail.de a...@gmx-topmail.de wrote:
Content-Encoding: gzip
Content-Length: 1516
So the question becomes: Should the Content-Length be the
Am 19.03.2015 um 00:01 schrieb a...@gmx-topmail.de:
Am 18.03.2015 um 00:28 schrieb Tontyna:
If that happened on my computer I'd recompile Fossil, commenting out the
line #165 in winhttp.c :
-- file_delete(zReplyFName);
and have a look at the `fossil_server_P*_out*.txt` files.
that's a good
On 14.03.2015 13:12, a...@gmx-topmail.de wrote:
I am having problems to access my local fossil repositories with a
recent versions of chrome, it looks like only part of the html code is
served by the standalone webserver.
My question is whether this is a known problem and others can verify it
On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote:
On 3/19/15, a...@gmx-topmail.de a...@gmx-topmail.de wrote:
Content-Encoding: gzip
Content-Length: 1516
So the question becomes: Should the Content-Length be the length of
the content before or after compression?
Before aka
On Thu, Mar 19, 2015 at 12:56:02PM -0400, Ron W wrote:
I think there is some confusion of Content-Encoding vs Transfer-Encoding
Content-Encoding is gzip, Transfer-Encoding should be unset as Fossil
doesn't do HTTP/1.1 Chunked Transfers.
Joerg
___
On Thu, Mar 19, 2015 at 4:53 PM, Richard Hipp d...@sqlite.org wrote:
I've also been reading in RFC 7230. The more I read, the more I
believe this is a Chrome bug.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
is pretty unambiguous:
The transfer-length of a message is the
On Thu, Mar 19, 2015 at 9:32 AM, bch brad.har...@gmail.com wrote:
The reality is that nothing can be perfect for 100% of all possible use
cases, and in this particular case, I just got unlucky. The merge conflict
information as given couldn't support a mechanical pick one or the other
On Thu, Mar 19, 2015 at 10:16:18AM -0400, Richard Hipp wrote:
On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote:
On 3/19/15, a...@gmx-topmail.de a...@gmx-topmail.de wrote:
Content-Encoding: gzip
Content-Length:
Thus said Tontyna on Thu, 19 Mar 2015 11:58:40 +0100:
Starting several fossil servers with ui increments port from 8080 onwards.
Starting several fossil servers with server increments port ditto.
Mixing ui and server instances results in double-bound ports.
Don't know whether that's a
On Mar 18, 2015, at 5:04 PM, Abilio Marques abili...@gmail.com wrote:
home directory /var/lib/openshift/54fb48714382ecec88eb/ must be writeable
That sounds like just cause to complain to OpenShift tech support. There’s no
good justification for $HOME to be read-only on a web platform
Am 19.03.2015 um 15:19 schrieb Thomas Schnurrenberger:
On 14.03.2015 13:12, a...@gmx-topmail.de wrote:
I am having problems to access my local fossil repositories with a
recent versions of chrome, it looks like only part of the html code is
served by the standalone webserver.
My question is
On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Thu, Mar 19, 2015 at 10:16:18AM -0400, Richard Hipp wrote:
On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote:
On 3/19/15, a...@gmx-topmail.de
On Mar 19, 2015 12:40 AM, Scott Robison sc...@casaderobison.com wrote:
On Wed, Mar 18, 2015 at 5:41 PM, bch brad.har...@gmail.com wrote:
I tried this, and I see what you're talking about -- It's not clear to
me it's an error (I'm not apologizing for anything that happened here,
but I'd have
Am 19.03.2015 um 16:53 schrieb Richard Hipp:
On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Thu, Mar 19, 2015 at 10:16:18AM -0400, Richard Hipp wrote:
On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote:
67 matches
Mail list logo
