On 12/11/12 23:08, K wrote: > I agree with Themba. I like that Fossil is a separate repo 'world' from my > files. If this boundary is to be pierced, I think it should require passing > in some kind of explicit switch to cause it. eg., ./fossil -s rm ..., s in > this example representing "sync". > > I would like some friendly tip text after rm/et al are ran, such as: > > "You have removed file1.h, file1.c from repo foo, you may want to remove them > from your working copy."
> Seems like a great way to remind, teach, and help all in-context and with > minimal overhead. Say during your lifetime you'll (re)move 1000 files in fossil repositories. That means you'll in practice perform 2000 (re)move operations (once in metadata, and once in the filesystem). At what point would one expect to have been sufficiently reminded and taught how to (re)move files? Personally, I have never learned anything of value from having to (re)move files twice. And I don't really buy the "It's safer" argument either. I have several times become confused over what operations I have actually performed because the file-system isn't in sync with the operations I have performed; and becoming confused over what operations one has performed because the filesystem doesn't reflect it is not "safe". I'm willing to bet that the number of times people will type "fossil mv/rm X Y" and not actually want to mv/rm X to Y just afterwards is vanishingly small. More to the point; let's reverse your "-s"-flag; I.e.: $ fossil mv X Y ... renames X to Y (metadata and filesystem). $ fossil -d mv X Y ... as in "Don't actually move" will only change the metadata, and the user can then use the mv command afterwards to manually rename/move the file in the filesystem. The last option doesn't make any sense at all. Which is sort of my point.. I think such an option would be used roughly zero times; but your proposed "-s" would be used almost 100% of the time (when people learn about it). And this goes back to that "ten things I hate about git"-list; when commands counter-intuitively require extra flags to get the canonical behavior. (I did some serious refactoring recently which involved lots of mv and a few rm, and it really annoyed me that my computer, which is supposedly a machine for automating tasks, required me to perform an extra manual step for each mv and rm). (Yes, I ended up scripting it in the end .. but that just further annoyed me; why do I need to script operations in fossil to get the canonical behavior?). I too am a little skeptical about adding too many settings to fossil, but this is definitely one that I would think merits a setting if the current (default) behavior is kept in 2.0. Sorry if this came out as a rant; it's not directed at anyone personally, but like I said, I battled fossil rm/mv recently and I'm still not completely over it. No flame-bait intended. -- Kind regards, Jan Danielsson _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
