On 2 February 2012 10:54, Jeff King <peff@xxxxxxxx> wrote: > On Thu, Feb 02, 2012 at 10:44:05AM +0100, demerphq wrote: > >> The general design of git seems to me to be based around providing >> building blocks that people can use to build new and interesting tools >> on top of, and so it seems counter to that philosophy to reject an >> feature based on speculative security issues that really can't be >> decided in advance but must instead be decided on a case by case >> basis. > > I can't speak for Junio, but I am certainly not rejecting it. Only > saying that it needs to be thought through, and the utility weighed > against the costs. Of course. I totally understand. I have written mails saying stuff like this myself. :-) > So far I haven't seen an actual patch to comment on > (or even a proposed syntax beyond starting a string with "!", which I > think is a non-starter due to conflicting with existing uses), I understand. I think we will probably use backtick quoting in git-deploy. So deploy.prefix=`cat /etc/SERVER_ROLE` will execute cat /etc/SERVER_ROLE and use the results as the value of the config option. > nor have > I seen a concrete use case (you mentioned pulling the name/email from > ldap, but you also mentioned that there are lots of other ways of > solving that particular problem, so it's not especially compelling). One place that it would be useful for us in git-deploy would be to detect the tag prefix for the rollout we are doing. Every staging server already has a file that contains this value. We would like to make it easy for people to configure the tool to either use the value provided, or to use something like `cat /etc/SERVER_ROLE` instead. Anyway, from that POV I could totally understand "so do that in git-deploy". Since the tool is written in perl we have to wrap git-config anyway, so it easy to add a special case for ourselves. But I still think the general idea is pretty useful, the ldap example is IMO a cleaner solution than the alternatives, and a variant that I think is much harder to do currently come to mind right away: setting the user.email automatically depending on where in your tree a git repo was located, so that when I work on repo underneath /CPAN/ it uses my CPAN address, and when I work in my /work/ tree it uses my $work address, etc, without me having to configure it repo by repo. (This has bitten more than once in the past) > I'd be happy to hear a more concrete proposal. I will be mostly afk the next week so I will leave that to Avar if he wants to pursue it. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html