[fossil-users] RFC: new config option
Hiho, In a repo of mine (not fossil) i just made a commit faux pas by not entering the _one_ filename i wanted on the command line, and instead committing several others i wasn't ready to commit. So now i want to add a fossil feature but thought i'd run it through the crowd for opinions or alternatives before i code a feature of out frustration ;). The hypothetical usage and effect would look like this: $ fossil config set empty-commit-warn $ fossil commit -m '...' No file names provided. Really continue? [y/N] The warning would only show if empty-commit-warn (or whatever name we chose) is on, of course (default=off). :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] RFC: new config option
On Jun 21, 2013 9:32 AM, Stephan Beal sgb...@googlemail.com wrote: Hiho, In a repo of mine (not fossil) i just made a commit faux pas by not entering the _one_ filename i wanted on the command line, and instead committing several others i wasn't ready to commit. So now i want to add a fossil feature but thought i'd run it through the crowd for opinions or alternatives before i code a feature of out frustration ;). The hypothetical usage and effect would look like this: $ fossil config set empty-commit-warn $ fossil commit -m '...' No file names provided. Really continue? [y/N] I realize this check is early in the commit phase, but now I wonder: barring pushed/autosync'd content, can one pop or unwind the last commit of a local repo? The warning would only show if empty-commit-warn (or whatever name we chose) is on, of course (default=off). :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] RFC: new config option
On Fri, Jun 21, 2013 at 1:35 PM, B Harder brad.har...@gmail.com wrote: I realize this check is early in the commit phase, but now I wonder: barring pushed/autosync'd content, can one pop or unwind the last commit of a local repo? An uncommit command has been on the to-do list for a long time, but has not yet been implemented. Note that uncommit is considerably less useful in Fossil compared to Git, since Fossil normally has autosync turned on so that your content gets pushed automatically right after the commit in most cases. And everybody agrees that uncommit is not feasible once you have pushed. When you want to undo a check-in in Fossil, the typical procedure is to move that check-in off into a dead-end branch named error or mistake. Example here: http://www.fossil-scm.org/fossil/timeline?n=8c=2011-06-16+18:10:54y=ci VCSes that have an uncommit command allows one to airbrush out embarrassing missteps. Fossil, on the other hand, forces us to own up to our errors. Fossil: Encouraging confession, penitence, and humility since 2007 ;-) -- 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] RFC: new config option
On Jun 21, 2013 11:02 AM, Richard Hipp d...@sqlite.org wrote: On Fri, Jun 21, 2013 at 1:35 PM, B Harder brad.har...@gmail.com wrote: I realize this check is early in the commit phase, but now I wonder: barring pushed/autosync'd content, can one pop or unwind the last commit of a local repo? An uncommit command has been on the to-do list for a long time, but has not yet been implemented. Note that uncommit is considerably less useful in Fossil compared to Git, since Fossil normally has autosync turned on so that your content gets pushed automatically right after the commit in most cases. And everybody agrees that uncommit is not feasible once you have pushed. Re: not feasible once pushed - that is understood. Whether an uncommit would be considerably less useful is not clear to me though. I too have made accidental commits where I'm working on a feature, and go on a slight tangent, or have stray un-stashed work and end up committing more than I want. I usually just end up amending the commit msg. I fossilize the vast majority of my personal work, which isn't collaborative, and not autosync'd. I'd be surprised if there aren't many more like me. I suspect it's the nature of this sort of work that we don't hear about it because it's small and personal, versus a big public fossil projects like Tcl or SQLite. If the discussion is all about big projects and how to utilize fossil, autosync is arguably a smart option. I'm a little curious what thelong tail of fossil projects looks like. I can say for *my* work though, I'd get value out of an uncommit command. When you want to undo a check-in in Fossil, the typical procedure is to move that check-in off into a dead-end branch named error or mistake. Example here: http://www.fossil-scm.org/fossil/timeline?n=8c=2011-06-16+18:10:54y=ci VCSes that have an uncommit command allows one to airbrush out embarrassing missteps. Fossil, on the other hand, forces us to own up to our errors. Fossil: Encouraging confession, penitence, and humility since 2007 ;-) I completely agree and appreciate this, but I think making an exception for the undistributed TIP commit isn't too offensive to the spirit. -- 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] RFC: new config option
On Fri, Jun 21, 2013 at 8:01 PM, Richard Hipp d...@sqlite.org wrote: An uncommit command has been on the to-do list for a long time, but has not yet been implemented. And i've only missed it once or twice - i know this is a corner case and impossible when syncing is on. Note that uncommit is considerably less useful in Fossil compared to Git, since Fossil normally has autosync turned on so that your content gets pushed automatically right after the commit in most cases. And everybody agrees that uncommit is not feasible once you have pushed. i had, incidentally, turned off autosync by accident because i thought that two 'opens' of the same repo did not share that setting (i have a test copy which i don't want to autosync, but i just realized 4 minutes ago that they share that setting). So in this once in a million case i could have used an uncommit, but autosync is normally always on. So IMO it's not worth the implementation hassle (it wouldn't/couldn't help me very often, in any case). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] RFC: new config option
On 6/21/2013 9:32 AM, Stephan Beal wrote: Hiho, In a repo of mine (not fossil) i just made a commit faux pas by not entering the _one_ filename i wanted on the command line, and instead committing several others i wasn't ready to commit. So now i want to add a fossil feature but thought i'd run it through the crowd for opinions or alternatives before i code a feature of out frustration ;). The hypothetical usage and effect would look like this: $ fossil config set empty-commit-warn $ fossil commit -m '...' No file names provided. Really continue? [y/N] The warning would only show if empty-commit-warn (or whatever name we chose) is on, of course (default=off). How about a pre-commit script? Maybe in TH1 or TCL or run-a-local-program, etc. I know the general case of script hooks has been discussed before and there are difficulties due to the distributed nature of things, not to mention security and portability concerns. But... what about per-user script hooks? I don't know if that has been discussed. They'd live in ~/.fossil and hopefully avoid the complications of the general case. I'd envision the scripts as applying to all repositories, but giving the script access to the project-id so it could limit itself to certain repositories if desired. One drawback is that you'd have to setup your scripts by hand on each system you develop on. Just a thought. -- Edward Berner ___ 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] RFC: new config option
On Fri, Jun 21, 2013 at 9:42 PM, Edward Berner e...@bernerfam.com wrote: But... what about per-user script hooks? This would certainly be a perfect use case for them. i can't speak to the security concerns. On a related note, there is a precedence for such an option: mysql client does not allow UPDATE given on the command line without a WHERE clause unless you specify a certain other option: [stephan@host:~/cvs/fossil/cwal/th1ish]$ mysql --help | grep dummy -U, --i-am-a-dummy Synonym for option --safe-updates, -U. i-am-a-dummy FALSE But adding --i-am-a-dummy to allow no-file-name commits in fossil would be backwards-incompatible ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] RFC: new config option name
Hiya! The JSON API returns errors in the form of 4-digit error codes, as described here: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/edit?hl=en_US The codes are grouped such that we can dumb down error codes to be less specific (w/ 3 levels of specificity), for the sake of not revealing potentially security-relevant codes to clients. The dumbing-down support is implemented but currently uses a hard-coded dumb-down level (called g.json.errorDetailParanoia) which i would like to switch to a configuration option. But what to call it? json-paranoia-level? json-error-dumbdown-level? something complete different? -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
