From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:33
René Scharfe [off-list ref] writes:
quoted
Maybe we should not so much name it by purpose, but by function. How
about "substformat" for the attribute name, and replacing any
$Format:blablub$ inside those files with something a la
--pretty=format:blablub?
I like the $Format:...$ notation. How about naming the attribute
"template", as that's what a thus marked file is?
Sounds good, although I suspect "template" might confuse newbies
that checkout may apply the substitution as well. How about
something with "export" in it? export-subst, perhaps?
From: René Scharfe <hidden> Date: 2016-06-15 22:43:33
As suggested by Johannes, --pretty=format: placeholders in specfiles
need to be wrapped in $Format:...$ now. This syntax change restricts
the expansion of placeholders and makes it easier to use with files
that contain non-placeholder percent signs.
Signed-off-by: Rene Scharfe <redacted>
---
Documentation/gitattributes.txt | 5 +++-
builtin-archive.c | 52 +++++++++++++++++++++++++++++++++++---
t/t5000-tar-tree.sh | 4 +-
3 files changed, 53 insertions(+), 8 deletions(-)
@@ -432,7 +432,10 @@ several placeholders when adding this file to an archive. The expansion depends on the availability of a commit ID, i.e. if gitlink:git-archive[1] has been given a tree instead of a commit or a tag then no replacement will be done. The placeholders are the same-as those for the option `--pretty=format:` of gitlink:git-log[1].+as those for the option `--pretty=format:` of gitlink:git-log[1],+except that they need to be wrapped like this: `$Format:PLACEHOLDERS$`+in the file. E.g. the string `$Format:%H$` will be replaced by the+commit hash. GIT
From: René Scharfe <hidden> Date: 2016-06-15 22:43:33
Junio C Hamano schrieb:
René Scharfe [off-list ref] writes:
quoted
quoted
Maybe we should not so much name it by purpose, but by function. How
about "substformat" for the attribute name, and replacing any
$Format:blablub$ inside those files with something a la
--pretty=format:blablub?
I like the $Format:...$ notation. How about naming the attribute
"template", as that's what a thus marked file is?
Sounds good, although I suspect "template" might confuse newbies
that checkout may apply the substitution as well. How about
something with "export" in it? export-subst, perhaps?
Well, including "export" in the name makes sense, yes. I can't come up
with a better name, let's take this.
--- snip! ---
As suggested by Junio and Johannes, change the name of the former
attribute specfile to export-subst to indicate its function rather
than purpose and to make clear that it is not applied to working tree
files.
Signed-off-by: Rene Scharfe <redacted>
---
Documentation/gitattributes.txt | 6 +++---
builtin-archive.c | 14 +++++++-------
t/t5000-tar-tree.sh | 18 +++++++++---------
3 files changed, 19 insertions(+), 19 deletions(-)
@@ -424,10 +424,10 @@ frotz unspecified Creating an archive ~~~~~~~~~~~~~~~~~~~-`specfile`-^^^^^^^^^^+`export-subst`+^^^^^^^^^^^^^^-If the attribute `specfile` is set for a file then git will expand+If the attribute `export-subst` is set for a file then git will expand several placeholders when adding this file to an archive. The expansion depends on the availability of a commit ID, i.e. if gitlink:git-archive[1] has been given a tree instead of a commit or a
@@ -108,20 +108,20 @@ test_expect_success \'diff -r a c/prefix/a' test_expect_success\-'create an archive with a specfile'\-'echospecfilespecfile>a/.gitattributes&&+'create an archive with a substfile'\+'echosubstfileexport-subst>a/.gitattributes&&gitarchiveHEAD>f.tar&&rma/.gitattributes' test_expect_success\-'extract specfile'\+'extract substfile'\'(mkdir f && cd f && $TAR xf -) <f.tar' test_expect_success\-'validate specfile contents'\-'gitlog--max-count=1"--pretty=format:A${SPECFILEFORMAT}O"HEAD\->f/a/specfile.expected&&-difff/a/specfile.expectedf/a/specfile'+'validate substfile contents'\+'gitlog--max-count=1"--pretty=format:A${SUBSTFORMAT}O"HEAD\+>f/a/substfile.expected&&+difff/a/substfile.expectedf/a/substfile' test_expect_success\'git archive --format=zip'\
Maybe initialise formatted_len, just to be on the safe side?
+
+ b = memchr(a, '$', len);
+ if (!b || a + len < b + 9 || memcmp(b + 1, "Format:", 7))
+ break;
Wouldn't memmem(buffer, len, "$Format:", 8) be better here?
A general comment: since you plan to output the result into a file anyway,
it should be even easier to avoid realloc(), and do a
print_formatted_specfile() instead of a format_specfile(), no?
Ciao,
Dscho
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:33
Hi,
On Thu, 6 Sep 2007, René Scharfe wrote:
As suggested by Junio and Johannes, change the name of the former
attribute specfile to export-subst to indicate its function rather
than purpose and to make clear that it is not applied to working tree
files.
Signed-off-by: Rene Scharfe <redacted>
ACK!
(Even if I did not really suggest "export-subst", which I like very
much...)
The bigger question is now if these two patches should be folded back into
your original patch series, or stand alone as commits of their own...
Ciao,
Dscho
Should this not be "char *buffer" instead of "const char *format"? Or
even better: a "struct strbuf *"?
const is correct, because the data in the buffer shouldn't be (and
isn't) modified.
"buffer" is a generic term; "format" on the other hand indicates the
meaning of the data within the buffer.
Input and output might indeed be passed along as struct strbuf, even
more so since the new API encourages its use as generic buffer (format
can contain NULs).
Maybe initialise formatted_len, just to be on the safe side?
I wish I could use C99 syntax and move its declaration down to its first
use, then it would be obvious that formatted_len is never used without
initialization.
quoted
+
+ b = memchr(a, '$', len);
+ if (!b || a + len < b + 9 || memcmp(b + 1, "Format:", 7))
+ break;
Wouldn't memmem(buffer, len, "$Format:", 8) be better here?
Oh, that's a nice GNU extension, didn't know it before. We might import
it to compat etc., but I think that's better left for a follow-up patch.
A general comment: since you plan to output the result into a file anyway,
it should be even easier to avoid realloc(), and do a
print_formatted_specfile() instead of a format_specfile(), no?
Hmm, not sure what you mean. At least archive-tar needs the expanded
contents in a buffer (not immediately written to stdout) because it
tries to mimic a real tar and always writes in blocks of 10k and
therefore needs to buffer the output.
Thanks!
René
From: René Scharfe <hidden> Date: 2016-06-15 22:43:34
Johannes Schindelin schrieb:
The bigger question is now if these two patches should be folded back
into your original patch series, or stand alone as commits of their
own...
Yes, indeed. I submitted them as add-on patches because I noticed the
first three are already in next, but I sure can make a fresh three-part
series based on master. Junio?
Thanks,
René
From: René Scharfe <hidden> Date: 2016-06-15 22:43:34
René Scharfe schrieb:
Johannes Schindelin schrieb:
quoted
quoted
+
+ b = memchr(a, '$', len);
+ if (!b || a + len < b + 9 || memcmp(b + 1, "Format:", 7))
+ break;
Wouldn't memmem(buffer, len, "$Format:", 8) be better here?
Oh, that's a nice GNU extension, didn't know it before. We might import
it to compat etc., but I think that's better left for a follow-up patch.
Just noticed: if the memcmp() above finds a difference, the code should
*not* break out of the loop. Ahem. Perhaps I should first add memmem()
after all...
René
From: René Scharfe <hidden> Date: 2016-06-15 22:43:34
memmem() is a nice GNU extension for searching a length limited string
in another one.
This compat version is based on the version found in glibc 2.2 (GPL 2);
I only removed the optimization of checking the first char by hand, and
generally tried to keep the code simple. We can add it back if memcmp
shows up high in a profile, but for now I prefer to keep it (almost
trivially) simple.
Since I don't really know which platforms beside those with a glibc
have their own memmem(), I used a heuristic: if NO_STRCASESTR is set,
then NO_MEMMEM is set, too.
Signed-off-by: Rene Scharfe <redacted>
---
Makefile | 11 +++++++++++
compat/memmem.c | 29 +++++++++++++++++++++++++++++
git-compat-util.h | 6 ++++++
3 files changed, 46 insertions(+), 0 deletions(-)
create mode 100644 compat/memmem.c
@@ -28,6 +28,8 @@ all::## Define NO_STRCASESTR if you don't have strcasestr.#+# Define NO_MEMMEM if you don't have memmem.+## Define NO_STRLCPY if you don't have strlcpy.## Define NO_STRTOUMAX if you don't have strtoumax in the C library.
From: René Scharfe <hidden> Date: 2016-06-15 22:43:34
As suggested by Johannes, --pretty=format: placeholders in specfiles
need to be wrapped in $Format:...$ now. This syntax change restricts
the expansion of placeholders and makes it easier to use with files
that contain non-placeholder percent signs.
Signed-off-by: Rene Scharfe <redacted>
---
This replacement patch fixes a bug in the "$Format:" search logic. It
now uses memmem() and thus depends on patch 3.5 which introduces this
function. Patch 5 still applies unchanged.
Documentation/gitattributes.txt | 5 +++-
builtin-archive.c | 52 +++++++++++++++++++++++++++++++++++---
t/t5000-tar-tree.sh | 4 +-
3 files changed, 53 insertions(+), 8 deletions(-)
@@ -432,7 +432,10 @@ several placeholders when adding this file to an archive. The expansion depends on the availability of a commit ID, i.e. if gitlink:git-archive[1] has been given a tree instead of a commit or a tag then no replacement will be done. The placeholders are the same-as those for the option `--pretty=format:` of gitlink:git-log[1].+as those for the option `--pretty=format:` of gitlink:git-log[1],+except that they need to be wrapped like this: `$Format:PLACEHOLDERS$`+in the file. E.g. the string `$Format:%H$` will be replaced by the+commit hash. GIT
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:34
Hi,
On Thu, 6 Sep 2007, René Scharfe wrote:
Johannes Schindelin schrieb:
quoted
quoted
+
+ b = memchr(a, '$', len);
+ if (!b || a + len < b + 9 || memcmp(b + 1, "Format:", 7))
+ break;
Wouldn't memmem(buffer, len, "$Format:", 8) be better here?
Oh, that's a nice GNU extension, didn't know it before.
Oh sorry, I didn't even realise that this is a GNU extension...
quoted
A general comment: since you plan to output the result into a file
anyway, it should be even easier to avoid realloc(), and do a
print_formatted_specfile() instead of a format_specfile(), no?
Hmm, not sure what you mean. At least archive-tar needs the expanded
contents in a buffer (not immediately written to stdout) because it
tries to mimic a real tar and always writes in blocks of 10k and
therefore needs to buffer the output.
Yeah, I missed that. Thanks for explaining it to me!
Ciao,
Dscho