Re: [fossil-users] Is this a crazy idea?
* Ramon Ribó ram...@compassis.com [20150320 11:19]: 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 This is pretty much what hg GUIs (tortoisehg) do, and it is something rather useful. qvb -- pica ___ 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?
[Default] On Fri, 20 Mar 2015 14:36:51 -0430, Abilio Marques
abili...@gmail.com 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.
Will something like
fossil ci -m example $(fossil changes|grep -v .pdf|awk '{print $2}')
do what you intend?
It is repeated as easily as the --ignore solution.
--
Regards, Cordialement, Groet,
Kees Nuyt
___
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?
On Fri, Mar 20, 2015 at 2:11 AM, die.drachen die.drac...@gmail.com 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] Is this a crazy idea?
On Fri, Mar 20, 2015 at 5:38 AM, Reimer Behrends 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 ___ 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?
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 g...@atmarama.net: Richard Hipp d...@sqlite.org 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] Is this a crazy idea?
Richard Hipp d...@sqlite.org 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] Is this a crazy idea?
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ó ram...@compassis.com 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 g...@atmarama.net: Richard Hipp d...@sqlite.org 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] Is this a crazy idea?
On Mar 20, 2015 1:07 PM, Abilio Marques abili...@gmail.com 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] Is this a crazy idea?
On Fri, Mar 20, 2015 at 11:24 AM, Ramon Ribó ram...@compassis.com 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] Is this a crazy idea?
On Fri, Mar 20, 2015 at 1:45 PM, Ramon Ribó ram...@compassis.com 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?
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 sgb...@googlemail.com: On Fri, Mar 20, 2015 at 11:24 AM, Ramon Ribó ram...@compassis.com 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?
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 sgb...@googlemail.com: On Fri, Mar 20, 2015 at 1:45 PM, Ramon Ribó ram...@compassis.com 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] Is this a crazy idea?
On Mar 20, 2015 5:39 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Mar 20, 2015 at 11:24 AM, Ramon Ribó ram...@compassis.com 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] Is this a crazy idea?
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?
On Fri, Mar 20, 2015 at 12:22 PM, Abilio Marques abili...@gmail.com 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?
On 20/03/15 08:16, Peter Spjuth wrote: On Fri, Mar 20, 2015 at 5:38 AM, Reimer Behrends behre...@gmail.com 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
Re: [fossil-users] Is this a crazy idea?
On 3/20/15, Abilio Marques abili...@gmail.com 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 pault.eg...@gmail.com wrote: On 20/03/15 08:16, Peter Spjuth wrote: On Fri, Mar 20, 2015 at 5:38 AM, Reimer Behrends 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 -- 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?
On Fri, Mar 20, 2015 at 2:55 PM, Richard Hipp d...@sqlite.org wrote: On 3/20/15, Abilio Marques abili...@gmail.com 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?
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 d...@sqlite.org wrote: On 3/20/15, Abilio Marques abili...@gmail.com 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 pault.eg...@gmail.com wrote: On 20/03/15 08:16, Peter Spjuth wrote: On Fri, Mar 20, 2015 at 5:38 AM, Reimer Behrends 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 -- 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] Is this a crazy idea?
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 pault.eg...@gmail.com wrote: On 20/03/15 08:16, Peter Spjuth wrote: On Fri, Mar 20, 2015 at 5:38 AM, Reimer Behrends 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
Re: [fossil-users] Is this a crazy idea?
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 pault.eg...@gmail.com mailto:pault.eg...@gmail.com wrote: On 20/03/15 08:16, Peter Spjuth wrote: On Fri, Mar 20, 2015 at 5:38 AM, Reimer Behrends behre...@gmail.com 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 mailto: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] Is this a crazy idea?
[Default] On Thu, 19 Mar 2015 19:22:14 -0430, Abilio Marques abili...@gmail.com wrote: Having said these things, I must confess that in my mind, I find the staging area a difference that's not easily solved. Perhaps some of you have thought about this before, and have ideas on how to simulate it in a clean way. Any idea on my idea is welcomed. Isn't that solved by the ability of fosil to have multiple checkouts for the same repository, each in its own branch? I agree it might be hard to write a shim for that. -- Regards, Cordialement, Groet, Kees Nuyt ___ 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?
On Thu, Mar 19, 2015 at 6:32 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Scott Robison sc...@casaderobison.com wrote: I can't answer for Abilio, but given my recent increased experience with git due to workplace changes: the git folk seem to prefer the staging area because you're less likely to accidentally commit something you didn't mean to. Essentially, it seems like a feature for people who can't or don't want multiple open work areas so ensure the right things get committed on the right branches, since they very well may be working on multiple branches at the same time in the same tree. So the staging area is being used as a way of working around the fact that Git does not allow multiple independent check-outs against the same repository? Am I understanding that correctly? That is the best answer I've been given. I explained how I worked (in both svn fossil) on separate branches in separate directories, but received no further feedback on that topic. -- 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] Is this a crazy idea?
On Thu, Mar 19, 2015 at 6:14 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Does the git staging area provide any capability beyond this? Am I missing something? Please help me to understand why people think that the git staging area is a good idea. I can't answer for Abilio, but given my recent increased experience with git due to workplace changes: the git folk seem to prefer the staging area because you're less likely to accidentally commit something you didn't mean to. Essentially, it seems like a feature for people who can't or don't want multiple open work areas so ensure the right things get committed on the right branches, since they very well may be working on multiple branches at the same time in the same tree. See this: http://stackoverflow.com/questions/6270193/multiple-working-directories-with-git The staging area can be disabled / skipped, but that's how it has been explained to me. -- 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] Is this a crazy idea?
On 3/19/15, Scott Robison sc...@casaderobison.com wrote: I can't answer for Abilio, but given my recent increased experience with git due to workplace changes: the git folk seem to prefer the staging area because you're less likely to accidentally commit something you didn't mean to. Essentially, it seems like a feature for people who can't or don't want multiple open work areas so ensure the right things get committed on the right branches, since they very well may be working on multiple branches at the same time in the same tree. So the staging area is being used as a way of working around the fact that Git does not allow multiple independent check-outs against the same repository? Am I understanding that correctly? -- 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?
On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Fossil does give you the ability to do a partial commit (in case you are really want to commit changes that you have not tested). Just list the subset of files you want to commit on the commit command-line: fossil commit one.txt two.txt dir-three/ If you include directories in the list, then all modified files underneath those directories are committed. Does the git staging area provide any capability beyond this? Am I missing something? Please help me to understand why people think that the git staging area is a good idea. -- 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?
I was cooking dinner, so Scott wrote it first. Basically I agree with his point of view. I must confess that historically, I first used fossil, then git, so staging was actually weird for me at the beginning. Then I kinda liked it for no apparent reason. It felt like it simplified the partial commit, specially because I decided this file SHOULD be in my next commit, this shouldn't... then went for lunch, came back... and the list was still there. I could go home, get back the next day, and the list was still there. In fossil, I must rewind all my work until the commit moment, check the list of files, remember what was did what, and the proceed to do a partial commit. Then there is the fact to ensure right things committed on the right branches. In my personal projects, there is one where I miss this thing a lot. I keep my resume in LaTeX, and I do push the PDFs that are generated, but only into trunk (not the other branches). I have to do partial commits all the times. Actually, about that, 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. Why staging area is so hip? I don't really know... I guess is a philosophy thing, and most people come from git, so they are used to it, and is a shock when they don't see it. I guess they feel like they will miss some kind of freedom. Can you survive on fossil without it? totally... For most of them (my git friends), the autosync is also a how will I survive this moment, but then they discover they can turn it off, use it for a while like that, then give it a shot again, and then live with it (some love it). On Thu, Mar 19, 2015 at 7:52 PM, Scott Robison sc...@casaderobison.com wrote: On Thu, Mar 19, 2015 at 6:14 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Does the git staging area provide any capability beyond this? Am I missing something? Please help me to understand why people think that the git staging area is a good idea. I can't answer for Abilio, but given my recent increased experience with git due to workplace changes: the git folk seem to prefer the staging area because you're less likely to accidentally commit something you didn't mean to. Essentially, it seems like a feature for people who can't or don't want multiple open work areas so ensure the right things get committed on the right branches, since they very well may be working on multiple branches at the same time in the same tree. See this: http://stackoverflow.com/questions/6270193/multiple-working-directories-with-git The staging area can be disabled / skipped, but that's how it has been explained to me. -- 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] Is this a crazy idea?
On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Fossil does give you the ability to do a partial commit (in case you are really want to commit changes that you have not tested). Just list the subset of files you want to commit on the commit command-line: fossil commit one.txt two.txt dir-three/ If you include directories in the list, then all modified files underneath those directories are committed. Does the git staging area provide any capability beyond this? 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. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ 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?
On 3/19/15, Andreas Kupries andre...@activestate.com wrote: On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Fossil does give you the ability to do a partial commit (in case you are really want to commit changes that you have not tested). Just list the subset of files you want to commit on the commit command-line: fossil commit one.txt two.txt dir-three/ If you include directories in the list, then all modified files underneath those directories are committed. Does the git staging area provide any capability beyond this? 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. The next time that I end up w/ two logical ideas commited w/ a single checkin won't be the first. Currently, if it's important enough for me, what I do is [stash] the commit, generate a diff and then selectively apply that diff in the appropriate number of steps, committing ea. logical idea at a time. Otherwise, re: staging area vs. fossil commit, it seems it's just a matter of default include vs default deny as far as what gets committed. One thing that would alleviate miscommitted collections of files (or miscommitted anything) is the ability to [pop] off a branch tip... -bch -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster(tm) F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ 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?
By doing git commit -a, your doing an implicit git add -A before the commit, which stages all the uncommitted changes, and then you're working close to what you would in fossil. But we're talking about the Linus dream: You do some changes, then you select the files (not it seems that even line by line changes are selectable) you want to include in the commit by doing git add, and then you commit. Try this on an empty directory (I'm running by memory now, so don't believe me completely): git init echo line 1 test.txt git add test.txt git commit -m this is a test echo line 2 test.txt git status # You'll see it talks about unstaged changes by this point git commit -m another line in the test # I believe it will refuse On Thu, Mar 19, 2015 at 9:17 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Abilio Marques on Thu, 19 Mar 2015 21:08:55 -0430: (1) modify a file or files (2) add the files (every single time... this sucks sometimes, as Joerg said) (3) commit I'm not sure what (2) is unless you mean that I create new files in the working checkout and then use ``git add'' to add them. As to why this would suck, I'm not sure, isn't ``git add'' a necessary evil to get something into the repository? Here's my typical git day: (1) modify or create file(s) (1a) git add files if necessary (2) review changes with git diff (3) git commit -a (or git commit for a specific file if some changes are not ready (4) git pull; git push when ready So, let me ask this, if this means I'm using the staging area, why don't I feel like this is any different than how I use Fossil? Andy -- TAI64 timestamp: 4000550b7c54 ___ 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?
Thus said Abilio Marques on Thu, 19 Mar 2015 21:25:05 -0430: By doing git commit -a, your doing an implicit git add -A before the commit, which stages all the uncommitted changes, and then you're working close to what you would in fossil. I see, this is totally foreign to how I use git. I have never had to use ``git add -A'', nor have I had to do ``git add'' for files that were modified, only files that do not exist in the current checkout. You do some changes, then you select the files (not it seems that even line by line changes are selectable) you want to include in the commit by doing git add, and then you commit. Again, this is foreign to me. I'm not sure I see the benefit to such a feature. I can select which files (though not which lines) when I do ``fossil commit files.'' Having a step in between the commit and modifying the files just seems just more state that I have to worry about. git status # You'll see it talks about unstaged changes by this point Oh, yes, I do use ``git status'' similar to how I use ``fossil status'' git commit -m another line in the test # I believe it will refuse Yes, it will refuse. Normally, I just use git commit -a or git commit filename. So I think I can safely say that, no, I do not use the staging area, at least not the way Linus intended it. I think this is a non-feature. Thank you for taking the time to explain to me what I'm missing out on by using ``git commit -a'' and ``git commit filename'' :-) Andy -- TAI64 timestamp: 4000550b84b7 ___ 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?
Really? didn't know that... I'm impressed by that. There've been times when I've needed it, then proceeded to stash, then stash apply, then modified, then committed, then stash popped and so on... Unless you mean that you do a git add, the modify the same file, and commit as is, without doing git add again... that way you can selectively commit a sub-set, but depends on the moment you did the adds. Never heard of selectivity. I know it could be off topic (does it?), but how would you do that? Do you have an example? On Thu, Mar 19, 2015 at 8:28 PM, Andreas Kupries andre...@activestate.com wrote: On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Fossil does give you the ability to do a partial commit (in case you are really want to commit changes that you have not tested). Just list the subset of files you want to commit on the commit command-line: fossil commit one.txt two.txt dir-three/ If you include directories in the list, then all modified files underneath those directories are committed. Does the git staging area provide any capability beyond this? 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. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ 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?
Thus said Abilio Marques on Thu, 19 Mar 2015 19:22:14 -0430: Having said these things, I must confess that in my mind, I find the staging area a difference that's not easily solved. Perhaps some of you have thought about this before, and have ideas on how to simulate it in a clean way. Any idea on my idea is welcomed. I've used git for a few years now, but I've never used this beloved ``staging area,'' at least not conciously. What am I missing by not using the ``staging area?'' Andy -- TAI64 timestamp: 4000550b78ab ___ 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?
I think I missed you here, or you missed me, but I know you got the fact that by doing: git commit -a or git commit filename, you're skipping the staging area. For example, by doing git commit -a -m this is a test, what git is internally doing is the equivalent to: git add -A git commit -m this is a test And by doing git commit -m this is a test filenames, it's doing: git add filenames git commit -m this is a test I suggest you (if you haven't done it) to avoid using git commit - and avoid using git commit filenames . The way you're working, well... that was the way I did it the first days I used git, until a close friend of mine told me to drop it and work like everybody else. I said no, 3 minutes later I was trying... had to learn that the ADD command was for something else that adding a new file (linus tovards, why? just use the word STAGE). Believe me, reading about staging area seemed weird and hard to grasp... why would I complicate with those things? In the end I learned how to use it, and it improved communication with my team. That's the reason why I tell you to give it a shot. On Thu, Mar 19, 2015 at 9:53 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Abilio Marques on Thu, 19 Mar 2015 21:25:05 -0430: By doing git commit -a, your doing an implicit git add -A before the commit, which stages all the uncommitted changes, and then you're working close to what you would in fossil. I see, this is totally foreign to how I use git. I have never had to use ``git add -A'', nor have I had to do ``git add'' for files that were modified, only files that do not exist in the current checkout. You do some changes, then you select the files (not it seems that even line by line changes are selectable) you want to include in the commit by doing git add, and then you commit. Again, this is foreign to me. I'm not sure I see the benefit to such a feature. I can select which files (though not which lines) when I do ``fossil commit files.'' Having a step in between the commit and modifying the files just seems just more state that I have to worry about. git status # You'll see it talks about unstaged changes by this point Oh, yes, I do use ``git status'' similar to how I use ``fossil status'' git commit -m another line in the test # I believe it will refuse Yes, it will refuse. Normally, I just use git commit -a or git commit filename. So I think I can safely say that, no, I do not use the staging area, at least not the way Linus intended it. I think this is a non-feature. Thank you for taking the time to explain to me what I'm missing out on by using ``git commit -a'' and ``git commit filename'' :-) Andy -- TAI64 timestamp: 4000550b84b7 ___ 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?
will only commit changes in 1, and if you do git status, will tell you about the modifications done in 3. On Thu, Mar 19, 2015 at 8:38 PM, Richard Hipp d...@sqlite.org wrote: Further questions about staging area: If I do this: (1) Edit file xyzzy.txt (2) git add xyzzy.txt (3) More edits to xyzzy.txt (4) git commit Then does only the first set of edits to xyzzy.txt get committed, or do both edits (1) and (3) get committed? -- D. Richard Hipp 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] Is this a crazy idea?
On Thu, Mar 19, 2015 at 06:22:52PM -0600, Scott Robison wrote: I can't answer for Abilio, but given my recent increased experience with git due to workplace changes: the git folk seem to prefer the staging area because you're less likely to accidentally commit something you didn't mean to. Ironically, from what I have seen it is the feature most likely to make you commit something you didn't mean to. It is even more obnoxious than the commit with explicit file list in all other systems -- it makes it even easier to forgot parts with a dirty work directory. Joerg ___ 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?
I'm brand new to fossil but have used git some and mercurial even longer. When I'm working on a project I tend to poke around in the areas of code nearby to what my task directly involves - as a manner of investigating and learning. The git staging area is useful to my workflow because I am often making changes and testing something, but later decide to have separate commits within all the changes. This helps preserve a nicer history where commits usually have single-responsibility. For example, fixing a null pointer in a button click handler, but also tweaking the button's sizing/border/etc. to be consistent within the UI. I would likely make those two changes at once and test locally, but ultimately have separate commits for each change. On other occasions where I might end up in a similar situations is when finding out one bug is actually multiple bugs. It sounds like fossil is similar to mercurial - mercurial's commit command by default includes all local changes, but arguments can be specified for including/excluding files (or file patterns). When I first started using git I was thrown off by having to include things into staging before committing, but I have started preferring the explicit nature of defining my commits that way. Christopher ___ 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?
Further questions about staging area: If I do this: (1) Edit file xyzzy.txt (2) git add xyzzy.txt (3) More edits to xyzzy.txt (4) git commit Then does only the first set of edits to xyzzy.txt get committed, or do both edits (1) and (3) get committed? -- D. Richard Hipp 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?
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: Changes to be committed: modified: index.js Changes not staged for commit: modified: index.js ___ 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?
Do you follow the traditional?: (1) modify a file or files (2) add the files (every single time... this sucks sometimes, as Joerg said) (3) commit If the answer is yes, you're using the staging area... Cool things about that... yes, you can select what to include (seems that line by line). See my next email On Thu, Mar 19, 2015 at 9:01 PM, Andy Bradford amb-sendok-1429407112.filllmkhpgbjfacbk...@bradfords.org wrote: Thus said Abilio Marques on Thu, 19 Mar 2015 19:22:14 -0430: Having said these things, I must confess that in my mind, I find the staging area a difference that's not easily solved. Perhaps some of you have thought about this before, and have ideas on how to simulate it in a clean way. Any idea on my idea is welcomed. I've used git for a few years now, but I've never used this beloved ``staging area,'' at least not conciously. What am I missing by not using the ``staging area?'' Andy -- TAI64 timestamp: 4000550b78ab ___ 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?
Yes, I realized you seem to be right and nobody told me (I learnt git on my own), but in git, you can run git add --interactive (and it allows you to selectively work with each uncommitted add you did) and there is also git add --edit, which allows you to directly edit the unified patch in your favorite text editor (the one that will be stored in the commit). Seems REALLY powerful, but need to play more with it. As a side note, one of the reasons I dislike git is because the commands don't do (do as in never) what their name imply, and some are hidden as subcommands inside commands that are meant for other purposes. Fossil should keep away from that road of uncertainty. On Thu, Mar 19, 2015 at 8:28 PM, Andreas Kupries andre...@activestate.com wrote: On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Fossil does give you the ability to do a partial commit (in case you are really want to commit changes that you have not tested). Just list the subset of files you want to commit on the commit command-line: fossil commit one.txt two.txt dir-three/ If you include directories in the list, then all modified files underneath those directories are committed. Does the git staging area provide any capability beyond this? 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. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ 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?
On Mar 19, 2015, at 5:52 PM, Abilio Marques abili...@gmail.com wrote:
I've toyed with the idea of writing a shim so fossil can be used in place
of git or subversion.
I speak only pidgin Git, so I wouldn’t like to speculate about how difficult
such a shim would be to write.
I can, however, speak to the svn case. I have used Subversion heavily for
about a dozen years now, so I can pretty confidently predict that you’re going
to run into a bunch of areas where the semantics of Fossil and Subversion
differ enough to make building such a shim tricky, and in places actually
difficult.
Here are the differences that immediately occur to me:
1. svn uses a monotonically-increasing revision number for the whole repository
as the unique identifier for each checkin. Fossil uses cryptographic hashes
instead. This affects every command in both systems that take an -r flag, and
more.
(“More” because Fossil doesn’t always use -r to specify a checkin. Fossil is
somewhat of a bicameral mind on this point: sometimes you use -r, and other
times you just give it as a bare parameter.)
For the same reason, I don’t know how you’d implement an svnversion wrapper in
terms of Fossil.
2. Fossil branching and tagging are baked into the database schema; there’s
only one way to do it.
In Subversion, branching and tagging are a mere *convention* built on top of
the svn copy command, and there is no requirement that your copy target be
somewhere under the repo’s branches or tags directories; that too is just a
convention.
I don’t think you can actually emulate the full scope of the svn copy command
in terms of Fossil. There are things you can do with that command that do not
map neatly to fossil tag and branch commands.
3. fossil timeline is not quite the same thing as svn log.
First you have to decide if you want to translate the output formats so that
it’s parseable by tools that know how to read svn log output.
Then you have a deeper problem, which is that the two commands simply don’t
entirely overlap in their capability.
Some svn log commands will be straightforward to translate into fossil timeline
commands:
svn log -r{2014-12-25}:HEAD
is the same as:
fossil timeline after 2014-12-25 -n 0
But, svn also lets me give an arbitrary log endpoint, which fossil timeline
doesn’t:
svn log -r{2014-12-25}:r1234
How will your shim cope?
4. svn does one-step mv and rm operations. Fossil currently requires a
separate OS-level mv or rm to accompany the Fossil command in order to make the
file tree consistent with the repo.
I’ve advocated for this to change, though it’s looking like if something along
this line does happen, it won’t be to make Fossil behave exactly like svn, but
perhaps more like Monotone instead.
5. svn ci is not quite the same thing as fossil ci. Perhaps “fossil ci .” is
close enough for your purposes. (i.e. Subversion checks in only files in the
current directory and its children, by default.)
6. svn allows sub-repo checkouts. Fossil doesn’t. (Yet.)
7. There is no equivalent to svn [un]lock in Fossil. (Praise Ritchie!)
8. Emulating svn merge in terms of fossil merge amounts to taking a simple and
straightforward interface and complexifying it.
9. svn doesn’t even blink if you try to check in a binary file. Fossil copes
just fine with binary files, too, but by default it second-guesses you whenever
you do it with a file that isn’t on its glob whilelist.
10. svn info more or less combines what Fossil implements separately via info
and finfo. I think it might be tricky to work out which Fossil command to call
for a given set of args to your svn wrapper.
11. svn stat and fossil stat are conceptually the same thing, but their output
formats are quite different.
12. fossil open kind of overlaps the effects of svn co and svn switch, but not
entirely.
13. Most of the svn prop{get,set,edit,del} properties do not exist in Fossil:
svn:ignore: Fossil has the ignore-glob setting, but it’s very much not the same
thing. Fossil and svn are almost inverses in the way they handle file
ignorance. (Ignoration? Ignorification?)
svn:keywords: Fossil doesn’t do RCS/CVS-like keyword substitution at all, on
purpose.
svn:executable: A similar per-file property exists in Fossil, but it’s more of
an implicit property. To make the shim behave *exactly* like svn, you’re going
to have to defeat Fossil’s implicit use of the file’s modes to implement this
property.
svn:eol-style: Fossil doesn’t do CRLF translation, ever. I think those
interested in using such a shim will be a self-selected set of people who have
a greater-than-average interest in having such a feature than those willing to
just switch to Fossil. You may be asked to emulate this behavior on top of
Fossil.
svn:mime-type: The “doc” URL handler in Fossil has a hard-coded implementation
of this, which probably obviates the need to emulate this property, but perhaps
someone
Re: [fossil-users] Is this a crazy idea?
die.drachen wrote: The git staging area is useful to my workflow because I am often making changes and testing something, but later decide to have separate commits within all the changes. This helps preserve a nicer history where commits usually have single-responsibility. For example, fixing a null pointer in a button click handler, but also tweaking the button's sizing/border/etc. to be consistent within the UI. I would likely make those two changes at once and test locally, but ultimately have separate commits for each change. On other occasions where I might end up in a similar situations is when finding out one bug is actually multiple bugs. There are three points I'd like to make here: 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.). Second, even if you prefer not to do it this way, git commit --amend essentially made the staging area superfluous a long time ago for the purpose of splitting commits. Third, while splitting commits (where you accidentally mashed multiple things together that you later realize should be separated) is a very relevant feature, this is largely a problem of the user interface, not the staging area. The staging area is frequently used because many graphical Git clients provide excellent UI tooling for staging parts of a file as a commit. However, this does not require a staging area; see, e.g., Bazaar's qshelve command for a graphical tool that provides a similar feature for stashing partial commits. It sounds like fossil is similar to mercurial - mercurial's commit command by default includes all local changes, but arguments can be specified for including/excluding files (or file patterns). Keep in mind that Mercurial also has Mercurial queues, which is (for better or worse) a staging area on steroids. Also, what I said about git commit --amend above applies equally to hg commit --amend. 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] Is this a crazy idea?
Abilio Marques wrote: Cool things about that... yes, you can select what to include (seems that line by line). This does not require a staging area. Darcs, for example, had such selective commits since its inception (in fact, it was and is the default mode of operation for Darcs, for better or worse). 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] Is this a crazy idea?
On Thu, Mar 19, 2015 at 6:10 PM, Abilio Marques abili...@gmail.com wrote: Really? didn't know that... I'm impressed by that. There've been times when I've needed it, then proceeded to stash, then stash apply, then modified, then committed, then stash popped and so on... Unless you mean that you do a git add, the modify the same file, and commit as is, without doing git add again... that way you can selectively commit a sub-set, but depends on the moment you did the adds. Never heard of selectivity. I know it could be off topic (does it?), but how would you do that? Do you have an example? I actually do not know how to do it from the command line. What I use is the git gui command (*), which is a light Tk interface to essentially look at the workspace and the staging area, with a list of files to the left, modified, new, deleted, and for modified files I see the unified diff of my changes for the selected file. I use that to go through all the changes, review them, and choose which to place into the commit, whole file, chunks, parts of a chunk (stage file, stage chunk, stage lines). How it does all this underneath, i.e. which other git commands get used and how, that I do not know. (*) Note, git gui is not gitk, although each can invoke the other, as a separate process. On Thu, Mar 19, 2015 at 8:28 PM, Andreas Kupries andre...@activestate.com wrote: On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Fossil does give you the ability to do a partial commit (in case you are really want to commit changes that you have not tested). Just list the subset of files you want to commit on the commit command-line: fossil commit one.txt two.txt dir-three/ If you include directories in the list, then all modified files underneath those directories are committed. Does the git staging area provide any capability beyond this? 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. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ 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 -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ 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?
Thus said Abilio Marques on Thu, 19 Mar 2015 22:10:41 -0430: git commit -a or git commit filename, you're skipping the staging area. Yes, that's right---thanks to your explanation. I haven't needed it and now that I understand it (at least according what has been discussed) I'm certain I don't need it. :-) I suggest you (if you haven't done it) to avoid using git commit -a and avoid using git commit filenames. Why? Based on what I've seen so far, it doesn't really benefit me (and I fail to see how my use of it will benefit others). Thanks, Andy -- TAI64 timestamp: 4000550b909e ___ 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?
Thus said Abilio Marques on Thu, 19 Mar 2015 21:08:55 -0430: (1) modify a file or files (2) add the files (every single time... this sucks sometimes, as Joerg said) (3) commit I'm not sure what (2) is unless you mean that I create new files in the working checkout and then use ``git add'' to add them. As to why this would suck, I'm not sure, isn't ``git add'' a necessary evil to get something into the repository? Here's my typical git day: (1) modify or create file(s) (1a) git add files if necessary (2) review changes with git diff (3) git commit -a (or git commit for a specific file if some changes are not ready (4) git pull; git push when ready So, let me ask this, if this means I'm using the staging area, why don't I feel like this is any different than how I use Fossil? Andy -- TAI64 timestamp: 4000550b7c54 ___ 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?
Thus said Abilio Marques on Thu, 19 Mar 2015 21:29:28 -0430: As a side note, one of the reasons I dislike git is because the commands don't do (do as in never) what their name imply, and some are hidden as subcommands inside commands that are meant for other purposes. You mean like overloading ``git add'' to be both ``git add'' for new files to be added to the checkout (and eventually the repository) and using ``git add'' to really mean ``git stage''? Andy -- TAI64 timestamp: 4000550b8522 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
