Re: [fossil-users] Is this a crazy idea?

[Luca Ferrari]

On Fri, Mar 20, 2015 at 2:11 AM, die.drachen  wrote:
>
>> 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 changes from step 1 are committed. After adding changes from step 1 to 
> staging area then making more changes, a status looks like this:

Yes, and this is the idea behind the staging area, to freeze the
commit and allow you to continue working. I have to admit that I don't
use it very much for this purpose (I use branches, rebasing).

Now, coming back to the original idea, my personal opinion is that is
not going to work.
Besides the technical differences, the workflows are different. Hiding
the fossil workflow behind the git one (for instance) could lead to
problems. And will not pop in users to fossil, since they will be
thinking in terms of "git".
It sounds to me like the vc-mode for emacs, that is "appropriate" to
many vcs systems.
Then you try something native, like magit, that is specifically
designed for a single implementation, and you work a lot better.
My 2 cents.

Luca
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] multiple independent check-outs against the same repository

[Jan Nijtmans]

2015-03-20 4:56 GMT+01:00 Richard Hipp :
> I rue the day that I allowed that patch to land on trunk.
> But it is all fixed now - you won't have the problem with 1.32.

Note that the "initial empty commit" is an unique feature of
fossil, GIT and SVN don't have that. Abilio started with
a completely empty repository and started committing from
two different (empty) checkouts. That means the two
file sets committed don't have any relation. If you
use fossil 1.32 for doing the same, there will be
an additional initial empty commit, which suggests a
relation which isn't really there. The only problem
I see in your workflow is that you were not warned
that actually you were creating a fork, in 1.32 you
will get that warning (after doing the same steps):
$ fossil commit -m "commit b"
would fork.  "update" first or use --allow-fork.

Thank you for your report.

Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[Peter Spjuth]

On Fri, Mar 20, 2015 at 5:38 AM, Reimer Behrends  wrote:

> First, the safer (and arguably overall better) approach is to recognize
> that stash/shelve operations are the inverse of the staging area for this
> purpose. I.e., rather than stage a partial commit, you stash everything but
> the partial commit, then commit whatever changes remain in toto. This does
> not require the staging area and ensures that, e.g., you're not committing
> something that doesn't even compile (which breaks bisect, CI tools, etc.).
>

This is exactly my viewpoint. A work a lot in Subversion and I often miss a
stash, never a staging area.
I have used git's staging area as intended occasionally but mostly I find
it annoying. I feel slighty dirty
when I do a partial commit since I know it is, in theory at least, untested.

A stash with abilites like "git add --interactive" to stash parts within a
file is the way to go IMO.

/Peter
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[Gour]

Richard Hipp  writes:

> Please help me to understand why people think that the git staging
> area is a good idea.

Considering that git provides 'commit -a' option which practically
eliminates staging area.

Moreover, the author of very popular Pro Git book
(http://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository)
in "Skipping the Staging Area" section says:

"Although it can be amazingly useful for crafting commits exactly how
you want them, the staging area is sometimes a bit more complex than you
need in your workflow. If you want to skip the staging area, Git
provides a simple shortcut. Adding the -a option to the git commit
command makes Git automatically stage every file that is already tracked
before doing the commit, letting you skip the git add part..."

which led me to conclude that we can live in Fossil without it. ;)


Sincerely,
Gour

-- 
Therefore, without being attached to the fruits of activities, 
one should act as a matter of duty, for by working without 
attachment one attains the Supreme.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] multiple independent check-outs against the same repository

[John Found]

On Thu, 19 Mar 2015 22:36:56 -0430
Abilio Marques  wrote:

> I started to think: what does it mean to have "multiple independent
> check-outs"? And I knew I wouldn't be able to sleep well because of not
> knowing. So I created a new test repo, and began:

It really surprised me. Using multiply check-outs is so natural, that 
I never though someone can not use it...

IMHO, this is because the source *file* is usually perceived as something 
primary and the version control system as some kind of backup system.

But starting use fossil, I realized, that the primary is actually the
check-in. The files are simply scratch places, that you can create, delete
and change in random manner. At the end the important is only what you
checked out.


-- 
http://fresh.flatassembler.net
http://asm32.info
John Found 
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[Ramon Ribó]

A possible workflow to do partial commits in fossil could be:

- fossil diff --tk --partial-commit

(A special version of fossil diff --tk appears where there is a
checkbox in every difference)

- Select some differences

- Save and quit

(Then, an automatic "fossil stash" is performed where the original
modified files are stored. The files left in the working area only
contain the selected differences)

- Compile and test

- fossil commit

  (command could print a message remembering us that there is a
pending automatic stash and the way to recover it)

- fossil stash pop


The trick here is that the GUI tool should perform the stash
automatically, to avoid accidental loss of modified code and should
inform the user of the situation.


RR


2015-03-20 9:31 GMT+01:00 Gour :
> Richard Hipp  writes:
>
>> Please help me to understand why people think that the git staging
>> area is a good idea.
>
> Considering that git provides 'commit -a' option which practically
> eliminates staging area.
>
> Moreover, the author of very popular Pro Git book
> (http://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository)
> in "Skipping the Staging Area" section says:
>
> "Although it can be amazingly useful for crafting commits exactly how
> you want them, the staging area is sometimes a bit more complex than you
> need in your workflow. If you want to skip the staging area, Git
> provides a simple shortcut. Adding the -a option to the git commit
> command makes Git automatically stage every file that is already tracked
> before doing the commit, letting you skip the git add part..."
>
> which led me to conclude that we can live in Fossil without it. ;)
>
>
> Sincerely,
> Gour
>
> --
> Therefore, without being attached to the fruits of activities,
> one should act as a matter of duty, for by working without
> attachment one attains the Supreme.
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] multiple independent check-outs against the same repository

[John Found]

On Fri, 20 Mar 2015 11:46:14 +0200
John Found  wrote:

> On Thu, 19 Mar 2015 22:36:56 -0430
> Abilio Marques  wrote:
> 
> > I started to think: what does it mean to have "multiple independent
> > check-outs"? And I knew I wouldn't be able to sleep well because of not
> > knowing. So I created a new test repo, and began:
> 
> It really surprised me. Using multiply check-outs is so natural, that 
> I never though someone can not use it...
> 
> IMHO, this is because the source *file* is usually perceived as something 
> primary and the version control system as some kind of backup system.
> 
> But starting use fossil, I realized, that the primary is actually the
> check-in. The files are simply scratch places, that you can create, delete
> and change in random manner. At the end the important is only what you
> checked out.

At the end the important is what you actually "checked in" of course. :)

> 
> 
> -- 
> http://fresh.flatassembler.net
> http://asm32.info
> John Found 
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


-- 
http://fresh.flatassembler.net
http://asm32.info
John Found 
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[Abilio Marques]

Warren, thanks for your reply. It was pretty comprehensive, and I liked it,
even when those are bad news. I actually discovered some of them myself a
long time ago... Same goes to GIT,  That's the reason I've only toyed with
the idea, but then started to think about the many many things that have to
be done to create the "illusion". The original email was meant to ask if
someone had thoughts about it.

The shim wouldn't be meant for regular users, but mostly for GUI text
editing suites, that don't go over the entire combinations that a crazily
imaginative command line user could make. Those tools basically allow you
to commit, select which files and type in a comment, move inside the
branches, and pretty much that.

Actually I don't even think the behaviour should be the exact same one from
git. Perhaps it could actually allow some differences. After all, I do want
to use fossil in the first place, not git... Perhaps it should return warns
when there is a known behaviour difference.

Is kinda what you do when you use Openoffice to edit Word documents, Word
to edit ... wordperfect (yeah, I think Microsoft golden years are gone...
Embrace, extend and extinguish... what an era), or Apple Pages to edit
Word. You know that you're doing an imperfect thing, that the result won't
be perfect, yet you continue to use it, and even learn the differences. The
programs warn you that the things you are willing to save could not be
compatible, yet you proceed to save them.

To put it back again in better words, the idea is to make an adaptor that
let's existing apps (mostly IDEs) to use Fossil as another version control
system, until they get a native plugin, but via using the existing GIT tool
interface.


This email was meant to start a conversation about that. So this note is to
say that I love, really, love the idea of discussing usefulness of staging
or not (my personal opinion is that is not useful), but mostly the idea of
select which lines to keep for a specific commit.

I will then proceed to open another discussion about that, sort to keep
this one for the "shim" idea. Anyone who thinks a shim can at least be an
idea to try? Also, ideas from IDEs users are welcomed (as I personally
don't know them all, mostly, I don't use them often, I edit with nano and
nowadays with gedit, unless on Windows, where I use notepad++ and Microsoft
Visual C 6).

On Fri, Mar 20, 2015 at 5:54 AM, Ramon Ribó  wrote:

> A possible workflow to do partial commits in fossil could be:
>
> - fossil diff --tk --partial-commit
>
> (A special version of fossil diff --tk appears where there is a
> checkbox in every difference)
>
> - Select some differences
>
> - Save and quit
>
> (Then, an automatic "fossil stash" is performed where the original
> modified files are stored. The files left in the working area only
> contain the selected differences)
>
> - Compile and test
>
> - fossil commit
>
>   (command could print a message remembering us that there is a
> pending automatic stash and the way to recover it)
>
> - fossil stash pop
>
>
> The trick here is that the GUI tool should perform the stash
> automatically, to avoid accidental loss of modified code and should
> inform the user of the situation.
>
>
> RR
>
>
> 2015-03-20 9:31 GMT+01:00 Gour :
> > Richard Hipp  writes:
> >
> >> Please help me to understand why people think that the git staging
> >> area is a good idea.
> >
> > Considering that git provides 'commit -a' option which practically
> > eliminates staging area.
> >
> > Moreover, the author of very popular Pro Git book
> > (
> http://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository
> )
> > in "Skipping the Staging Area" section says:
> >
> > "Although it can be amazingly useful for crafting commits exactly how
> > you want them, the staging area is sometimes a bit more complex than you
> > need in your workflow. If you want to skip the staging area, Git
> > provides a simple shortcut. Adding the -a option to the git commit
> > command makes Git automatically stage every file that is already tracked
> > before doing the commit, letting you skip the git add part..."
> >
> > which led me to conclude that we can live in Fossil without it. ;)
> >
> >
> > Sincerely,
> > Gour
> >
> > --
> > Therefore, without being attached to the fruits of activities,
> > one should act as a matter of duty, for by working without
> > attachment one attains the Supreme.
> >
> >
> > ___
> > fossil-users mailing list
> > fossil-users@lists.fossil-scm.org
> > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] same port in use by concurrent fossil instances

[Tontyna]

Am 19.03.2015 um 19:36 schrieb Andy Bradford:

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 Windows-only issue.


This  is not  a  Windows-only  behavior. The  server  does  not use  any
specific IP  and in  fact uses  any (0.0.0.0) as  shown in  your netstat
output. Whereas  ui wants to be  on 127.0.0.1 to restrict  access to the
local machine  only. 127.0.0.1 is  more specific,  so your OS  allows it
(OpenBSD allows it to). There is no double-binding going on here. If you
had 10 IP addresses you could have 10 things all listening on port 8080.

If you point your browser to  127.0.0.1:8080 you'll get the UI instance.
If  you point  your browser  to 192.168.1.10:8080  (or whatever  your IP
happens to be) I imagine you'll get the server.

Andy
--
TAI64 timestamp: 4000550b1748



Thank you very much for your explanation.

From now on I'll use "http://localhost"; to display repos served by 
`fossil ui` and "http://computername"; to request from `fossil server`.


To avoid confusion in the browser (refresh a page with an URL/port that 
in the meanwhile points to another repo) I could apply clear-cut 
distinct stylings to my repos.


- Tontyna

P.S.: The mixed-up communication (aka double-bind) at work involved a 
server computer having multiple IPs. Will definitely recheck that.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Select specific changes within files

[Abilio Marques]

​​After a yesterday's email entitled “is this a crazy idea?” meant to ask
about a shim ended in a really interesting discussion about select specific
changes to files, I think we could give that idea a chance to live (just as
an idea, for the time being).

I've personally gone through times where I've needed it. And yes Mr. Hipp,
now I know about multiple check-outs, thanks for that one. Yet before that,
I knew about stash. But sometimes it was already too late to simply stash
and begin doing some other changes, as both changes were already in the
file.

That normally means a kinda complicated/frustrating/error prone process
(ok, is not the end of the world, yet, would be lovely to have an easier,
safer way) to split the two changes. I guess everyone must agree with me on
this. If you catch the need for the split early on, is a trivial thing, but
if you've gone until the end of at least one of the changes, splitting is
not that easy anymore.

So having the means to “automate” that splitting process seems to be great.
I use the word “seems”, as I've never used such a thing, so I can't
actually give an opinion on usefulness.

Neat ideas already popped. Here I copy/paste some fragments of them:

AFAIK with git staging you can select specific changes in a single file as
> well, to commit only a sub-set of changes in that file.
>


> *That* would be neat to have -- I've heard of it in git, but not explored
> it.
>


> Third, while splitting commits (where you accidentally mashed multiple
> things together that you later realize should be separated) is a very
> relevant feature
>


> 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 or worse).
>


> A stash with abilites like "git add --interactive" to stash parts within a
> file is the way to go IMO.
>


> fossil diff --tk --partial-commit (Then, an automatic "fossil stash" is
> performed where the original modified files are stored. The files left in
> the working area only contain the selected differences)
>

I personally would like a selective stash. Perhaps one where you can
selectively push some changes (then fossil could proceed to remove them
from the actual files), or selectively pop/apply some changes (but I
imagine this one could get things confusing, specially if used with apply).

I've never played with Darcs nor any other tool that provides this
functionality, except for GIT, and I started playing with that function
yesterday. It seems that GIT gives you the chance to select the changes by
editing the unified patch on your favorite text editor (I guess someone
mentioned that in his workflow for this situation, he did something
similar, but manually). More ideas on this?

What are your opinions? Is this useful? Is this powerful? What would your
approaches be?​
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] many duplicate links @ www/permutedindex.html

[Svyatoslav Mishyn]

Hello,

$ sed -ne 's/.*\"\(.*\.wiki\).*/\1/p' www/permutedindex.html | sort | wc -l
163

$ sed -ne 's/.*\"\(.*\.wiki\).*/\1/p' www/permutedindex.html | sort -u | wc -l
49

$ sed -ne 's/.*\"\(.*\.md\).*/\1/p' www/permutedindex.html | sort  | wc -l
9

$ sed -ne 's/.*\"\(.*\.md\).*/\1/p' www/permutedindex.html | sort -u | wc -l
2


-- 
http://www.juef.tk/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[tonyp]

I was about to suggest the same because I often have this situation, also.  I 
need to commit a large number of files, except one or two which are still no 
ready for commit.

I’ve been thinking about what the simplest way from a user’s point of view 
would be, and I think if in the editor that comes up for putting a commit 
comment, and all the files are listed underneath, the ability to simply put a 
minus before that file you do NOT want, or maybe just delete that line 
altogether, that would be very easy.   It also allows to verify which files get 
committed and which not at the last moment, making whatever changes in case of 
mistakes.

On the command line, an –ignore option would also be nice for the case –m is 
also supplied in which case the editor is not entered at all.

From: Abilio Marques 
Sent: Friday, March 20, 2015 2:52 AM

>I've found myself in several other situations where I want to add everything 
>except 1 or 2 files... So a commit --ignore "these files" would become handy. 
>Specially because I can continue to do "complete" commits (of different files) 
>while ignoring the same two, by repeating the command line on history, no 
>changes at all, without having to think too much each time.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[Stephan Beal]

On Fri, Mar 20, 2015 at 11:24 AM, Ramon Ribó  wrote:

> A possible workflow to do partial commits in fossil could be:
>
> - fossil diff --tk --partial-commit
>
> (A special version of fossil diff --tk appears where there is a
> checkbox in every difference)
>

A partial-file commit implies that one will commit untested code (because
it's impossible to test a partial commit). While that might be acceptable
in some projects, many would not allow it.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Convenient command for standardizing and simplifying marking a commit as a mistake.

[Stephan Beal]

On Mar 20, 2015 5:05 AM, "Henry Adisumarto" 
wrote:
>
> 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.

What about repos which use non-English branch names?

>
> ·If there is a leaf in the branch, the leaf will be closed.
>
> ·The mistaken commits will be hidden from the timeline.

i have always disliked the hiding feature.

>
> ·If any of the mistaken commits have been merged into another
branch, the mistaken commits will be backed out from the valid branches.

That implies automatically committing after backing out, which makes some
people nervous, as it amounts to checking in untested changes. There are
failure cases here, e.g. when multiple branches merge into the line which
this op would want to back something out of.

- stephan
(Sent from a mobile device, possibly from bed. Please excuse brevity,
typos, and top-posting.)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Stephan Beal]

On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques  wrote:

> I personally would like a selective stash. Perhaps one where you can
> selectively push some changes (then fossil could proceed to remove them
> from the actual files), or selectively pop/apply some changes (but I
> imagine this one could get things confusing, specially if used with apply).
> ...
> What are your opinions? Is this useful? Is this powerful? What would your
> approaches be?​
>

IMO it's inherently evil because it promotes checking in untested subsets.
Automated tests require a full, valid tree. Checking in a part of a change
may well lead to code which runs on your machine but doesn't run on remotes
(continuous integration systems or other users).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[Ramon Ribó]

> A partial-file commit implies that one will commit untested code (because
> it's impossible to test a partial commit). While that might be acceptable in
> some projects, many would not allow it.

If you read the full workflow description, there is a line with text:

- Compile and test

RR

2015-03-20 13:39 GMT+01:00 Stephan Beal :
> On Fri, Mar 20, 2015 at 11:24 AM, Ramon Ribó  wrote:
>>
>> A possible workflow to do partial commits in fossil could be:
>>
>> - fossil diff --tk --partial-commit
>>
>> (A special version of fossil diff --tk appears where there is a
>> checkbox in every difference)
>
>
> A partial-file commit implies that one will commit untested code (because
> it's impossible to test a partial commit). While that might be acceptable in
> some projects, many would not allow it.
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
> those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[Stephan Beal]

On Fri, Mar 20, 2015 at 1:45 PM, Ramon Ribó  wrote:

> > A partial-file commit implies that one will commit untested code (because
> > it's impossible to test a partial commit). While that might be
> acceptable in
> > some projects, many would not allow it.
>
> If you read the full workflow description, there is a line with text:
>
> - Compile and test
>

But how do you do that when checking in _part_ of a file? The compiler
compiles the _whole_ file.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[Ramon Ribó]

> But how do you do that when checking in _part_ of a file? The compiler
> compiles the _whole_ file.

Well, every user, depending on their group policies, will decide what
can be done and what not.

Option a) it is not allowed to commit without compiling and testing

Then, the user must be sure that the partial commit can compile

Option b) it is allowed

Then, the user do whatever he likes to.



2015-03-20 13:46 GMT+01:00 Stephan Beal :
> On Fri, Mar 20, 2015 at 1:45 PM, Ramon Ribó  wrote:
>>
>> > A partial-file commit implies that one will commit untested code
>> > (because
>> > it's impossible to test a partial commit). While that might be
>> > acceptable in
>> > some projects, many would not allow it.
>>
>> If you read the full workflow description, there is a line with text:
>>
>> - Compile and test
>
>
> But how do you do that when checking in _part_ of a file? The compiler
> compiles the _whole_ file.
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
> those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Convenient command for standardizing and simplifying marking a commit as a mistake.

[Jan Nijtmans]

2015-03-20 13:41 GMT+01:00 Stephan Beal :
>> 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:
>> ·The mistaken commits will be hidden from the timeline.
>
> i have always disliked the hiding feature.

I like the hiding feature ... ;-)   ...  but it should be used sparingly just as
shunning. It shouldn't be made too easy, otherwise people will be
more sloppy because any mistake can be corrected easily anyway.

>> ·If any of the mistaken commits have been merged into another
>> branch, the mistaken commits will be backed out from the valid branches.
>
> That implies automatically committing after backing out, which makes some
> people nervous, as it amounts to checking in untested changes. There are
> failure cases here, e.g. when multiple branches merge into the line which
> this op would want to back something out of.

Agreed. I don't think any simplification would be a good idea. Sorry!

Regards,
 Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Richard Hipp]

On 3/20/15, Stephan Beal  wrote:
> On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques 
> wrote:
>
>> I personally would like a selective stash. Perhaps one where you can
>> selectively push some changes (then fossil could proceed to remove them
>> from the actual files), or selectively pop/apply some changes (but I
>> imagine this one could get things confusing, specially if used with
>> apply).
>> ...
>> What are your opinions? Is this useful? Is this powerful? What would your
>> approaches be?​
>>
>
> IMO it's inherently evil because it promotes checking in untested subsets.
> Automated tests require a full, valid tree. Checking in a part of a change
> may well lead to code which runs on your machine but doesn't run on remotes
> (continuous integration systems or other users).
>

I agree with Stephan, except to note that some repositories do not
store code.  If you are checking in changes to text documentation,
then maybe testing is not as important and a partial commit would be
ok.

I'm still having trouble understanding how the partial commit would be
*useful*, though.
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[Luca Ferrari]

On Fri, Mar 20, 2015 at 12:22 PM, Abilio Marques  wrote:
> To put it back again in better words, the idea is to make an adaptor that
> let's existing apps (mostly IDEs) to use Fossil as another version control
> system, until they get a native plugin, but via using the existing GIT tool
> interface.
>
>

I am still not convinced this is the right way to go.
As I said, the workflow could be very different, so you are going to
convince people to use the git one, exactly as being able to edit word
files in openoffice let people to continue to use word...sometimes
things should be incompatible to force the change (please, I'm not
saying openoffice should not be able to open word documents).
Second, I don't think that it does suffice to translate from a command
line interface to another, but you have to do it at a library level
(e.g., jgit https://eclipse.org/jgit/), or the other way around (make
fossil responsive to git commands), what is your aim is not clear to
me here.

Luca
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[bch]

On Mar 20, 2015 5:39 AM, "Stephan Beal"  wrote:
>
> On Fri, Mar 20, 2015 at 11:24 AM, Ramon Ribó  wrote:
>>
>> A possible workflow to do partial commits in fossil could be:
>>
>> - fossil diff --tk --partial-commit
>>
>> (A special version of fossil diff --tk appears where there is a
>> checkbox in every difference)
>
>
> A partial-file commit implies that one will commit untested code (because
it's impossible to test a partial commit). While that might be acceptable
in some projects, many would not allow it.

I don't disagree with this, but I think ideas like this are still worth
considering. We have to trust users to Do The Right Thing for their
projects and treat them (our user-base) with respect. Facilitate rather
than mandate, where appropriate.

> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Stephan Beal]

On Fri, Mar 20, 2015 at 3:35 PM, bch  wrote:

> Can we define partial commit ?
>
> Are we talking about when I , ,  and then realize
> that I've got two features' worth of new material and would like to
> separate them so that Feature B is held back, Feature A is applied
> (and yes, tested, etc., etc) and committed, then Feature B is applied
> (tested, etc.) and committed ?
>

i was referring specifically (but in unfortunately vague terminology) to
partial-file commits. i.e. committing chunks 3 and 4 out of 7 changes in
the same file.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[bch]

Can we define partial commit ?

Are we talking about when I , ,  and then realize
that I've got two features' worth of new material and would like to
separate them so that Feature B is held back, Feature A is applied
(and yes, tested, etc., etc) and committed, then Feature B is applied
(tested, etc.) and committed ?

Or am I misunderstanding ?

-bch


On 3/20/15, Richard Hipp  wrote:
> On 3/20/15, Stephan Beal  wrote:
>> On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques 
>> wrote:
>>
>>> I personally would like a selective stash. Perhaps one where you can
>>> selectively push some changes (then fossil could proceed to remove them
>>> from the actual files), or selectively pop/apply some changes (but I
>>> imagine this one could get things confusing, specially if used with
>>> apply).
>>> ...
>>> What are your opinions? Is this useful? Is this powerful? What would your
>>> approaches be?
>>>
>>
>> IMO it's inherently evil because it promotes checking in untested subsets.
>> Automated tests require a full, valid tree. Checking in a part of a change
>> may well lead to code which runs on your machine but doesn't run on
>> remotes
>> (continuous integration systems or other users).
>>
>
> I agree with Stephan, except to note that some repositories do not
> store code.  If you are checking in changes to text documentation,
> then maybe testing is not as important and a partial commit would be
> ok.
>
> I'm still having trouble understanding how the partial commit would be
> *useful*, though.
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Abilio Marques]

Yes, that's my vision of it. I've come to several situations in which
feature A and feature B share the same file.

I then proceed to remove all the code from feature B, run the tests for the
A, pass them, then commit. Then apply back the lines from feature B,
retest, pass, and commit.

Actually in those cases, sometimes I can swap the order: first go with
feature B, as I know feature A it's not compete yet, so I "stash" the A,
proceed to B to deliver it quickly, then switch to my lower priority A.

Once I worked in a company with continuous integration, and perhaps they
were doing it wrong, but you actually committed into a specific test branch
in to get the code to be tested.

In my personal life, I do a lot of embedded code for microcontrollers, so
automated tests are not available. I test my code by hand, it seems to
pass, yet contains bugs. Even for Qt I work like that.

Another case I could use it a lot is in documents, as Richard said.
On Mar 20, 2015 10:05 AM, "bch"  wrote:

> Can we define partial commit ?
>
> Are we talking about when I , ,  and then realize
> that I've got two features' worth of new material and would like to
> separate them so that Feature B is held back, Feature A is applied
> (and yes, tested, etc., etc) and committed, then Feature B is applied
> (tested, etc.) and committed ?
>
> Or am I misunderstanding ?
>
> -bch
>
>
> On 3/20/15, Richard Hipp  wrote:
> > On 3/20/15, Stephan Beal  wrote:
> >> On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques 
> >> wrote:
> >>
> >>> I personally would like a selective stash. Perhaps one where you can
> >>> selectively push some changes (then fossil could proceed to remove them
> >>> from the actual files), or selectively pop/apply some changes (but I
> >>> imagine this one could get things confusing, specially if used with
> >>> apply).
> >>> ...
> >>> What are your opinions? Is this useful? Is this powerful? What would
> your
> >>> approaches be?
> >>>
> >>
> >> IMO it's inherently evil because it promotes checking in untested
> subsets.
> >> Automated tests require a full, valid tree. Checking in a part of a
> change
> >> may well lead to code which runs on your machine but doesn't run on
> >> remotes
> >> (continuous integration systems or other users).
> >>
> >
> > I agree with Stephan, except to note that some repositories do not
> > store code.  If you are checking in changes to text documentation,
> > then maybe testing is not as important and a partial commit would be
> > ok.
> >
> > I'm still having trouble understanding how the partial commit would be
> > *useful*, though.
> > --
> > D. Richard Hipp
> > d...@sqlite.org
> > ___
> > fossil-users mailing list
> > fossil-users@lists.fossil-scm.org
> > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> >
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Kevin Greiner]

>
> On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques 
> wrote:
> I personally would like a selective stash.


Yes, I would find selective stash save/apply useful.

But I see the dangers of partial commit of git's staging area. I admit,
I've abused that myself to commit a comment or documentation typo without
compiling or testing.


> Perhaps one where you can
> selectively push some changes (then fossil could proceed to remove them
> from the actual files), or selectively pop/apply some changes (but I
> imagine this one could get things confusing, specially if used with
> apply).


I've read that git has an interactive mode [1] that allows the user to
stage specific parts or changes within a single file. However, I've only
used Atlassian's SourceTree tool to interact with git's staging area. The
GUI makes it simple to select chunks to include or exclude.

1 -
http://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging#Staging-Patches
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] not found: master

[Gour]

Hello,

today I wanted to switch back to weechat irc client (from hexcha) since
I'm moving back from gnome to xfce and wanted to restore my old archived
config.

However, have problem opening it:

$ fossil open ~/repos/local/fossil/weechat.fossil 
not found: master

Tried to run rebuild on it, but no luck. :-(

$ fossil version --verbose
This is fossil version 1.32 [39f084cf2c] 2015-03-14 15:21:53 UTC
Compiled on Mar 15 2015 10:04:42 using gcc-4.8.3 20141208
[gcc-4_8-branch revision 218481] (64-bit)
SQLite 3.8.8 2015-02-25 14:25:31 6d132e7a22
Schema version 2015-01-24
miniz 9.1.15, loaded 9.1.15
SSL (OpenSSL 1.0.1k-fips 8 Jan 2015)
TH1_DOCS
TH1_HOOKS
JSON (API 20120713)
UNICODE_COMMAND_LINE

Any idea?


Sincerely,
Gour

-- 
Even if you are considered to be the most sinful of all sinners, 
when you are situated in the boat of transcendental knowledge 
you will be able to cross over the ocean of miseries.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] not found: master

[Stephan Beal]

On Fri, Mar 20, 2015 at 4:20 PM, Gour  wrote:

> $ fossil open ~/repos/local/fossil/weechat.fossil
> not found: master
>
> Tried to run rebuild on it, but no luck. :-(
>

Is master a branch name? (If so, it sounds like you are running that from a
current checkout on that branch?)

How about:

fossil open ...file... trunk

?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] not found: master

[Richard Hipp]

On 3/20/15, Gour  wrote:
> Hello,
>
> today I wanted to switch back to weechat irc client (from hexcha) since
> I'm moving back from gnome to xfce and wanted to restore my old archived
> config.
>
> However, have problem opening it:
>
> $ fossil open ~/repos/local/fossil/weechat.fossil
> not found: master

Wild guess:

   fossil open ~/repos/local/fossil/weechat.fossil tip




>
> Tried to run rebuild on it, but no luck. :-(
>
> $ fossil version --verbose
> This is fossil version 1.32 [39f084cf2c] 2015-03-14 15:21:53 UTC
> Compiled on Mar 15 2015 10:04:42 using gcc-4.8.3 20141208
> [gcc-4_8-branch revision 218481] (64-bit)
> SQLite 3.8.8 2015-02-25 14:25:31 6d132e7a22
> Schema version 2015-01-24
> miniz 9.1.15, loaded 9.1.15
> SSL (OpenSSL 1.0.1k-fips 8 Jan 2015)
> TH1_DOCS
> TH1_HOOKS
> JSON (API 20120713)
> UNICODE_COMMAND_LINE
>
> Any idea?
>
>
> Sincerely,
> Gour
>
> --
> Even if you are considered to be the most sinful of all sinners,
> when you are situated in the boat of transcendental knowledge
> you will be able to cross over the ocean of miseries.
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] not found: master

[Gour]

Stephan Beal  writes:

> How about:
>
> fossil open ...file... trunk

Ahh, that's result when one was fiddling with git. :-)


Sincerely,
Gour

-- 
One must deliver himself with the help of his mind, and not 
degrade himself. The mind is the friend of the conditioned soul, 
and his enemy as well.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Abilio Marques]

Let's forget the GIT staging area, I believe most of us, fossil users, have
proven that is not needed at all. Years and years committing without
staging, that proves is not needed ;)
 On Mar 20, 2015 10:51 AM, "Kevin Greiner"  wrote:

> On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques 
>> wrote:
>> I personally would like a selective stash.
>
>
> Yes, I would find selective stash save/apply useful.
>
> But I see the dangers of partial commit of git's staging area. I admit,
> I've abused that myself to commit a comment or documentation typo without
> compiling or testing.
>
>
>> Perhaps one where you can
>> selectively push some changes (then fossil could proceed to remove them
>> from the actual files), or selectively pop/apply some changes (but I
>> imagine this one could get things confusing, specially if used with
>> apply).
>
>
> I've read that git has an interactive mode [1] that allows the user to
> stage specific parts or changes within a single file. However, I've only
> used Atlassian's SourceTree tool to interact with git's staging area. The
> GUI makes it simple to select chunks to include or exclude.
>
> 1 -
> http://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging#Staging-Patches
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] SVN-fs-dump-format-version: 3 will produce unusable blobs

[Kain Abel]

Hello developers,

I've played around with a most recent version of trunk
https://www.fossil-scm.org/fossil/info/dabb08e9b31bb0b2
and I think I've found a bug in fossil's svn import feature.

Um, I'm not so skilled on the command line and hope that the translation is
some kind of understandable.

Thanks for your attention,
Kain

I hope someone can reproduce this behavior:

svnrdump dump http://mp3check.googlecode.com/svn/trunk/ -r 0:HEAD >
mp3check_v3.dump
fossil import --svn --trunk trunk/src/ mp3check_v3.fos mp3check_v3.dump
fossil ui mp3check_v3.fos
http://localhost:8080/finfo?name=mp3check.1
binary file (aka blob)
vs.
https://code.google.com/p/mp3check/source/browse/trunk/src/mp3check.1

svnadmin create mp3check
svnadmin load mp3check < mp3check_v3.dump
svnadmin dump mp3check -r 0:HEAD > mp3check_v2.dump
fossil import --svn --trunk trunk/src/ mp3check_v2.fos mp3check_v2.dump
fossil ui mp3check_v2.fos
http://localhost:8080/finfo?name=mp3check.1
... looks fine as txt file.


---
This is fossil version 1.32 [dabb08e9b3] 2015-03-19 21:54:15 UTC
Compiled on Mar 20 2015 05:46:38 using msc-18.00 (32-bit)
SQLite 3.8.9 2015-03-09 10:40:48 e5da5e7d5d
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.2a 19 Mar 2015)
JSON (API 20120713)
UNICODE_COMMAND_LINE

[[ Result from tester.tcl:
* Failures: merge-utf-27-23 merge-utf-27-32 merge_multi-4
merge_renames-5
th1-setting-5 th1-setting-6 th1-checkout-1 th1-checkout-2 th1-header-2
th1-footer-2 th1-footer-3 th1-artifact-3 th1-artifact-5 th1-artifact-7
th1-artifact-9 th1-globalState-1 th1-globalState-8
]]


svnrdump, version 1.8.11 (r1643975)
   compiled Dec 17 2014, 21:04:03 on x86-microsoft-windows

Copyright (C) 2014 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using
serf.
  - using serf 1.3.8
  - handles 'http' scheme
  - handles 'https' scheme



svnadmin, version 1.8.11 (r1643975)
   compiled Dec 17 2014, 21:04:03 on x86-microsoft-windows

Copyright (C) 2014 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository back-end (FS) modules are available:

* fs_fs : Module for working with a plain file (FSFS) repository.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Luca Ferrari]

On Fri, Mar 20, 2015 at 2:02 PM, Richard Hipp  wrote:
> I agree with Stephan, except to note that some repositories do not
> store code.  If you are checking in changes to text documentation,
> then maybe testing is not as important and a partial commit would be
> ok.
>

I believe it can be evil even in this scenario.
Isolation, in my opinion, must be achieved with branches. And
"complete" commits, as opposed to partial ones, should be done with
merges.
I believe I'm totally misunderstanding, but used to do very small
commits, it does not make much sense to have "partial" commits. Or at
least, I cannot see how my workflow would be better using them.
Moreover, I believe that partial commits, in the form I understand
from this thread, will call for a continuos amend/rebase (are you sure
you will never miss a line in a partial commit?).

Luca
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[bch]

I'm still confused about what "complete" or "split" means in the
contexts that I think people are using this --

If I accidentally code two different logical thoughts into a single
file -- and so they are "combined", and uncommitted -- why would tools
or facilities to aid making-discrete two different logical ideas be
discouraged, and what precludes testing this separated code ?

-bch


On 3/20/15, Luca Ferrari  wrote:
> On Fri, Mar 20, 2015 at 2:02 PM, Richard Hipp  wrote:
>> I agree with Stephan, except to note that some repositories do not
>> store code.  If you are checking in changes to text documentation,
>> then maybe testing is not as important and a partial commit would be
>> ok.
>>
>
> I believe it can be evil even in this scenario.
> Isolation, in my opinion, must be achieved with branches. And
> "complete" commits, as opposed to partial ones, should be done with
> merges.
> I believe I'm totally misunderstanding, but used to do very small
> commits, it does not make much sense to have "partial" commits. Or at
> least, I cannot see how my workflow would be better using them.
> Moreover, I believe that partial commits, in the form I understand
> from this thread, will call for a continuos amend/rebase (are you sure
> you will never miss a line in a partial commit?).
>
> Luca
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Scott Robison]

On Fri, Mar 20, 2015 at 5:56 AM, Abilio Marques  wrote:

> Neat ideas already popped. Here I copy/paste some fragments of them:
>
> fossil diff --tk --partial-commit (Then, an automatic "fossil stash" is
>> performed where the original modified files are stored. The files left in
>> the working area only contain the selected differences)
>>
>
> I personally would like a selective stash. Perhaps one where you can
> selectively push some changes (then fossil could proceed to remove them
> from the actual files), or selectively pop/apply some changes (but I
> imagine this one could get things confusing, specially if used with apply).
>

Here is the problem with an interactive partial-commit that I see. But
first some history:

A couple days ago I was convinced I'd found a bug in the merge conflict
code. I hadn't, but was confused by a merge conflict in a file where the
exact same line was missing (correctly) from two of the three portions of
the merge conflict in the source file.

I experimented with some changes to try to make things more clear for
future me by having the merge conflict include more history. In my one
specific test case, it was helpful, but I quickly realized that:

- What if the "missing context" came at the beginning of a merge conflict
instead of at the end of the merge conflict? By the point fossil identifies
the lines that are part of the merge conflict we've already passed up
potentially deleted history and it would be quite complex to backup. Not
impossible, but very complex.

- What if the missing historical context at the end of the merge conflict
was more than one line? How to know how much extra history is needed for
this one exact file, where this file could be C source, or README, or XML,
or JSON, or C++, or any other form of text file?

- What if the missing historical context isn't even needed (which is
probably often the case)? In that case adding even an extra line could
confuse the issue just as much as the missing extra line was confusing me.

Note: In my case the missing line was #endif which would have left the
merge non-buildable if I only used the merge conflict info to resolve the
conflict.

I realized that there is no right answer to those questions. The point of
the merge conflict is that there was a conflict and a human had to make a
decision and all it could do is provide me what it knew about the state of
the merge. It is up to the human to take whatever additional remedial tasks
(such as diffing baseline against each copy and whatever other analysis is
needed).

Okay, sorry for that. There is a point, though. An ability to selectively
commit just portions of a file implies an ability to differentiate which
pieces are needed where. A human can do this. If the idea above (fossil
diff --tk --partial-commit) is to allow individual blocks of changes to be
selected, then it is too coarse grained for all situations. If it has
checkboxes on every changed line, then it might be adequate. Nope, scratch
that, it is possible that two changes could impact the same line in
different ways, so even a line by line set of checkboxes would be too
coarse grained. How about a word by word set of checkboxes? Character by
character? These changes could be anything, source code, documentation,
data files, html, css, javascript, C, etc, etc. Whatever solution is
implemented needs to accommodate all of them, and others not yet mentioned
or imagined. If the diff model proposed accommodates all these potential
variations, what has been invented is essentially a text editor.

I am sympathetic to the idea that you don't *intend* to jumble up changes
in a single set of edits and only realize after the fact that you've
accomplished exactly that, and thus you want a way to extract the changes
into two separate commits / branches / whatever. I think the git model is
only appealing at this point because it allows you to rewrite history. You
can commit anything you want to a git repo without trepidation because you
can always modify it, rebase it, delete it, whatever you want. This doesn't
work with fossil due to the immutable history functionality, which is a
feature.

The fossil version of this workflow would be something along the lines of:

1. You've opened a repo into work area A.

2. You've gone along happily editing for whatever period of time only to
realize "dang, I mixed up these two things, I need to separate them".

3. You make a copy of the entire work area A as work area B (perhaps with a
fossil open --keep, I'm not sure as I've not tried this myself).

4. In work area A you remove the parts that should only be in work area B
and test/commit.

5. In work area B you remove the parts that should only be in work area A
and test/commit.

Or alternatively:

3. You stash snapshot your current set of changes.

4. You remove one set of changes and test/commit.

5. You stash pop, remove the other set of changes and test/commit.

As I understand it, with git you'd do something like:

3. You st

Re: [fossil-users] Select specific changes within files

[Martin S. Weber]

On 2015-03-20 09:02:32, Richard Hipp wrote:
> (...)
> I'm still having trouble understanding how the partial commit would be
> *useful*, though.

Some people like their metadata (i.e. fossil's commit message log) to
match up with what they were doing in the files. You go to your file, you
begin to work on task A, something comes along, and work on task B gets
intermingled with the A changes. You wanna commit with metadata (commit
log) that clearly says A was done here, and B was done there. Often
enough, it's easy to halt before starting on B, commit (or stash),
go on to B, etc.

Also, ideally you're working in a flow anyways (the deep meditative
state where stuff gets done (tm)); doing housekeeping (stashing here
and there; grouping related changes to single commits so that you can
cleanly test them / undo them as a human without the need for tools such
as unit-testing combined with fossil bisect) is a safe way to kill any
meditative effort (except for real housekeeping, obviously meditative
in itself). So you end up with intermingled changes which one would
like to split cleanly.

But fossil is not git, you can't tear your history apart.So you have to
make sure the right history gets recorded (forever) in the first place. 
And we're back at partial committing with usefulness.

Regards,
-Martin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Scott Robison]

On Fri, Mar 20, 2015 at 10:26 AM, bch  wrote:

> I'm still confused about what "complete" or "split" means in the
> contexts that I think people are using this --
>
> If I accidentally code two different logical thoughts into a single
> file -- and so they are "combined", and uncommitted -- why would tools
> or facilities to aid making-discrete two different logical ideas be
> discouraged, and what precludes testing this separated code ?
>

I think the problem is not everyone is using "test" exactly the same way.
If you are talking about automated testing, it can only happen after
committing code. If you are talking about developer testing, yes, you can
test code after committing it, but ideally you've made changes, tested
them, then committed. The staging mechanism seems to require you to make a
commit before testing. With git, not so bad. You can rewrite history as
much as you want until you're satisfied. With fossil, this doesn't work.
Except that it can work in a similarly functional way (yet less confusing
from my perspective) as I outlined in my previous email.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Richard Hipp]

On 3/20/15, Martin S. Weber  wrote:
> On 2015-03-20 09:02:32, Richard Hipp wrote:
>> (...)
>> I'm still having trouble understanding how the partial commit would be
>> *useful*, though.
>
>
> Also, ideally you're working in a flow anyways (the deep meditative
> state where stuff gets done (tm)); doing housekeeping (stashing here
> and there; grouping related changes to single commits so that you can
> cleanly test them / undo them as a human without the need for tools such
> as unit-testing combined with fossil bisect) is a safe way to kill any
> meditative effort (except for real housekeeping, obviously meditative
> in itself). So you end up with intermingled changes which one would
> like to split cleanly.
>

The way I deal with this in SQLite is:

(1) Make logically separate changes in separate check-outs so that
they are easy to test and commit separately.  A real-life example of
this can be seen at https://www.sqlite.org/src/timeline?c=08958f57 - I
was working on the stat4-function branch when I noticed that an
unrelated comment needed to be cleaned up, so I checked in the comment
fix separately, then continued merrily working away on stat4-function.

(2) On the occasions when I mess up and accidentally put unrelated
changes into the same check-out, I have been known to stash the whole
thing, then reapply one set of changes, test, commit, then reapply the
other set of changes, test, and commit again.

(3) You might also check-in the whole thing into a side branch, then
do multiple partial merges back into the branch you were working on,
with appropriate comments on each merge.  (To do the partial merge,
you merge the whole change, then back out the parts that you don't
want for the current partial merge, test and commit, then repeat.
Copy/Paste from "fossil diff --tk" gets this done rather efficiently,
in my experience.)

You can argument that (2) might have been easier with a partial
commit.  Maybe so; maybe a little easier, but not a huge amount
easier.  And I would have had to skip the testing step, which might
have caused problems in the future such that the total effort (effort
to commit plus effort to fix problems caused by the untested commit)
is greater than the effort of applying procedure (2) as written.

So one can argue that partial commit might save you (a little) effort
today, but will end up requiring more work in the long-term.

Still, there will always be people who are convinced that there is
nothing that can go wrong and what to do a partial commit against
expert advise.  And I am not opposed to providing some reasonable
support for that in Fossil.  But there needs to be a balance.  We
shouldn't waste too much time implementing that capability when there
are other more useful features that could be added instead, and the
mechanism should not get in the way of people who don't want to use it
or even know about it, and it shouldn't be so easy as to encourage
people to use it to their harm.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Ron W]

On Fri, Mar 20, 2015 at 7:56 AM, Abilio Marques  wrote:

> Yet before that, I knew about stash. But sometimes it was already too late
> to simply stash and begin doing some other changes, as both changes were
> already in the file.
>

Never too late to stash. If I decide I need to split out changes already
made, I stash the files, then do "fossil stash gdiff" to selectively (re)
apply the stashed changes, then build/test/commit. Then "fossil stash
gdiff" to apply more of the changes, then build/test/commit. Repeat until
all need changes are done. If I think I might later need what I stashed, I
can restore it and commit to an appropriate branch.

If anything, using the staging area for partial commits just makes it
harder to build and test before committing.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Marcel Graf]

On Fri, Mar 20, 2015 at 6:04 PM, Richard Hipp  wrote:

> On 3/20/15, Martin S. Weber  wrote:
> ...

> in itself). So you end up with intermingled changes which one would
> > like to split cleanly.
> >
> The way I deal with this in SQLite is:
> ...

(2) On the occasions when I mess up and accidentally put unrelated
> changes into the same check-out, I have been known to stash the whole
> thing, then reapply one set of changes, test, commit, then reapply the
> other set of changes, test, and commit again.


This (2) might be easier with something like a
"partial/selective/interactive stash" as mentioned by the OP in the bottom
part of his email.
So (2a) would look like: selectively stash the "second" set of changes,
test (thus including the "first" set of changes), commit, stash pop/apply
"second", test, commit

Imho, the "missing piece" would be "stash" having means to do partial
stashing (finer than on file-by-file base). This the would allow to do
these "splittings of a mixed up check-outs" a bit easier (including testing
"before" committing, no need for "partial commit" then), wouldn't it?

Regards
Marcel
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Martin S. Weber]

On 2015-03-20 13:04:44, Richard Hipp wrote:
> (...)
> The way I deal with this in SQLite is:
> 
> (1) Make logically separate changes in separate check-outs so that
> they are easy to test and commit separately.  (...)

That's the sort of flow-interrupting context switch I was referring to
on one hand, for myself; I see the usefulness of this approach, also it's
very KISS. I like it. I usually do not treat checkouts as transient as
this implies, but there's nothing wrong with doing that, considered it
does not interrupt you. Maybe having it in mind won't interrupt me next
time I stumble over it, I'll wait and see.

> (2) On the occasions when I mess up and accidentally put (...)

That's the sort of thing that one can do after the fact, i.e., when
the housekeeping portion after the productivity burst is coming to
take a breather... see more below.

> (3) You might also check-in the whole thing into a side branch, then
> do multiple partial merges back into the branch you were (...)

I can see one doing this when they approach their checkout with a
plan they know will create mess. It's good advice.

I think in combination, your three approaches actually cover the use-cases
I have, when I'm considering the topic of partial commits.  I suppose the
process of (2) and a partial commit selection would be actually end up
being quite similar (in (2) you have more (visual) context but you make 
the same choices for the most part, i.e., select this, ignore that, ...)

Partial commits would offer a line of "defense", of cleaning up and 
associating metadata with changes. (2) fulfills this role just as well.
(1) is good reminder/advice for when the opening is quick. People
should be doing (3) for messy stuff anyways :)

> Still, there will always be people who are convinced that there is
> nothing that can go wrong and what to do a partial commit against
> expert advise.  

I wanted to showcase the potential usefulness of the feature. You're
saying you got me covered already. After some consideration I think
I agree. So no need for me to ask for and rely on yet-unwritten code.

Thanks,

-Martin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Ron W]

On Fri, Mar 20, 2015 at 1:30 PM, Marcel Graf 
wrote:

> On Fri, Mar 20, 2015 at 6:04 PM, Richard Hipp  wrote:
>
>> On 3/20/15, Martin S. Weber  wrote:
>> ...
>
> > in itself). So you end up with intermingled changes which one would
>> > like to split cleanly.
>> >
>> The way I deal with this in SQLite is:
>> ...
>
> (2) On the occasions when I mess up and accidentally put unrelated
>> changes into the same check-out, I have been known to stash the whole
>> thing, then reapply one set of changes, test, commit, then reapply the
>> other set of changes, test, and commit again.
>
>
> This (2) might be easier with something like a
> "partial/selective/interactive stash" as mentioned by the OP in the bottom
> part of his email.
> So (2a) would look like: selectively stash the "second" set of changes,
> test (thus including the "first" set of changes), commit, stash pop/apply
> "second", test, commit
>

I suppose this would make sense if there are fewer changes to "undo" in the
edited code than to "re do" in the reverted code.

You can achieve the same result with "fossil snapshot" (which skips the
automatic revert), then "fossil gdiff" to selectively "undo" changes. Then
edit/build/test/commit what remains. After that, "fossil stash gdiff" to
selectively re-apply more changes. Repeat as needed
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[bch]

On 3/20/15, Richard Hipp  wrote:
> On 3/20/15, Martin S. Weber  wrote:
>> On 2015-03-20 09:02:32, Richard Hipp wrote:
>>> (...)
>>> I'm still having trouble understanding how the partial commit would be
>>> *useful*, though.
>>
>>
>> Also, ideally you're working in a flow anyways (the deep meditative
>> state where stuff gets done (tm)); doing housekeeping (stashing here
>> and there; grouping related changes to single commits so that you can
>> cleanly test them / undo them as a human without the need for tools such
>> as unit-testing combined with fossil bisect) is a safe way to kill any
>> meditative effort (except for real housekeeping, obviously meditative
>> in itself). So you end up with intermingled changes which one would
>> like to split cleanly.
>>
>
> The way I deal with this in SQLite is:
>
> (1) Make logically separate changes in separate check-outs so that
> they are easy to test and commit separately.  A real-life example of
> this can be seen at https://www.sqlite.org/src/timeline?c=08958f57 - I
> was working on the stat4-function branch when I noticed that an
> unrelated comment needed to be cleaned up, so I checked in the comment
> fix separately, then continued merrily working away on stat4-function.
>
> (2) On the occasions when I mess up and accidentally put unrelated
> changes into the same check-out, I have been known to stash the whole
> thing, then reapply one set of changes, test, commit, then reapply the
> other set of changes, test, and commit again.
>
> (3) You might also check-in the whole thing into a side branch, then
> do multiple partial merges back into the branch you were working on,
> with appropriate comments on each merge.  (To do the partial merge,
> you merge the whole change, then back out the parts that you don't
> want for the current partial merge, test and commit, then repeat.
> Copy/Paste from "fossil diff --tk" gets this done rather efficiently,
> in my experience.)
>
> You can argument that (2) might have been easier with a partial
> commit.  Maybe so; maybe a little easier, but not a huge amount
> easier.  And I would have had to skip the testing step, which might
> have caused problems in the future such that the total effort (effort
> to commit plus effort to fix problems caused by the untested commit)
> is greater than the effort of applying procedure (2) as written.
>
> So one can argue that partial commit might save you (a little) effort
> today, but will end up requiring more work in the long-term.
>
> Still, there will always be people who are convinced that there is
> nothing that can go wrong and what to do a partial commit against
> expert advise.

 I'm interested in exploring the idea of supporting some way to do
"split commits",  where two logical ideas end up in the same file in
the same checkout, but to characterize that as "convinced that there
is nothing that can go wrong" is disengenuous.

What I've done so far is use the stash in an [diff]/[apply]/[pop]
manner and hand-adjust patches. I've had good luck w/ the robustness
of the final [pop] against patched code, and the "depth" of my mistake
(a missed commit for a logical code change) has been relatively
shallow to date.

I wonder (off the top of my head): is there such a thing as a diff
that has a range, either explicit or logical ? Example:

$ fossil stash save -m 'thought 1' ./mfile -start 20 -end 80
$ fossil stash save -m 'thoght 2' ./mfile -start 90
$ fossil stash pop; fossil ci -m 'my cool feature "thought 2"'
$ fossil stash pop; fossil ci -m 'my other feature "thought 1"'



> And I am not opposed to providing some reasonable
> support for that in Fossil.  But there needs to be a balance.  We
> shouldn't waste too much time implementing that capability when there
> are other more useful features that could be added instead, and the
> mechanism should not get in the way of people who don't want to use it
> or even know about it, and it shouldn't be so easy as to encourage
> people to use it to their harm.
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[org.fossil-scm.fossil-users]

On 2015-03-20T07:26:53 -0430
Abilio Marques  wrote:

> I personally would like a selective stash.

This seems like the best of all worlds: You get the clean separate
commits typical of git, but with each of those commits actually
compiled and tested.

I tried to put this together ages ago by producing a single diff
from the stash and then interactively patching using some 3rd-party GUI
patch tools, but it never really worked out (due to the 3rd-party tools
not really doing it very well).

It's basically the logic from git add --patch but working in reverse:
Take a large diff, interactively split it into chunks and optionally
apply some of the chunks. Compile. Test. Commit. Repeat until there are
no chunks left.

M
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Reimer Behrends]

Stephan Beal wrote:

On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques mailto:abili...@gmail.com>> wrote:

I personally would like a selective stash. Perhaps one where you can
selectively push some changes (then fossil could proceed to remove
them from the actual files), or selectively pop/apply some changes
(but I imagine this one could get things confusing, specially if
used with apply).
...
What are your opinions? Is this useful? Is this powerful? What would
your approaches be?​


IMO it's inherently evil because it promotes checking in untested
subsets. Automated tests require a full, valid tree. Checking in a part
of a change may well lead to code which runs on your machine but doesn't
run on remotes (continuous integration systems or other users).


A selective stash does not have these problems, since you're only 
removing files from the working tree; it does not change the repository, 
until you actually perform a (non-selective) commit.


Second, there are ways to do selective commits without the above 
problems (assuming you find the feature desirable and worth the effort 
of implementing it).


Give the commit command three subcommands:

fossil commit --tentative
fossil commit --amend
fossil commit --finalize

Here, `fossil commit --tentative` will begin a tentative commit. Such a 
commit cannot be exported from the repository (via push, bundle, etc.), 
but can be diffed against, viewed, etc. Then, `fossil commit --amend` 
can change the commit by adding files or individual hunks to it or 
removing them. Finally, once you're satisfied, you can use `fossil 
commit --finalize` to turn the tentative commit into a regular one 
(presumably after stashing all remaining changes and testing the 
commit). You can even be strict and require that the tree be clean for 
`fossil commit --finalize` to be permitted.


(Note: This is essentially a greatly simplified version of how Mercurial 
Queues work.)


Such an approach should fix most of the issues with the Git staging 
area, while retaining all its power; the main downside is that it adds a 
lot of potential complexity to `commit`, while a selective stash (and 
selective `stash apply`) would be equally powerful and much simpler to 
implement, understand, and teach. (Note: Bzr uses selective stash -- 
called shelve -- and full commits by default, and to good effect.)


Reimer Behrends
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Abilio Marques]

Ok, in an attempt to provide a short example:

The code is working, I have tests, yet I don't test for memory leaks.
That's my current scenario. A code snippet follows:

void functionA() {
char *thisWillLeak;
...
thisWillLeak = malloc(1024);
...
// never free nor return the memory
}

void functionB() {
functionA();
}


Then I start to work in a new feature, and I add 10 functions (I will only
show one here).
void functionA() {
char *thisWillLeak;
...
thisWillLeak = malloc(1024);
...
// never free nor return the memory
}

void functionB() {
functionA();
}

void functionC() {
for (i = 0; i < 12000; i++) {
functionA();
}
}

When I run the code it crashes (as it's running on a device with 8Mb of
RAM). I check the why... and I discover that thisWillLeak was never freed.
I'm busy working, so I accidentally add the free in the middle of my work
day, and continue to work on my new feature.

Today is a code freeze, and even when my new feature is not going to be
included, as is not complete, 4 hours later I think "hum, that memory leak
made my software crash because it tried to make 12000 allocations... but in
real life, if functionB, which runs every 5 minutes, gets called around
8192 times, it will surely make the system crash too, so that bug would be
a nasty one given less than a month"

So including that patch right now seems really important. But I have a mix
between the patch and the unfinished (and also untested).

Until yesterday, what did I do?

fossil stash snapshot
go to the editor, find the lines that I want to remove (all the ones from
the new feature), remove them.
test
commit
fossil stash pop

continue working as usual.

But there has also been times where I was working in some document (I use
LaTeX from time to time).

So I have a partial document on the repo. I continue committing every time
I add a new section. I'm in the middle of a section, and some friend kindly
pass by my computer and reads the document directly from the screen. Finds
a typo... I edit it right there (I'm not going to tell him... wait while I
go to the terminal and stash my current work so we can fix the typo,
normally I even forget I can do it while I'm doing the work all by
myself)... then after I finish the section, I do:

fossil diff

just to discover... ouch, I have this uncommitted typo fix too... I don't
want to commit both changes at once... so I need to go and repeat something
close to the previously described workflow.


The change in the first example (only adding a line with a free) seems
trivial, but sometimes there is more than 1 line involved and they are not
all together. Sometimes both the fix and the new feature are completely
independent, ie: instead of a leak, I find a way to rewrite 20 lines of
code, all scattered around, that make functionA a lot more efficient in
execution time than the actual code.

As functionC calls it 12000 times... improving speed execution of functionA
will reduce the time I must spend waiting for the test of functionC ends
(which I run several times as the new feature gets completed). So I
replaced it in the heat of the moment,without stashing... first commented
the line that uses functionC ran the program, worked faster... got happy,
I'll go to bed earlier, uncommented the call functionC and continue to
work...

At the end, I do a fossil diff... and I get the picture... both the speed
improvement idea and the new feature are mixed together...

I can proceed to stash either the speed improvement code or the new
feature, test the one that is not stashed, commit it after I'm happy, pop
the remaining code, and keep going.


Please forgive me if these examples seem trivial or too specific. I tried
to put 3 ones that come to my mind right now.


To finish the idea, I will use another example (this time generic).

touch a.txt
fossil ci -m "a is empty"
fossil add a.txt
echo "dog" >> a.txt
echo "cat" >> a.txt
echo "parrot" >> a.txt
echo "house" >> a.txt
echo "car" >> a.txt
fossil diff

I get
Index: a.txt
==
--- a.txt
+++ a.txt
@@ -0,0 +1,4 @@
+dog
+cat
+parrot
+house
+car


I discover that the animals, even when it should go into that file,
shouldn't go in the first commit). So I do:

fossil stash save --selectively -m "This stash removes the animals"

Somehow this (perhaps on the same way git does the add --edit, by opening a
text editor with the diff) let me deselect the lines that say "house" and
"car"... and bang. The commit can proceed only with house and car... then I
do fossil pop... that inlcudes the animals... and I can commit again, the
final version of the file.


The main question remains... is there a way to do that "selectively" thing.
Would stash the best place to add it. Is is possible to do so? And the most
important one... does it seem useful for a lot of people?

On Fri, Mar 20, 2015 at 1:05 PM, Martin S. Weber  wrote:

> On 2015-03-20 13:04:44, Richard Hipp w

Re: [fossil-users] Is this a crazy idea?

[paul]

On 20/03/15 08:16, Peter Spjuth wrote:


On Fri, Mar 20, 2015 at 5:38 AM, Reimer Behrends > wrote:


First, the safer (and arguably overall better) approach is to
recognize that stash/shelve operations are the inverse of the
staging area for this purpose. I.e., rather than stage a partial
commit, you stash everything but the partial commit, then commit
whatever changes remain in toto. This does not require the staging
area and ensures that, e.g., you're not committing something that
doesn't even compile (which breaks bisect, CI tools, etc.).

This is exactly my viewpoint. A work a lot in Subversion and I often 
miss a stash, never a staging area.
I have used git's staging area as intended occasionally but mostly I 
find it annoying. I feel slighty dirty
when I do a partial commit since I know it is, in theory at least, 
untested.
A stash with abilites like "git add --interactive" to stash parts 
within a file is the way to go IMO.

/Peter



When I was using git and came to fossil I missed the staging area. Sometimes
when making a change I'd want to make a change to another part of the 
software

to support the change I was making, and so then ended up doing two commits.

The reason I liked the staging area was because before committing I'd always
do diff/add/status, to review changes, and have one final check that 
everthing

was OK before actually committing.

Then I would add the remaining files and do the next commit.

But as fossil can commit a subset of changes, I can still manage to do 
what I

like.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[Abilio Marques]

But sometimes the subset of files to include in the first commit is longest
than the ones to be included in the second... so perhaps something like

fossil ci -m "first commit" --ignore file1 file2

would be easier than:
fossil ci -m "first commit" file3 file4 file5 file6... file12


On Fri, Mar 20, 2015 at 2:13 PM, paul  wrote:

>  On 20/03/15 08:16, Peter Spjuth wrote:
>
>
> On Fri, Mar 20, 2015 at 5:38 AM, Reimer Behrends 
> wrote:
>
>> First, the safer (and arguably overall better) approach is to recognize
>> that stash/shelve operations are the inverse of the staging area for this
>> purpose. I.e., rather than stage a partial commit, you stash everything but
>> the partial commit, then commit whatever changes remain in toto. This does
>> not require the staging area and ensures that, e.g., you're not committing
>> something that doesn't even compile (which breaks bisect, CI tools, etc.).
>>
>
> This is exactly my viewpoint. A work a lot in Subversion and I often miss
> a stash, never a staging area.
> I have used git's staging area as intended occasionally but mostly I find
> it annoying. I feel slighty dirty
> when I do a partial commit since I know it is, in theory at least,
> untested.
>
> A stash with abilites like "git add --interactive" to stash parts within a
> file is the way to go IMO.
>
> /Peter
>
>
>
>
> When I was using git and came to fossil I missed the staging area.
> Sometimes
> when making a change I'd want to make a change to another part of the
> software
> to support the change I was making, and so then ended up doing two commits.
>
> The reason I liked the staging area was because before committing I'd
> always
> do diff/add/status, to review changes, and have one final check that
> everthing
> was OK before actually committing.
>
> Then I would add the remaining files and do the next commit.
>
> But as fossil can commit a subset of changes, I can still manage to do
> what I
> like.
>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] many duplicate links @ www/permutedindex.html

[Andy Goth]

On 3/20/2015 6:59 AM, Svyatoslav Mishyn wrote:
> $ sed -ne 's/.*\"\(.*\.wiki\).*/\1/p' www/permutedindex.html | sort | wc -l
> 163
> 
> $ sed -ne 's/.*\"\(.*\.wiki\).*/\1/p' www/permutedindex.html | sort -u | wc -l
> 49
> 
> $ sed -ne 's/.*\"\(.*\.md\).*/\1/p' www/permutedindex.html | sort  | wc -l
> 9
> 
> $ sed -ne 's/.*\"\(.*\.md\).*/\1/p' www/permutedindex.html | sort -u | wc -l
> 2

This is intentional.  A permuted index provides many links to the same
documents, permuting the name each time.

For example, a document titled "hello world" will be linked from "hello
world" and "world — hello".

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[Richard Hipp]

On 3/20/15, Abilio Marques  wrote:
> But sometimes the subset of files to include in the first commit is longest
> than the ones to be included in the second... so perhaps something like
>
> fossil ci -m "first commit" --ignore file1 file2

I have your request.  In the meantime, consider this work-around:

fossil stash save file1 file2
# test
fossil ci -m "first commit"
fossil stash pop

>
> would be easier than:
> fossil ci -m "first commit" file3 file4 file5 file6... file12
>
>
> On Fri, Mar 20, 2015 at 2:13 PM, paul  wrote:
>
>>  On 20/03/15 08:16, Peter Spjuth wrote:
>>
>>
>> On Fri, Mar 20, 2015 at 5:38 AM, Reimer Behrends 
>> wrote:
>>
>>> First, the safer (and arguably overall better) approach is to recognize
>>> that stash/shelve operations are the inverse of the staging area for
>>> this
>>> purpose. I.e., rather than stage a partial commit, you stash everything
>>> but
>>> the partial commit, then commit whatever changes remain in toto. This
>>> does
>>> not require the staging area and ensures that, e.g., you're not
>>> committing
>>> something that doesn't even compile (which breaks bisect, CI tools,
>>> etc.).
>>>
>>
>> This is exactly my viewpoint. A work a lot in Subversion and I often miss
>> a stash, never a staging area.
>> I have used git's staging area as intended occasionally but mostly I find
>> it annoying. I feel slighty dirty
>> when I do a partial commit since I know it is, in theory at least,
>> untested.
>>
>> A stash with abilites like "git add --interactive" to stash parts within
>> a
>> file is the way to go IMO.
>>
>> /Peter
>>
>>
>>
>>
>> When I was using git and came to fossil I missed the staging area.
>> Sometimes
>> when making a change I'd want to make a change to another part of the
>> software
>> to support the change I was making, and so then ended up doing two
>> commits.
>>
>> The reason I liked the staging area was because before committing I'd
>> always
>> do diff/add/status, to review changes, and have one final check that
>> everthing
>> was OK before actually committing.
>>
>> Then I would add the remaining files and do the next commit.
>>
>> But as fossil can commit a subset of changes, I can still manage to do
>> what I
>> like.
>>
>>
>>
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[paul]

Maybe. But after Peter's comment,  perhaps that way of working shouldn't 
be encouraged

anyway, despite not breaking anything doing this sort of thing, yet ...


On 20/03/15 18:49, Abilio Marques wrote:
But sometimes the subset of files to include in the first commit is 
longest than the ones to be included in the second... so perhaps 
something like


fossil ci -m "first commit" --ignore file1 file2

would be easier than:
fossil ci -m "first commit" file3 file4 file5 file6... file12


On Fri, Mar 20, 2015 at 2:13 PM, paul > wrote:


On 20/03/15 08:16, Peter Spjuth wrote:


On Fri, Mar 20, 2015 at 5:38 AM, Reimer Behrends
mailto:behre...@gmail.com>> wrote:

First, the safer (and arguably overall better) approach is to
recognize that stash/shelve operations are the inverse of the
staging area for this purpose. I.e., rather than stage a
partial commit, you stash everything but the partial commit,
then commit whatever changes remain in toto. This does not
require the staging area and ensures that, e.g., you're not
committing something that doesn't even compile (which breaks
bisect, CI tools, etc.).

This is exactly my viewpoint. A work a lot in Subversion and I
often miss a stash, never a staging area.
I have used git's staging area as intended occasionally but
mostly I find it annoying. I feel slighty dirty
when I do a partial commit since I know it is, in theory at
least, untested.
A stash with abilites like "git add --interactive" to stash parts
within a file is the way to go IMO.
/Peter



When I was using git and came to fossil I missed the staging area.
Sometimes
when making a change I'd want to make a change to another part of
the software
to support the change I was making, and so then ended up doing two
commits.

The reason I liked the staging area was because before committing
I'd always
do diff/add/status, to review changes, and have one final check
that everthing
was OK before actually committing.

Then I would add the remaining files and do the next commit.

But as fossil can commit a subset of changes, I can still manage
to do what I
like.



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org

http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Ron W]

On Fri, Mar 20, 2015 at 2:28 PM, Abilio Marques  wrote:

>
> So including that patch right now seems really important. But I have a mix
> between the patch and the unfinished (and also untested).
>
> Until yesterday, what did I do?
>
> fossil stash snapshot
> go to the editor, find the lines that I want to remove (all the ones from
> the new feature), remove them.
> test
> commit
> fossil stash pop
>

Since your patch is a smaller amount of code, what I might do is:

fossil stash save  # files will be
automatically reverted
fossil stash gdiff  fileWithPatch.c   # find line(s) with patch and
apply to working copy
build
# test
fossil ci -m 'Fix memory leak'

Same end result with less work.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[Ron W]

On Fri, Mar 20, 2015 at 2:55 PM, Richard Hipp  wrote:

> On 3/20/15, Abilio Marques  wrote:
> > fossil ci -m "first commit" --ignore file1 file2
>
> I have your request.  In the meantime, consider this work-around:
>
> fossil stash save file1 file2
> # test
> fossil ci -m "first commit"
> fossil stash pop


I see this as a safer way to do partial commits.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[Abilio Marques]

Yeah, stash is the way I do all the time, but sometimes I want to exclude
binaries that are regenerated each time a change and compilation occurs,
until I'm ready to the new version to go into trunk.

Top of my mind, the PDF files that are generated when I use LaTeX. I want
to keep the stable version in trunk, yet avoid including binaries that are
sometimes hundreds of Kbytes each commit to my "this is just a test"
branch, or "this is a modification in progress" branch. I would have to
stash the PDFs before each commit (and they are not useful anyway) or type
down the entire list of files that I want to include on each commit, which
are different each time.

But by doung fossil ci --ignore file1.pdf file2.pdf -m "here is an
example", I can reuse that command 15 times without using the brain harder
than a normal "complete" commit will ask me for, until I'm ready to go to
the trunk.





On Fri, Mar 20, 2015 at 2:25 PM, Richard Hipp  wrote:

> On 3/20/15, Abilio Marques  wrote:
> > But sometimes the subset of files to include in the first commit is
> longest
> > than the ones to be included in the second... so perhaps something like
> >
> > fossil ci -m "first commit" --ignore file1 file2
>
> I have your request.  In the meantime, consider this work-around:
>
> fossil stash save file1 file2
> # test
> fossil ci -m "first commit"
> fossil stash pop
>
> >
> > would be easier than:
> > fossil ci -m "first commit" file3 file4 file5 file6... file12
> >
> >
> > On Fri, Mar 20, 2015 at 2:13 PM, paul  wrote:
> >
> >>  On 20/03/15 08:16, Peter Spjuth wrote:
> >>
> >>
> >> On Fri, Mar 20, 2015 at 5:38 AM, Reimer Behrends 
> >> wrote:
> >>
> >>> First, the safer (and arguably overall better) approach is to recognize
> >>> that stash/shelve operations are the inverse of the staging area for
> >>> this
> >>> purpose. I.e., rather than stage a partial commit, you stash everything
> >>> but
> >>> the partial commit, then commit whatever changes remain in toto. This
> >>> does
> >>> not require the staging area and ensures that, e.g., you're not
> >>> committing
> >>> something that doesn't even compile (which breaks bisect, CI tools,
> >>> etc.).
> >>>
> >>
> >> This is exactly my viewpoint. A work a lot in Subversion and I often
> miss
> >> a stash, never a staging area.
> >> I have used git's staging area as intended occasionally but mostly I
> find
> >> it annoying. I feel slighty dirty
> >> when I do a partial commit since I know it is, in theory at least,
> >> untested.
> >>
> >> A stash with abilites like "git add --interactive" to stash parts within
> >> a
> >> file is the way to go IMO.
> >>
> >> /Peter
> >>
> >>
> >>
> >>
> >> When I was using git and came to fossil I missed the staging area.
> >> Sometimes
> >> when making a change I'd want to make a change to another part of the
> >> software
> >> to support the change I was making, and so then ended up doing two
> >> commits.
> >>
> >> The reason I liked the staging area was because before committing I'd
> >> always
> >> do diff/add/status, to review changes, and have one final check that
> >> everthing
> >> was OK before actually committing.
> >>
> >> Then I would add the remaining files and do the next commit.
> >>
> >> But as fossil can commit a subset of changes, I can still manage to do
> >> what I
> >> like.
> >>
> >>
> >>
> >> ___
> >> fossil-users mailing list
> >> fossil-users@lists.fossil-scm.org
> >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> >>
> >>
> >
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Marcel Graf]

On Fri, Mar 20, 2015 at 7:14 PM, Ron W  wrote:

> On Fri, Mar 20, 2015 at 1:30 PM, Marcel Graf 
> wrote:
>
>> On Fri, Mar 20, 2015 at 6:04 PM, Richard Hipp  wrote:
>>
>>> On 3/20/15, Martin S. Weber  wrote:
>>> ...
>>
>> > in itself). So you end up with intermingled changes which one would
>>> > like to split cleanly.
>>> >
>>> The way I deal with this in SQLite is:
>>> ...
>>
>> (2) On the occasions when I mess up and accidentally put unrelated
>>> changes into the same check-out, I have been known to stash the whole
>>> thing, then reapply one set of changes, test, commit, then reapply the
>>> other set of changes, test, and commit again.
>>
>>
>> This (2) might be easier with something like a
>> "partial/selective/interactive stash" as mentioned by the OP in the bottom
>> part of his email.
>> So (2a) would look like: selectively stash the "second" set of changes,
>> test (thus including the "first" set of changes), commit, stash pop/apply
>> "second", test, commit
>>
>
> I suppose this would make sense if there are fewer changes to "undo" in
> the edited code than to "re do" in the reverted code.
>
>

> You can achieve the same result with "fossil snapshot" (which skips the
> automatic revert), then "fossil gdiff" to selectively "undo" changes. Then
> edit/build/test/commit what remains. After that, "fossil stash gdiff" to
> selectively re-apply more changes. Repeat as needed
>

I assume you mean fossil stash snapshot. This will still "take" the whole
thing (or a selection of entire files) and whatever diff-merge-gui I use
for fossil gdiff will hopefully allow me to efficiently "undo" the changes
of the "second" modification. Yes, that will do!
And as you said, doing it "forward" or "backward" depends on the number of
changes in the "first" vs the "second" modification. Or even split is up in
one "stash save" for all files with only "second" modifications, one "stash
snapshot" for the "mixed" ones and "undo"  the parts from the "second".
Test/commit, "stash apply 2" and "stash apply 1", test/commit.

I was more thinking about a command line only version of stash/snapshot
--interactive asking for each file if i want it entirely or split and in
case of the latter, letting me select each chunk without the use of an
external gui (I vaguely remember mercurial's record extension doing
something like this). But might not be worth it and/or induce to many
options to stash ...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Ron W]

On Fri, Mar 20, 2015 at 3:32 PM, Marcel Graf 
wrote:
>
> I was more thinking about a command line only version of stash/snapshot
> --interactive asking for each file if i want it entirely or split and in
> case of the latter, letting me select each chunk without the use of an
> external gui (I vaguely remember mercurial's record extension doing
> something like this). But might not be worth it and/or induce to many
> options to stash ...
>

To interactively select file-by-file which files to stash should be not
hard.

Selecting chunks of code with in a file is a lot more work, but still
possible. Basically a variation on a non-gui, interactive merge. The input
pair would be the edited file and its baseline. Then where a difference is
detected, the tool shows the 2 versions of the differing block of lines,
along with context, and prompts the user to choose which of the 2, then
outputs the chosen variant to the output file. Then the content output file
would be put in the stash.

I've never seen a non-gui, interactive merge, so I don't know how feasible
to create such a tool

But, generically speaking, a selective stash operation would provide the
edited file and its baseline to a configurable tool that would produce a
third file that Fossil would then put the content thereof in the stash for
the edited file.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Martin S. Weber]

On 2015-03-20 15:56:51, Ron W wrote:
> I've never seen a non-gui, interactive merge, so I don't know how feasible
> to create such a tool

Have a look at sdiff from e.g. GNU diffutils, invoked with the -o option.

Regards,
-Martin
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] multiple independent check-outs against the same repository

[Warren Young]

On Mar 19, 2015, at 9:27 PM, Richard Hipp  wrote:
> 
> There is no documentation because I could not conceive of wanting to
> use a VCS in any other way.

It’s been several years since Git emerged as top dog in the DVCS race, so there 
must be a significant number of people who have used nothing else.  They’re 
going to be trained to think that stash-and-switch is the only way.

Those of us who came up through CVS and/or SVN have a different outlook.

(...An outlook that often results in “Git? E.” :) )
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Steve Stefanovich]

‎I feel exactly like below little excerpt from recent drh's email on the 
subject. There other bits of Fossil that are more important - to me, at least - 
to spend time on, like polishing search, improving wiki and ticketing default 
setup, etc. 

If we are discussing "partial", I'm more interested in partial checkouts than 
partial commits, i.e. having the ability to checkout a specific directory only. 
Now that would be useful for us with big source trees where there are third 
party components included.

  Original Message  
From: Richard Hipp
Sent: Saturday, 21 March 2015 04:05
Subject: Re: [fossil-users] Select specific changes within files

...We shouldn't waste too much time implementing that capability when there are 
other more useful features that could be added instead...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Scott Robison]

On Fri, Mar 20, 2015 at 2:55 PM, Steve Stefanovich  wrote:

> If we are discussing "partial", I'm more interested in partial checkouts
> than partial commits, i.e. having the ability to checkout a specific
> directory only. Now that would be useful for us with big source trees where
> there are third party components included.
>

+1

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[jungle Boogie]

On 20 March 2015 at 13:55, Steve Stefanovich  wrote:
> If we are discussing "partial", I'm more interested in partial checkouts than 
> partial commits, i.e. having the ability to checkout a specific directory 
> only. Now that would be useful for us with big source trees where there are 
> third party components included.


+1

Another interesting idea for Fossil:
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19270.html




-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Ron W]

On Fri, Mar 20, 2015 at 4:55 PM, Steve Stefanovich  wrote:
>
> If we are discussing "partial", I'm more interested in partial checkouts
> than partial commits, i.e. having the ability to checkout a specific
> directory only. Now that would be useful for us with big source trees where
> there are third party components included.
>

++
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] skin-xekri check-ins

[jungle Boogie]

Hi All,

Can zakero's updates be pushed to trunk/tip or is there still code review?

http://fossil-scm.org/index.html/info/9fc08d9200e432f9
http://fossil-scm.org/index.html/info/4b1671f8fd168cdd



-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Andy Bradford]

Thus said Stephan Beal on Fri, 20 Mar 2015 13:45:14 +0100:

> IMO  it's inherently  evil because  it promotes  checking in  untested
> subsets. Automated  tests require  a full, valid  tree. Checking  in a
> part of a change may well lead  to code which runs on your machine but
> doesn't  run  on  remotes  (continuous integration  systems  or  other
> users).

The  biggest  difference  being  that  with  git,  your  commit  is  not
automatically pushed. So it's alright  to commit partial changes because
they won't go anywhere and remain local until you actually pull and then
push (or make a pull request).

With Fossil, on the other hand,  the default sync mode is autosync which
means that committing a partial commit could be much more dangerous than
in git.

Andy
--
TAI64 timestamp: 4000550cab48
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] skin-xekri check-ins

[Andrew Moore]

On Mar 20, 2015 5:02 PM, "jungle Boogie"  wrote:
>
> Hi All,
>
> Can zakero's updates be pushed to trunk/tip or is there still code review?
>
> http://fossil-scm.org/index.html/info/9fc08d9200e432f9
> http://fossil-scm.org/
index.html

/info/4b1671f8fd168cdd

>

I would prefer to wait.  Tontyna provided some feedback earlier in the week
which I would like to address first.  Unfortunately, life got busy and
didn't have an opportunity to work on it, however I will have time this
weekend.

Sorry for the delay.

>
>
> --
> ---
> inum: 883510009027723
> sip: jungleboo...@sip2sip.info
> xmpp: jungle-boo...@jit.si
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] skin-xekri check-ins

[jungle Boogie]

On Mar 20, 2015 4:37 PM, "Andrew Moore"  wrote:
>
>
> On Mar 20, 2015 5:02 PM, "jungle Boogie"  wrote:
> >
> > Hi All,
> >
> > Can zakero's updates be pushed to trunk/tip or is there still code
review?
> >
> > http://fossil-scm.org/index.html/info/9fc08d9200e432f9
> > http://fossil-scm.org/index.html/info/4b1671f8fd168cdd
> >
>
> I would prefer to wait.  Tontyna provided some feedback earlier in the
week which I would like to address first.  Unfortunately, life got busy and
didn't have an opportunity to work on it, however I will have time this
weekend.
>
> Sorry for the delay.
>

No problem on my part.  I don't know there were pending changes.

> >
> >
> > --
> > ---
> > inum: 883510009027723
> > sip: jungleboo...@sip2sip.info
> > xmpp: jungle-boo...@jit.si
> >
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Andy Bradford]

Thus said Richard Hipp on Fri, 20 Mar 2015 13:04:44 -0400:

> (1) Make  logically separate  changes in  separate check-outs  so that
> they are easy to test and commit separately.

I think this  ability to have multiple checkouts of  the same repository
is a much more elegant solution, but  it does require one to impose some
modicum of discipline in one's workflow.

As you  say, it is possible  to accidentally make changes  where one did
not want them, and  yes, this may require some clean  up, but is partial
commit support optimizing for an edge case?

Fossil has stash.  It supports multiple opens of the  same repository on
different branches.

It is  already relatively (I  mean relative to  git) easier to  clean up
mistakes;  I've never  felt like  ``I'm a  bad person  and must  rewrite
history[1]''  because  Fossil make  recovering  from  these things  much
easier.

In my time using git I have never actually once used partial commits.

How often do git users on this list use partial commits?

[1] http://sethrobertson.github.io/GitFixUm/fixup.html#pushed_old

Thanks,

Andy
--
TAI64 timestamp: 4000550cb1ae
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[tonyp]

++1

From: Scott Robison 
Sent: Friday, March 20, 2015 11:08 PM

On Fri, Mar 20, 2015 at 2:55 PM, Steve Stefanovich  wrote:

  If we are discussing "partial", I'm more interested in partial checkouts than 
partial commits, i.e. having the ability to checkout a specific directory only. 
Now that would be useful for us with big source trees where there are third 
party components included.


+1

-- 

Scott Robison 




___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Andy Bradford]

Thus said Ron W on Fri, 20 Mar 2015 13:19:58 -0400:

> Never too  late to  stash. If  I decide  I need  to split  out changes
> already  made, I  stash the  files, then  do "fossil  stash gdiff"  to
> selectively (re) apply the stashed changes, then build/test/commit.

gdiff allows you to selectively apply part of the stash? If so, it seems
like Fossil already has partial commit support. :-)

/me needs to look at gdiff...

Andy
--
TAI64 timestamp: 4000550cb28f
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Andy Bradford]

Thus said Abilio Marques on Fri, 20 Mar 2015 13:58:33 -0430:

> Then I start to work in a new  feature, and I add 10 functions (I will
> only show one here).

Now that you know about it, can  the start of a new feature also involve
another fossil open of the repository for said feature?

Thanks,

Andy
--
TAI64 timestamp: 4000550cb414
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Andy Bradford]

Thus said Marcel Graf on Fri, 20 Mar 2015 18:30:11 +0100:

> Imho, the "missing piece" would be  "stash" having means to do partial
> stashing (finer than on file-by-file base). This the would allow to do
> these "splittings  of a mixed  up check-outs" a bit  easier (including
> testing  "before"  committing, no  need  for  "partial commit"  then),
> wouldn't it?

Or  the opposite.  Stash and  partial pop,  which apparently  Fossil can
already handle simply  by using the ``right'' diff tool.  For example, I
configured Fossil to use idiff as my gdiff command

$ fossil set gdiff-command idiff

Now I can run  fossil stash gdiff and interactive diff  will allow me to
selectively apply the diff

There may be better tools than idiff, but honestly, given that there are
already tools out there that do this,  and Fossil allows one to choose a
gdiff-command, must Fossil also have this same code?

Just my $0.02.

Andy
--
TAI64 timestamp: 4000550cbabc
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is this a crazy idea?

[Scott Robison]

On Mar 20, 2015 1:07 PM, "Abilio Marques"  wrote:
>
> Yeah, stash is the way I do all the time, but sometimes I want to exclude
binaries that are regenerated each time a change and compilation occurs,
until I'm ready to the new version to go into trunk.
>
> Top of my mind, the PDF files that are generated when I use LaTeX. I want
to keep the stable version in trunk, yet avoid including binaries that are
sometimes hundreds of Kbytes each commit to my "this is just a test"
branch, or "this is a modification in progress" branch. I would have to
stash the PDFs before each commit (and they are not useful anyway) or type
down the entire list of files that I want to include on each commit, which
are different each time.
>
> But by doung fossil ci --ignore file1.pdf file2.pdf -m "here is an
example", I can reuse that command 15 times without using the brain harder
than a normal "complete" commit will ask me for, until I'm ready to go to
the trunk.

Just throwing out an idea: I can see the utility in ignoring certain files
on the command line. An ignore switch fits with other commands which take
an ignore glob on the command line (I think). The extended thought that
came to mind was a new command like "fossil pause", which would not remove
a file from the repo, probably would only apply to the working copy, but
would stop committing updates to paused files until unpaused. For those of
us that use the interactive commenting feature at commit, it could easily
provide a list of not only what files are included in the commit, but what
files are updated but paused.

Or maybe it is a solution in search of a problem.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Select specific changes within files

[Andy Bradford]

Thus said Ron W on Fri, 20 Mar 2015 15:56:51 -0400:

> I've never  seen a  non-gui, interactive  merge, so  I don't  know how
> feasible to create such a tool

Here's a non-gui, interactive merge (I didn't show it, but there is also
an edit command  which invokes $EDITOR on just the  chunk in question to
allow you to correct for overlaps such as the one for ``line 3'':

$ fossil settings gdiff-command idiff
$ fossil stash gdif
CHANGED file
3c3,4
< line 3
---
> Line 3
> Line 4
? <
7c8
< Lin3 8
---
> Line 8
? >
idiff output in file idiff.out
$ cp idiff.out file
$ fossil diff
Index: file
==
--- file
+++ file
@@ -2,8 +2,8 @@
 Line 2
 line 3
 Line 5
 Line 6
 Line 7
-Lin3 8
+Line 8
 Line 9
 Line 10

$ fossil ci -m done
New_Version: 4939f3582aa15aa4739b713b232c8feeb34cbc8b

Andy
--
TAI64 timestamp: 4000550cc043
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] multiple independent check-outs against the same repository

[David Macek]

On 20. 3. 2015 21:30, Warren Young wrote:
> On Mar 19, 2015, at 9:27 PM, Richard Hipp  wrote:
>>
>> There is no documentation because I could not conceive of wanting to
>> use a VCS in any other way.
> 
> It’s been several years since Git emerged as top dog in the DVCS race, so 
> there must be a significant number of people who have used nothing else.  
> They’re going to be trained to think that stash-and-switch is the only way.

Hi. Not sure if this wasn't mentioned on purpose, but git kinda sorta supports 
multiple checkouts, depending on how hard you want to stick to the definition.

First, there's the option of cloning the repository locally, which will result 
in two working copies you can work on independently. Maybe too independently, 
as each working copy has its own repo. If you want to see some structure there, 
you can keep one clone as a bare repo and consider it primary. Git should use 
hard links for local cloning, so the operation shouldn't be slower than with 
Fossil.

Second, there's git-new-workdir. I have not used it, but it seems to exist 
exactly for this use case. 


-- 
David Macek



smime.p7s
Description: S/MIME Cryptographic Signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] multiple independent check-outs against the same repository

[Reimer Behrends]

David Macek wrote:

First, there's the option of cloning the repository locally, which will result 
in two working copies you can work on independently. Maybe too independently, 
as each working copy has its own repo. If you want to see some structure there, 
you can keep one clone as a bare repo and consider it primary. Git should use 
hard links for local cloning, so the operation shouldn't be slower than with 
Fossil.


While this is the intended solution (it's why "git clone" uses hardlinks 
for the parts of the repository that can be safely shared when cloning 
locally), it is inherently more limited in that you can't reference 
branches in the other clones, can't diff/merge/etc. against a remote 
branch that wasn't part of the original clone without first bringing it 
in via "git fetch". This is not a problem that Fossil, Monotone, 
Mercurial (with "hg share"), or Bazaar have (let alone any centralized 
system). Ultimately, the standard Git workflow is designed around one 
checkout per repository and doing something else generally requires you 
to jump through some hoops.



Second, there's git-new-workdir. I have not used it, but it seems to exist exactly 
for this use 
case.


Note that git-new-workdir is not safe and can lose you data. The reason 
is that the HEAD revision is local to the directory containing the 
checkout when you use git-new-workdir. Thus, if you have multiple HEAD 
revisions in different directories, only one will be traced by the 
garbage collector. Because reflogs are checkout-local, too, the only 
safety against data loss that remains is the two week grace period built 
into the GC. I.e., you can get stuff like this:


[behrends@Hilbert /tmp/g2]$ git gc --prune=all
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (6/6), done.
Total 6 (delta 0), reused 6 (delta 0)
[behrends@Hilbert /tmp/g2]$ cd ../g
[behrends@Hilbert /tmp/g]$ git log --all
fatal: bad object HEAD

There's a reason why it's in contrib and not a first-class Git command. 
In short: Don't use it unless you know exactly what you are doing.


Note: Git could relatively easily be fixed to support multiple 
checkouts, but that would require deeper changes.


Reimer Behrends
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users