From: Jeff King <peff@peff.net>
To: Dietmar Winkler <dietmarw@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [Bug] %[a|c]d placeholder does not respect --date= option in combination with git archive
Date: Sat, 5 Mar 2011 14:50:20 -0500 [thread overview]
Message-ID: <20110305195020.GA3089@sigill.intra.peff.net> (raw)
In-Reply-To: <4D70BA9C.1080902@gmx.de>
On Fri, Mar 04, 2011 at 11:10:36AM +0100, Dietmar Winkler wrote:
> Well in
> http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html it says:
>
> "The placeholders are the same as those for the option
> --pretty=format: of git-log(1), except that they need to be wrapped like
> this: $Format:PLACEHOLDERS$ in the file."
>
> And in git log the list includes (besides the various date formats) also
>
> %ad: author date (format respects --date= option)
> ...
> %cd: committer date *
>
> *) actually here the string "(format respects --date= option)" is
> missing. Otherwise what committer date format are we speaking about ;)
>
> So either the documentation should make clear that the substitution will
> *not* work or (and this would be preferable) fix the substitution so
> that it works as documented.
Yeah, the documentation is misleadingly vague there. I've improved it in
the patch series below.
> > I remember at some point discussing extending the specifier syntax to
> > allow things like "%(ad,date=short)", but it was never implemented. I
> > think that would be the cleanest way to do what you want.
>
> Yes that would be even better since it would give one the freedom of
> defining different format for the subsitutions in different places in a
> project. Shame it was not accepted.
I think we got bogged down in what exactly the extended format should
look like and then nothing got done. I spent a few hours yesterday
looking again at how bad it would be to extend the syntax to handle both
the traditional format and '%(foo,arg=value)' but there are lot of
corner cases.
So this morning I scrapped that and just added "%ad(mode)" which was
much simpler, and matches syntactically with some of our other commands.
It's in the series below.
> > The second cleanest would be adding an archive.date variable. Which is
> > much simpler, obviously. But I think making "log.date" start applying to
> > archive substitutions is going to surprise some people and possibly
> > break their setups.
>
> How should this surprise people? If the used %ad they would have
> expected a configuration depended substitution to start with. If they
> wanted a log.date *independent* substitution they should have (according
> to the documentation) some of the other formats (e.g., %ar, %ai, ...).
> So I don't really see this as a reason for not fixing this bug.
Imagine a project which uses "git archive" as part of its scripts for
building a distribution tarball. I.e., you run "make dist" or similar,
and it produces the tarball. The gitattributes and $Format:%ad$
placeholders are contained in the upstream repository. So anybody who
clones it can run "make dist" and get the identical tarball.
Now imagine as a developer on the project, you prefer to see your logs
with a different date format. So you set log.date to "short". But if
git-archive behaves as you want it to, then your "make dist" is now
broken. It generates different results to everyone else's.
Anyway, hopefully the point becomes moot with this patch series, which
lets you do %ad(short) in your format strings:
[1/2]: pretty.c: give format_person_part the whole placeholder
[2/2]: pretty.c: allow date formats in user format strings
-Peff
next prev parent reply other threads:[~2011-03-05 19:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-03 9:30 [Bug] %[a|c]d placeholder does not respect --date= option in combination with git archive Dietmar Winkler
2011-03-03 15:10 ` Jeff King
2011-03-04 10:10 ` Dietmar Winkler
2011-03-05 19:50 ` Jeff King [this message]
2011-03-05 19:51 ` [PATCH 1/2] pretty.c: give format_person_part the whole placeholder Jeff King
2011-03-05 20:00 ` [PATCH 2/2] pretty.c: allow date formats in user format strings Jeff King
[not found] ` <AANLkTinH8zwX2sbd5bpk=x4R3zOAg3Dc92Fbspfdv03T@mail.gmail.com>
2011-03-06 21:54 ` Fwd: " Will Palmer
2011-03-07 16:17 ` Jeff King
2011-03-07 17:28 ` Will Palmer
2011-03-07 18:50 ` Will Palmer
2011-03-07 19:26 ` Jeff King
2011-03-08 8:29 ` Will Palmer
2011-03-09 21:06 ` Junio C Hamano
2011-03-10 22:31 ` Jeff King
2011-03-11 8:33 ` Dietmar Winkler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110305195020.GA3089@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=dietmarw@gmx.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).