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." > 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 :) > > Well, couldn't the problem about trusting files be solved in a less > > intrusive way ? I would suggest to refuse loudly to use a .mrconfig > > with improper write permissions > > The issue is not really local write permissions, it is mrconfig files that > others may edit via VCS. Hm, I think I see what you mean. Kind of related to the reason why the .git contents (config and hooks) are not part of the versionned data. > For example, I've proposed that d-i convert to > git and use a toplevel mrconfig file to list all the git repositories. 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). The problem seems to boil down to "I have to trust repo decls from this .mrconfig, but want to review any change done to commands." Possibilities I can see to address this would be: - split the funtionnality into 2 files (one on which .mrtrust would have no influence), or ignore potentially-harmful decls from non-trusted mrconfigs - 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 ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
