On Mon, Mar 05, 2012 at 09:23:19AM -0800, Junio C Hamano wrote: > I think there were talks about cross pollinating and eventually > unifying the placeholder languages of pretty and for-each-ref, and > if we were to do so, I agree that --pretty definitely should learn > to do --sq. But I do not think we want to teach everything :shell; > following the style of %w(), something more generic that would apply > to any payload would be preferred, perhaps giving an end result like > this: > > git show -s --format=' > GIT_AUTHOR_NAME=%(sq-begin)%an%(sq-end) > GIT_AUTHOR_EMAIL=%(sq-begin)%ae%(sq-end) > ' > > which would be immediately `eval`-able. Yeah, that could work. I didn't want to teach everything :shell individually. I was hoping eventually for a world where "%(foo:one:two=bar)" was internally parsed into "the foo item, with attribute one set, and attribute two set to bar". And then the "shell" attribute would have a particular meaning for everything, whereas in "%(authordate:format=short)", the "format" attribute would be specific to that item. I think that makes for a more readable syntax. However, your proposal does allow quoting multiple entities at a time, like: IDENT=%(sq-begin)%an <%ae>%(sq-end) which could be useful. Anyway, there is not much point in discussing hypothetical syntaxes. I think we agree that some form of this feature would be an ideal way forward in the long term, but specifics can wait until somebody shows up with patches. > In any case, my reading of the conclusion you guys have already > reached in this thread is that the issue is not even a bug in Git, > but is a broken build/installation of sed by a third-party. I am > inclined to suggest any change to get_author_ident_from_commit > helper backburnered before we teach --sq to --pretty machinery. I think that is true. It could be considered a bug in git if we were relying on an unportable sed construct. But it works everywhere else, and we already go to the effort to set LANG and LC_ALL, so I am inclined to say that it is not a portability issue in git, but a crappy sed implementation, and the right solution is to use a better one. We could switch the use of sed to perl (even just using 5.005-ish features, which are pretty portable), but until now, users of git-sh-setup don't need to rely on having perl at all. So I'm fine with leaving it for now and telling people to fix their sed. -Peff -- 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