Re: [fossil-users] Idea: automatic check for extras prior to commit
On 8/3/2015 3:24 PM, Warren Young wrote: After making this mistake, I know I'm supposed to move the bad commit to a hidden branch Who supposes this, and why do you take their opinion as normative? When a commit to Fossil causes a problem, I've seen drh move it to a branch (usually not hidden though since he's moving someone else's work) rather than merely following it up with a commit that backs it out. One technical reason for this is to facilitate bisect by striving for every commit on a stable branch compile and run. I thought I saw reference on this list to a way to lop off the most-recent checkin on a particular branch, but I couldn’t figure out how the last time I tried. Is this the mechanism? Using the web interface, you can edit the existing check-in to be in a branch (I usually use the name mistake if it's going to be hidden and superseded) that is closed and hidden. -- Andy Goth | andrew.m.goth/at/gmail/dot/com 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] branch from current branch
On 7/27/2015 6:58 AM, Luca Ferrari wrote: Hi, this can be goofy, but is there a way to instrument fossil to create a new branch from the current one instead of having to specify it? So something like: $ fossil branch new MYBRANCH instead of $ fossil branch new MYBRANCH trunk I didn't realize the branch command could be used to create new branches since I've only ever used commit -branch to do this. Creating a new branch without putting any changes in it is not something I've wanted to do before, and if I did, I would have used commit -allow-empty. -- Andy Goth | andrew.m.goth/at/gmail/dot/com 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] Incorrect check-in count on file report
On 5/17/2015 7:45 PM, Andy Goth wrote: http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg20586.html I found another consequence. This affects the finfo command. Test case from before: f init x.fossil mkdir x cd x f open ../x.fossil touch file1 file2 f add * f commit -m 1 echo hello file2 f commit -branch branch -m 2 f up trunk echo hello2 file1 f commit -m 3 f merge -integrate branch f commit -m 4 Running finfo (deleted user: andy for brevity): $ f finfo file1 2015-08-03 [34b42d0572] 4 (artifact: [0d2aae7d15], branch: trunk) 2015-08-03 [bd57f6ec06] 3 (artifact: [0d2aae7d15], branch: trunk) 2015-08-03 [9fac5e4c62] 1 (artifact: [da39a3ee5e], branch: trunk) $ f finfo file2 2015-08-03 [34b42d0572] 4 (artifact: [f572d396fa], branch: trunk) 2015-08-03 [37e7a23167] 2 (artifact: [f572d396fa], branch: branch) 2015-08-03 [9fac5e4c62] 1 (artifact: [da39a3ee5e], branch: trunk) file2 shows the same artifact [f572d396fa] in two commits, but this is to be expected since the work was first done on a branch then integrated to trunk. file1 also shows the same artifact [0d2aae7d15] in two commits, but I find this to be bogus because the last commit (the one with comment 4) didn't actually touch file1. All it did was integrate branch to trunk, and the only thing that was done on branch was change file2. -- Andy Goth | andrew.m.goth/at/gmail/dot/com 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] Idea: automatic check for extras prior to commit
On 8/3/2015 3:24 PM, Warren Young wrote: On Aug 3, 2015, at 1:31 PM, Andy Goth andrew.m.g...@gmail.com wrote: Usually I don't bother, especially if there have been check-ins since the error was committed. Wouldn’t a better solution to that problem be a continuous integration system, so you get an email shortly after committing a change that breaks the build? Then your risk window shrinks to the CI rebuild time. You're suggesting an external, automated method of auditing check-ins, which I think is a good idea but beyond the scope of the Fossil SCM. I'm suggesting a way for Fossil to warn the user prior to committing a bad check-in in the first place. I was also writing about how to recover from a bad check-in. It can be moved to a hidden branch then retry the commit, or it can be left alone and followed up with a check-in that corrects it. Maybe even merge the lists, prefixing each line with EXTRA or MISSING or NON_UTF8 or CRLF. I rarely run into this one, since I normally just say “all” when asked if I really meant to do that, since I usually did mean to. Then I go and hack on the relevant *-glob setting. I'm more likely to hit bad UTF-8 than CRLF because I know to fix line endings when I import code whereas I tend to rely on Fossil to detect character encodings. Fossil can't convert bad UTF-8 like it can CRLF. So I will want a complete list of files that need me to fix by hand. Maybe split this functionality from the commit command and make a new warning or audit or check command which will print all the things that may prevent a commit from going forward, but also toss in extra files if the check-extras setting is enabled. does Fossil squawk about files using CR alone or LFCR? Yes: Thanks for looking into it. -- Andy Goth | andrew.m.goth/at/gmail/dot/com 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] Wiki Header Footers
On 7/31/2015 9:55 AM, John L. Poole wrote: The Wiki Headers and Footers are not under any versioning control or history, correct? As far as I can tell, that's right. The only versions you get to pick are: 1. Contents of the text edit widget (Apply Changes to select) 2. Current settings (cancel to select) 3. Default (Revert To Default to select) I am planning on creating a file to source control them, but wanted to make sure I'm not doing something that is already built in. I'm not sure it's appropriate to put this (specifically this) in a file, not without reexamining the way the rest of the configuration is stored and managed. Fossil has a separate mechanism for transferring configuration between repositories. http://fossil-scm.org/xfer/help/config (by the way, why does the URL say config when the command is technically named configuration?) According to this, you already have the option to export the configuration to a file which can then be managed however you like. -- Andy Goth | andrew.m.goth/at/gmail/dot/com 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] quick poll: do you generally use add/rm or mv
The same for me. I always use mv as, I guess, add/remove destroys the history of changes. Re syncing with the file system, I find it ok as it is. Usually, I move files using IDE when coding, and then find missing ones while trying to commit. For me 'mv' works ok with the exception that when I added a renamed file, such that 'fossil chan' gives: MISSING myfile-oldname.txt ADDED myfile-newname.txt fossil complains if I try to do $ fossil mv myfile-oldname.txt myfile-newname.txt and then I have to do $ fossil rm newname.txt $ fossil mv myfile-oldname.txt myfile-newname.txt It would be perfect for me if I could just run the mv command even if the renamed file was already added to the current change stack. Cheers, Jacek 2015-08-03 4:53 GMT+01:00 Stephan Beal sgb...@googlemail.com: Counterpoint: have never used addremove because (A) i invariably have lots of temp/scratch files and (B) it's a pretty alien feature (not existing anywhere else, AFAIK). i always use mv. - stephan Sent from a mobile device, possibly from bed. Please excuse brevity and typos. On Aug 3, 2015 01:22, Matt Welland mattrwell...@gmail.com wrote: I've been using (and advising others to use) addremove because fossil mv behavior did not match Unix mv. The differences were confusing. I've no idea if fossil mv now behaves exactly like mv. The other issue was that fossil move did not keep the filesystem in sync with fossil which is also confusing and error prone. On Sat, Aug 1, 2015 at 8:46 AM, Michai Ramakers m.ramak...@gmail.com wrote: Hello, I have been avoiding 'fossil mv' a bit until recently, because I didn't trust it for no good reason. I reckon since it is in trunk, it is considered stable. In project-trees here, I move/rename dirs and files quite often. What I did earlier, was simply to move them as per filesystem, and then let 'fossil addremove' do its thing, and make a commit of only those additions/removals. I was wondering what you generally do for directory trees in motion - use add/rm or mv ? And: the benefit of fossil having a concept of 'moved file/dir' is that the user can trace ancestry crossing moves/renames more easily, is that correct? (At least that's how I use it now.) Michai ___ 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 ___ 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] quick poll: do you generally use add/rm or mv
On 8/3/2015 3:37 PM, Warren Young wrote: On Aug 3, 2015, at 12:49 PM, Andy Goth andrew.m.g...@gmail.com wrote: On 8/3/2015 2:01 AM, Michai Ramakers wrote: On 3 August 2015 at 01:22, Matt Welland mattrwell...@gmail.com wrote: I've no idea if fossil mv now behaves exactly like mv. indeed, it does not. Any plans to bring them in sync? We had a long thread about it months ago: http://lists.fossil-scm.org:8080/pipermail/fossil-users/2015-March/019997.html So far as I know, drh’s opinion remains: http://lists.fossil-scm.org:8080/pipermail/fossil-users/2015-March/020055.html Pretty sure he was talking about whether or not mv and rm should touch the checkout files, not about whether their semantics should be made to match those of the like-named Unix commands. -- Andy Goth | andrew.m.goth/at/gmail/dot/com 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] Wiki Header Footers
Thus said Andy Goth on Mon, 03 Aug 2015 17:47:33 -0500: (by the way, why does the URL say config when the command is technically named configuration?) This is due to fossil's least unambiguous command matching, any unambiguous length of /configuration will work: http://fossil-scm.org/xfer/help/configuratio is unambiguous, http://fossil-scm.org/xfer/help/con is unambiguous, http://fossil-scm.org/xfer/help/co is ambiguous but treated as special, http://fossil-scm.org/xfer/help/c is ambiguous and returns an error Andy -- TAI64 timestamp: 400055c016f3 ___ 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] quick poll: do you generally use add/rm or mv
On Mon, Aug 3, 2015 at 9:04 PM, Ross Berteig r...@cheshireeng.com wrote: And then, there will be fresh set of edge cases with subtly different behavior on Windows. And for that matter, do all versions of Unix-descendents mv have the same quirks at the edges? IMHO, fossil does a remarkable job of handling rename now. I'm not sure what the ROI is for tuning the fossil mv command further... fwiw: +1 -- - 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] quick poll: do you generally use add/rm or mv
On 04/08/15 00:34, Ross Berteig wrote: On 8/3/2015 11:49 AM, Andy Goth wrote: On 8/3/2015 2:01 AM, Michai Ramakers wrote: On 3 August 2015 at 01:22, Matt Welland mattrwell...@gmail.com wrote: I've been using (and advising others to use) addremove because fossil mv behavior did not match Unix mv. The differences were confusing. I've no idea if fossil mv now behaves exactly like mv. indeed, it does not. Any plans to bring them in sync? I often have to make a few attempts until I get fossil mv to do what I want. And then, there will be fresh set of edge cases with subtly different behavior on Windows. And for that matter, do all versions of Unix-descendents mv have the same quirks at the edges? What are the issues? I do not use mv much (because I rarely move files and directories around) which is probably why I have not noticed anything, but it would be nice to know IMHO, fossil does a remarkable job of handling rename now. I'm not sure what the ROI is for tuning the fossil mv command further... Regarding the original question: I have never resorted to addremove when intending renaming/moving files because I find the rename records to be useful when tracing the ancestry of a file. Personally, I know of fossil addremove and never use it, for much the same reasons that Stephan mentioned. I almost never have clutter-free source trees, and addremove is just too all-inclusive for that work flow. I use addremove all the time. I works well as long as I do wish I could undo easily when I make mistakes with it. --dry-run help avoid them, as does being careful with ignore-glob settings, but I still make the occasional mistake. -- Graeme Pietersz http://moneyterms.co.uk/ http://pietersz.net/ ___ 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] Merging repositories
On 7/16/2015 11:12 PM, Andy Bradford wrote: Thus said Andy Bradford on Thu, 16 Jul 2015 20:56:57 -0600: Maybe rather than doing a pull, you could deconstruct both repositories, put the extracted artifacts into the same place, fabricate a manifest that somehow merges the two timelines with files from both trees? So I did both actually. I took two projects, pulled one into the other, then deconstructed the new thing. I then created a manifest that had all the requisite cards to ``merge'' the two independent trunks into one, however, because I had a file name collision, I had to pick one of them. Because they have no common ancestor, I don't think a diff can be generated. diff'ing shouldn't require a common ancestor. You're thinking of merging. merge's -baseline option lets you explicitly pick the common ancestor, which could be either trunk's initial empty check-in. -- Andy Goth | andrew.m.goth/at/gmail/dot/com 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] quick poll: do you generally use add/rm or mv
On 8/3/2015 11:49 AM, Andy Goth wrote: On 8/3/2015 2:01 AM, Michai Ramakers wrote: On 3 August 2015 at 01:22, Matt Welland mattrwell...@gmail.com wrote: I've been using (and advising others to use) addremove because fossil mv behavior did not match Unix mv. The differences were confusing. I've no idea if fossil mv now behaves exactly like mv. indeed, it does not. Any plans to bring them in sync? I often have to make a few attempts until I get fossil mv to do what I want. And then, there will be fresh set of edge cases with subtly different behavior on Windows. And for that matter, do all versions of Unix-descendents mv have the same quirks at the edges? IMHO, fossil does a remarkable job of handling rename now. I'm not sure what the ROI is for tuning the fossil mv command further... Regarding the original question: I have never resorted to addremove when intending renaming/moving files because I find the rename records to be useful when tracing the ancestry of a file. Personally, I know of fossil addremove and never use it, for much the same reasons that Stephan mentioned. I almost never have clutter-free source trees, and addremove is just too all-inclusive for that work flow. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ 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] quick poll: do you generally use add/rm or mv
On 8/3/2015 2:01 AM, Michai Ramakers wrote: On 3 August 2015 at 01:22, Matt Welland mattrwell...@gmail.com wrote: I've been using (and advising others to use) addremove because fossil mv behavior did not match Unix mv. The differences were confusing. I've no idea if fossil mv now behaves exactly like mv. indeed, it does not. Any plans to bring them in sync? I often have to make a few attempts until I get fossil mv to do what I want. Regarding the original question: I have never resorted to addremove when intending renaming/moving files because I find the rename records to be useful when tracing the ancestry of a file. -- Andy Goth | andrew.m.goth/at/gmail/dot/com 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] fine(r) commit granularity
On 7/28/2015 9:18 PM, Warren Young wrote: On Jul 28, 2015, at 9:32 AM, Gour g...@atmarama.net wrote: split commit within one file in smaller chunks when one forgets to ’safe often, commit often’ or simply wants to divide single commit into several ones? That said, it would be spiffy to have a “fossil ci --cherrypick” option that would ask me yes/no questions about each diff section, then commit all those I said “yes” to, leaving the “no” sections uncommitted. I've wanted this too, but I know it's a bad idea. The trouble is that each commit ought to first be tested (at least checked to be sure it compiles). Partial commits (even checking in only selected files) result in the committed version not matching the on-disk version therefore not being tested. When you realize you've made more than one check-in's worth of edits, run fossil stash save to save what you have and revert to your baseline. Do fossil stash show to review the not-yet-committed changes, and apply pieces by hand. Or do fossil stash apply to put all the remaining changes in place, then selectively back out changes. I do this in vim by opening a file, typing :new to vertically split with a new buffer, then typing :%!fossil cat FILENAME in that new buffer to load the committed version, then doing :diffthis in each buffer to get a side-by-side comparison. Many features are available, but usually I type do and dp to obtain and push changes between the current and other buffer. Another approach I've used when not using Fossil is to rename my changed files to have .new or such at the end of the name, revert to the last checked-in version, then pull changes from the .new one at a time, testing and committing after each. -- Andy Goth | andrew.m.goth/at/gmail/dot/com 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] fine(r) commit granularity
On Aug 3, 2015, at 1:08 PM, Andy Goth andrew.m.g...@gmail.com wrote: On 7/28/2015 9:18 PM, Warren Young wrote: On Jul 28, 2015, at 9:32 AM, Gour g...@atmarama.net wrote: split commit within one file it would be spiffy to have a “fossil ci —cherrypick” option ...it's a bad idea...each commit ought to first be tested...fossil stash save” Okay, how about this design, then: $ fossil stash save -m “several unrelated changes” $ fossil stash apply --partial ...fossil interactively asks whether to apply each diff chunk $ make test vi make test vi... $ fossil ci -m “one coherent change” $ fossil stash apply --partial ...another interrogation, skipping previously-applied chunks $ make test fossil ci -m “a second coherent change” ...GOTO 10 :) If you say “apply --partial” and Fossil sees that all stashed chunks are already applied, it could implicitly do “stash pop” instead, since there is no data loss. If you go through an “apply --partial” pass and accept none of the offered diff chunks, it could just ask if you meant to say “stash pop”, but not do it automatically. ___ 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] Idea: automatic check for extras prior to commit
On 3 August 2015 at 21:31, Andy Goth andrew.m.g...@gmail.com wrote:
Many times I've created files, modified existing files to reference
them, tested, and committed, only to later discover I forgot to add the
newly created files to the repository.
After making this mistake, I know I'm supposed to move the bad commit to
a hidden branch and try again. Usually I don't bother, especially if
there have been check-ins since the error was committed. Instead I just
add the omitted files as a new check-in. However, this complicates bisect.
In most of my projects I do a good job of maintaining the ignore-glob
setting, so fossil extras gives an accurate list of files I either need
to add to my check-in or add to ignore-glob.
It occurs to me the whole problem can be avoided by having a
check-extras setting which makes the commit command print a warning
requiring confirmation to proceed if there are any extra files. This
setting would be off by default but can be turned on for projects that
diligently maintain ignore-glob. The prompt might offer an option to
list the files, then (after the list is shown) ask if they all should be
added.
I usually run fossil extras along with fossil changes prior to doing
commit. If check-extras is turned on, I suggest having fossil changes
go ahead and list the extra-but-not-added files, marking them EXTRA but
not ADDED. This way I can run one command to get a complete list of
things pertinent to the next commit.
You mean that the same setting would apply to 'commit' and 'changes', right?
(In the case where '-m' is not given to 'commit', it could perhaps
list the extra files as
'EXTRA' in the currently displayed overview of files; I think that
would be hint enough
to the user.)
I would be very interested in a setting that makes 'fossil changes' also list
extra files. Checking for both 'extras' and 'changes' is an automatism here;
it's what I always want (never just just one but not the other).
To have that same setting apply to 'commit -m': I don't know. Sounds
like 2 different
settings to me. ('changes-also-list-extras' and
'commit-warn-about-extras' or so)
/EUR0.02
MIchai
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Idea: automatic check for extras prior to commit
Many times I've created files, modified existing files to reference them, tested, and committed, only to later discover I forgot to add the newly created files to the repository. After making this mistake, I know I'm supposed to move the bad commit to a hidden branch and try again. Usually I don't bother, especially if there have been check-ins since the error was committed. Instead I just add the omitted files as a new check-in. However, this complicates bisect. In most of my projects I do a good job of maintaining the ignore-glob setting, so fossil extras gives an accurate list of files I either need to add to my check-in or add to ignore-glob. It occurs to me the whole problem can be avoided by having a check-extras setting which makes the commit command print a warning requiring confirmation to proceed if there are any extra files. This setting would be off by default but can be turned on for projects that diligently maintain ignore-glob. The prompt might offer an option to list the files, then (after the list is shown) ask if they all should be added. I usually run fossil extras along with fossil changes prior to doing commit. If check-extras is turned on, I suggest having fossil changes go ahead and list the extra-but-not-added files, marking them EXTRA but not ADDED. This way I can run one command to get a complete list of things pertinent to the next commit. As for missing files, fossil commit currently fails if there are any. The error message isn't the most helpful in the world. It just reports no such file and the first file it couldn't find. Might be better to explain that the commit cannot proceed because there are a certain number of missing files, and list them. Would it be useful to expand check-extras to similarly offer to remove the missing files? This is certainly open for debate. Getting further afield... the other warnings shown by fossil commit can stand to be improved. I recall character conversion problems are reported only one at a time, so I can't fix them all at once. If the facility to prompt for a list of all offending files is added for the sake of extra and missing files, it could be used to list files with non-UTF8 and carriage returns. Maybe even merge the lists, prefixing each line with EXTRA or MISSING or NON_UTF8 or CRLF. Oops, Fossil refers to CRLF as CRNL... that's always confused me. Even further off-topic... does Fossil squawk about files using CR alone or LFCR? -- Andy Goth | andrew.m.goth/at/gmail/dot/com 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] Merging repositories
Thus said Andy Goth on Mon, 03 Aug 2015 13:40:39 -0500: diff'ing shouldn't require a common ancestor. You're thinking of merging. merge's -baseline option lets you explicitly pick the common ancestor, which could be either trunk's initial empty check-in. Yes, you're right, I was thinking of merging. And I was unaware of the -baseline option for merge, so that certainly would be a better option than crafting one's own manifest. Thanks, Andy -- TAI64 timestamp: 400055bfc322 ___ 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] fine(r) commit granularity
On 3 August 2015 at 21:08, Andy Goth andrew.m.g...@gmail.com wrote: On 7/28/2015 9:18 PM, Warren Young wrote: On Jul 28, 2015, at 9:32 AM, Gour g...@atmarama.net wrote: split commit within one file in smaller chunks when one forgets to ’safe often, commit often’ or simply wants to divide single commit into several ones? That said, it would be spiffy to have a “fossil ci --cherrypick” option that would ask me yes/no questions about each diff section, then commit all those I said “yes” to, leaving the “no” sections uncommitted. ... I do this in vim by opening a file, typing :new to vertically split with a new buffer, then typing :%!fossil cat FILENAME in that new buffer to load the committed version, then doing :diffthis in each buffer to get a side-by-side comparison. Many features are available, but usually I type do and dp to obtain and push changes between the current and other buffer. Thanks for reminding me - Vim's diff-functionality is indeed excellent for this, I use it often for side-by-side differ, not to get/put chunks of code - nice. Something similar in one line for Bash-users: vim -d myfile ( fossil cat myfile ) FWIW, I try to have small commits here; occasionally when unrelated changes have been made in a single file, I simply use the word 'and' in the commit-message, and that's about it. I agree that manually To make check-in of a selection of the changed files, some suggestions were made on this list other than doing 'fossil commit file1 file2 ...'; perhaps Fuel (https://fuel-scm.org/fossil/index) is interesting, but I haven't tried it myself. (But then again, I don't think this was the original Q.) Michai ___ 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] fine(r) commit granularity
grr... On 3 August 2015 at 21:50, Michai Ramakers m.ramak...@gmail.com wrote: FWIW, I try to have small commits here; occasionally when unrelated changes have been made in a single file, I simply use the word 'and' in the commit-message, and that's about it. I agree that manually ...selecting chunks of code to check in is not something I would do often, if ever. Michai ___ 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] quick poll: do you generally use add/rm or mv
On 1 August 2015 at 17:46, Michai Ramakers m.ramak...@gmail.com wrote: Hello, I was wondering what you generally do for directory trees in motion - use add/rm or mv ? And: the benefit of fossil having a concept of 'moved file/dir' is that the user can trace ancestry crossing moves/renames more easily, is that correct? (At least that's how I use it now.) meta-question: if I wanted to write a small description of how exactly 'mv' behaves w.r.t. file- and dir-argument(s), and perhaps compare to *nix 'mv', what would be the place for this? The 'mv' command-help page, or a separate wiki-page? I think perhaps this falls somewhere in between. Michai ___ 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] Idea: automatic check for extras prior to commit
On Aug 3, 2015, at 1:31 PM, Andy Goth andrew.m.g...@gmail.com wrote: Many times I've created files, modified existing files to reference them, tested, and committed, only to later discover I forgot to add the newly created files to the repository. Yup, been there. :) After making this mistake, I know I'm supposed to move the bad commit to a hidden branch Who supposes this, and why do you take their opinion as normative? I thought I saw reference on this list to a way to lop off the most-recent checkin on a particular branch, but I couldn’t figure out how the last time I tried. Is this the mechanism? Usually I don't bother, especially if there have been check-ins since the error was committed. Wouldn’t a better solution to that problem be a continuous integration system, so you get an email shortly after committing a change that breaks the build? Then your risk window shrinks to the CI rebuild time. Maybe even merge the lists, prefixing each line with EXTRA or MISSING or NON_UTF8 or CRLF. I rarely run into this one, since I normally just say “all” when asked if I really meant to do that, since I usually did mean to. Then I go and hack on the relevant *-glob setting. Oops, Fossil refers to CRLF as CRNL... that's always confused me. Ditto. Why fight ASCII on naming here? does Fossil squawk about files using CR alone or LFCR? Yes: $ file foo.c # inverse-DOS line endings (LFCR) foo.c: ASCII C program text, with CRLF, CR, LF line terminators $ file bar.c # Mac OS classic line endings (CR) bar.c: ASCII C program text, with CR line terminators $ f ci ./foo.c contains mixed line endings. Use --no-warnings or the crnl-glob” setting to disable this warning. Commit anyhow (a=all/c=convert/y/N)? n ./bar.c contains CR line endings. Use --no-warnings or the crnl-glob setting to disable this warning. Commit anyhow (a=all/c=convert/y/N)? n $ ___ 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] quick poll: do you generally use add/rm or mv
On Aug 3, 2015, at 12:49 PM, Andy Goth andrew.m.g...@gmail.com wrote: On 8/3/2015 2:01 AM, Michai Ramakers wrote: On 3 August 2015 at 01:22, Matt Welland mattrwell...@gmail.com wrote: I've no idea if fossil mv now behaves exactly like mv. indeed, it does not. Any plans to bring them in sync? We had a long thread about it months ago: http://lists.fossil-scm.org:8080/pipermail/fossil-users/2015-March/019997.html So far as I know, drh’s opinion remains: http://lists.fossil-scm.org:8080/pipermail/fossil-users/2015-March/020055.html ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
