Yann Dirson wrote: > On Wed, Nov 25, 2009 at 05:35:17PM -0500, Joey Hess wrote: > > > > If you'd like to alias mr = mr -p > > > > > > Rather than that, what about adding support for making it the default > > > in ~/.mrconfig ? Well, not exactly that, since that would imply "read > > > ~/.mrconfig first, and then if this flag is specified, search for an > > > additional .mrconfig upstairs." - that would also match the behaviour > > > of other tools (like git's ~/.config and .git/config). > > > > mr does read ~/.mrconfig first. > > Well, the doc for -p may be wrong then, it reads: "use the first > .mrconfig found, instead of the default ~/.mrconfig."
Rechecked, docs are right. > > > Something could be added, perhaps in > > the ALIAS section, to enable options by default. I'm not sure though, > > how this is better than shell aliases? > > Well, it's mostly that intuitively I feel this should be the default > behaviour, and not the business of a shell alias :) I can understand that. I tend to agree with you; I want both that and enabling trust checking to both be defaults (you really need both for safety, just to guard against mr -p finding some mrconfig you didn't expect it to), but have not changed either yet since it could suprise existing users. > In some way, maybe .mrconfig is too much flexible. It contains both > information that are safe and useful to version-control (eg. lists of > repositories), and information that is potentially disastrous if > misused (command definitions). This is true, and it's what the untrusted mrconfig code handles, by only allowing untrusted mrconfig files to contain safe stuff. > - split the funtionnality into 2 files (one on which .mrtrust would > have no influence), or ignore potentially-harmful decls from > non-trusted mrconfigs I did consider using two files when implementing trust checking, but decided it made more sense to have one file with one format and check its content. > - extend mrtrust functionnality to include a hash of the trusted > mrconfig (those that have been reviewed), possibly with a new > command to help dealing with the issue (show what changed since last > trusted version, insert hash when accepted) > > - extend mrtrust functionnality include the individual declarations > accepted/reviewed from the given mrconfig, so only the new/changed > decls would have to be reviewed on change (would also come with a > helper command) > > Do you think that would make sense ? I'm not sure yet if such a thing is necessary. So far, the very limited commands that are allowed in untrusted mrconfig files (git clone, svn checkout, etc) have been sufficient to do useful things with the files. Adding a review burden on the user could be really annoying. -- see shy jo
signature.asc
Description: Digital signature
