Re: [fossil-users] forget binary files
On 4 August 2015 at 06:09, Stephan Beal sgb...@googlemail.com wrote: On Tue, Aug 4, 2015 at 12:04 PM, Luca Ferrari fluca1...@infinito.it wrote: On Tue, Aug 4, 2015 at 11:31 AM, Stephan Beal sgb...@googlemail.com wrote: http://www.fossil-scm.org/index.html/help?cmd=/shun In that case you would have to shun all of the files individually. Fossil, by design, makes it exceedingly difficult to change history, and that includes removing files. Shunning is really only intended to be used when someone checks in sensitive or malicious data. But it's a reasonable way to remove binaries that you don't want. Just be careful not to shun 0 length files or you won't be able to commit a 0-length file until you've cleared the shun table (because all 0-length files have the same SHA-1 id. ../Dave ___ 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] forget binary files
On Tue, Aug 4, 2015 at 1:02 PM, David Mason dma...@ryerson.ca wrote: But it's a reasonable way to remove binaries that you don't want. Indeed - my point was only that shunning as a feature is _primarily_ intended as a way to remove sensitive or malicious stuff. Just be careful not to shun 0 length files or you won't be able to commit a 0-length file until you've cleared the shun table (because all 0-length files have the same SHA-1 id. Excellent point, though it's hard to imagine such files being either binary or holding sensitive data (except maybe in their name... hmmm interesting corner case). -- - 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] forget binary files
On Tue, Aug 4, 2015 at 1:47 PM, Sergei Gavrikov sergei.gavri...@gmail.com wrote: I know one, that's 'The Infinitely Profitable Program' http://peetm.com/blog/?p=55 :-) To summarize: GO.COM contained no program bytes at all – it was entirely empty. However, because GO.COM was empty, but still a valid program file as far as CP/M was concerned (it had a directory entry and file-name ending with .com), the CP/M loader, the part of the OS whose job it is to pull programs off disk and slap them into the TPA, would still load it! Wow. i like to think that wouldn't be possible today. But, who knows... it's potentially possible to encode a whole virus in a long filename of an empty file, sharing the same hash as all other empty files. -- - 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] forget binary files
On Tue, Aug 4, 2015 at 12:04 PM, Luca Ferrari fluca1...@infinito.it wrote: On Tue, Aug 4, 2015 at 11:31 AM, Stephan Beal sgb...@googlemail.com wrote: http://www.fossil-scm.org/index.html/help?cmd=/shun shunning is the only way to remove something and should be considered a last resort option. Thanks, but not quite what I was searching for: I need to remove a full tree of files, so I don't have an exact SHA artifact, if I get it right. In that case you would have to shun all of the files individually. Fossil, by design, makes it exceedingly difficult to change history, and that includes removing files. Shunning is really only intended to be used when someone checks in sensitive or malicious data. -- - 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] forget binary files
On Tue, 4 Aug 2015, Stephan Beal wrote: On Tue, Aug 4, 2015 at 1:02 PM, David Mason dma...@ryerson.ca wrote: Just be careful not to shun 0 length files or you won't be able to commit a 0-length file until you've cleared the shun table (because all 0-length files have the same SHA-1 id. Excellent point, though it's hard to imagine such files being either binary or holding sensitive data (except maybe in their name... hmmm interesting corner case). I know one, that's 'The Infinitely Profitable Program' http://peetm.com/blog/?p=55 :-) Sergei___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] forget binary files
Hi, this may sound stupid, but once I've mistakenly committed binary files, is there a way to remove them from the repository at all? My attempt is (i) to not version such files and (ii) reduce repository size. Thanks, 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] forget binary files
On Tue, 4 Aug 2015, Stephan Beal wrote:
On Tue, Aug 4, 2015 at 1:47 PM, Sergei Gavrikov sergei.gavri...@gmail.com
wrote:
I know one, that's 'The Infinitely Profitable Program'
http://peetm.com/blog/?p=55 :-)
To summarize:
GO.COM contained no program bytes at all – it was entirely empty. However,
because GO.COM was empty, but still a valid program file as far as CP/M was
concerned (it had a directory entry and file-name ending with .com), the CP/M
loader, the part of the OS whose job it is to pull programs off disk and slap
them into the TPA, would still load it!
Wow. i like to think that wouldn't be possible today. But, who
knows... it's potentially possible to encode a whole virus in a long
filename of an empty file, sharing the same hash as all other empty
files.
[OFF-TOPIC]
I used GO.COM recently on one modern LEON3 target in self cooked
boot-loader. I used XMODEM to upload binary files and I looked for a way
to run application and return to the loader and return back (quickly) to
loaded application again. From my local web-log (jemdoc mark-down):
== 2015\/01\/12
Implement +Th_Eval2()+. In first, +Th_Eval2()+ does try to find a dot-com file
on CFS.
=== GO.COM
- [http://peetm.com/blog/?p=55]
It works!
~~~
{}{}
0 qm ls
hello.tcl init GO.COM HELLO.COM
0 qm HELLO
HELLO, WORLD!
0 qm GO
HELLO, WORLD!
~~~
BTW, +GO.COM+ was created as
~~~
{}{}
0 qm write GO.COM
~~~
Well, my COMMAND.COM on the target was TH1 interpreter :-)
Sergei___
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] forget binary files
On Tue, Aug 4, 2015 at 11:31 AM, Stephan Beal sgb...@googlemail.com wrote: http://www.fossil-scm.org/index.html/help?cmd=/shun shunning is the only way to remove something and should be considered a last resort option. Thanks, but not quite what I was searching for: I need to remove a full tree of files, so I don't have an exact SHA artifact, if I get it right. out of curiosity: did the binaries get added via the 'addremove' command? No, it was mistakenly added in a previous repo and then 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] forget binary files
On Tue, Aug 4, 2015 at 11:22 AM, Luca Ferrari fluca1...@infinito.it wrote: Hi, this may sound stupid, but once I've mistakenly committed binary files, is there a way to remove them from the repository at all? My attempt is (i) to not version such files and (ii) reduce repository size. see: http://www.fossil-scm.org/index.html/help?cmd=/shun shunning is the only way to remove something and should be considered a last resort option. out of curiosity: did the binaries get added via the 'addremove' command? -- - 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] Idea: automatic check for extras prior to commit
On Tue, 4 Aug 2015, Ron W wrote: On Tue, Aug 4, 2015 at 11:37 AM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Aug 4, 2015 at 5:23 PM, Ron W ronw.m...@gmail.com wrote: I think this would be a useful feature. To me this all sounds like fossil enforcing project-specific policy, which is something it most certainly should not be doing. I was commenting on the specific suggestion of a fossil check command, that would perform the same checks that fossil commit already does. It's possible that the --dry-run option for commit MIGHT be used for the same effect. Right now, not able to try it to examine its behavior. Yet another solution would to implement some test command(s), e.g. 'test-somewhat-sane'. I would like such checks if they would run in the times faster than ``fossil extras'' or ``fossil changes''. If tested state is dirty the command found at least *one* change, or missing, or extra, it just prints dirty and exits. Or may be ``fossil status'' command is right place to mark the dirty state, though that is slow and heavyweight command. Sergei ___ 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 4:35 PM, Andy Goth andrew.m.g...@gmail.com wrote: 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: Any plans to bring them in sync? We had a long thread about it months ago: 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. I don’t see the distinction. Fossil currently forces a two-step mv, which is different from *every other popular F/OSS VCS* except for CVS, and that’s only because CVS doesn’t have mv at all. Fossil also forces a two-step rm. F/OSS VCSes vary quite a bit in behavior here, as I cataloged here: http://lists.fossil-scm.org:8080/pipermail/fossil-users/2015-March/020032.html That said, I think we have a well-considered exemplar to emulate: https://www.selenic.com/mercurial/hg.1.html#remove As for questions about how to deal with OS semantics, I don’t think we have a real problem here. File deletion semantics are straightforward on all OSes Fossil runs on. The hg rm design shows how the VCS and OS can interact in a safe way. As for file *move* semantics, the only tricky bit is how to handle moves across filesystems, but that’s irrelevant to Fossil since there is no way to “open” a Fossil repo so that it spans filesystems. (Well, not without OS help, which would paper over the mv semantics problem, too.) Bottom line: Fossil doesn’t have to blaze trail on this. There are already well-trod paths. ___ 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 4, 2015, at 1:53 PM, Joe Mistachkin sql...@mistachkin.com wrote: Warren Young wrote: Fossil currently forces a two-step mv No, it doesn't. Fossil now has the --hard option for mv/rm. Ah, I completely missed the announcement of that feature. However, this feature is not available by default, as you seem to be saying, at least in trunk. You must say: ./configure --with-legacy-mv-rm for the mv-rm-files option to be available. It’s documented at the bottom of /setup_settings, but if you configure without options, there is no UI field for it, and you get this on the command line: $ fossil set mv-rm-files 1 no such setting: mv-rm-files $ f ver This is fossil version 1.33 [0a2ebe576d] 2015-08-03 18:35:53 UTC Also, I’d say this configure option and the underlying C macro it defines is named confusingly. I’m not “enabling legacy mode” here, I’m enabling a preview of a future default feature. ___ 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 4, 2015, at 1:18 PM, Warren Young w...@etr-usa.com wrote: On Aug 4, 2015, at 8:51 AM, Ron W ronw.m...@gmail.com wrote: Also, if pop --partial were also implemented I think “pop --partial” only makes sense if it actually modifies the stash to contain only the un-popped partial changes, which seems a bit…excessive for v1 of this feature. I’ve rethought this. “fossil stash pop --partial” would be easier to implement than apply --partial. It would be insufficient for apply --partial to just learn to recognize already-applied diff chunks as patch(1) does, because the chunks might have been modified before being checked in. Thus, a robust implementation of apply --partial would need to have a list of chunks you previously said “yes” to, so it can skip them the next time. Because pop --partial could just rewrite the stash after each run, it wouldn’t need that secondary storage area, making it considerably easier to write. ___ 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 4:20 PM, Andy Goth andrew.m.g...@gmail.com wrote: On 8/3/2015 3:24 PM, Warren Young wrote: I thought I saw reference on this list to a way to lop off the most-recent checkin 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. Nice, thank you! I will certainly find uses for this. I especially like the one-step “move and hide” behavior, with live updating of the UI via JS as you change the branch name. Someone was thinkin’ there. :) ___ 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 4, 2015, at 8:51 AM, Ron W ronw.m...@gmail.com wrote: An implicit pop would be contrary to the normal behavior of apply”. That’s fine. It’s very much a nonessential part of the design. Just trying to save someone a step there. Also, if pop --partial were also implemented, not popping would be contrary to its normal behavior, though would be a less shocking surprise. I think “pop --partial” only makes sense if it actually modifies the stash to contain only the un-popped partial changes, which seems a bit…excessive for v1 of this feature. ___ 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
Warren Young wrote: Fossil currently forces a two-step mv, which is different from *every other popular F/OSS VCS* except for CVS, and that's only because CVS doesn't have mv at all. No, it doesn't. Fossil now has the --hard option for mv/rm. Also, it can be compiled in such a way that --hard is the default. -- Joe Mistachkin ___ 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 Tue, Aug 4, 2015 at 11:37 AM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Aug 4, 2015 at 5:23 PM, Ron W ronw.m...@gmail.com wrote: I think this would be a useful feature. To me this all sounds like fossil enforcing project-specific policy, which is something it most certainly should not be doing. Case in point: [odroid@host:~/fossil/cwal/s2]$ ls -d * 1mod_porex.c s2_protos.o 1.bmod_porex.o s2sh 1.csvmod_porex.s2 s2sh.history 1.emod_porex.so s2sh.s2 huge snip mod_popen.os2_pf.c Z.s2 mod_popen.s2s2_pf.o mod_popen.sos2_protos.c [odroid@host:~/fossil/cwal/s2]$ ls -1 | wc -l 166 [odroid@host:~/fossil/cwal/s2]$ ls -1 *.c *.h Makefile *.sh *.?pp | wc -l 46 roughly 1/4th of those files are in source control, and it would absolutely kill me for fossil to say, hey, buddy, you've got 120 files I don't know about! Do something about that before continuing! To which my response would most certainly be a chain of expletives. Maintaining an ever-growing ignore-glob for an arbitrary number of globs, just to enforce a policy invoked in _someone else's project_ would be a highly unattractive option. -- - 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] Idea: automatic check for extras prior to commit
On Tue, Aug 4, 2015 at 11:37 AM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Aug 4, 2015 at 5:23 PM, Ron W ronw.m...@gmail.com wrote: I think this would be a useful feature. To me this all sounds like fossil enforcing project-specific policy, which is something it most certainly should not be doing. I was commenting on the specific suggestion of a fossil check command, that would perform the same checks that fossil commit already does. It's possible that the --dry-run option for commit MIGHT be used for the same effect. Right now, not able to try it to examine its behavior. Maybe this should go in a new thread to reduce confusion. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
