On Sun, Sep 9, 2019 at 4:34 PM Junio C Hamano wrote:
> I guess with "%(if)...%(then)...%(else)...%(end)" you might be able
> to do either one of --include/--exclude without supporting the
> other, e.g. "--include='%(if)%(symref)%(then)%(else)not a
> symref%(end)" would be usable as "I do not want
Remove the reference to the GIT_TEST_DATE_NOW which is done in date.c.
The intialization of variable x with the value from GIT_TEST_DATE_NOW
is unneeded since x is initalized by skip_prefix().
Signed-off-by: Stephen P. Smith
---
t/helper/test-date.c | 1 -
1 file changed, 1 deletion(-)
diff --g
As part of a previous patch set, the get_time() function was added to
date.c eliminating the need to pass a `now` parameter from the test
code.
Signed-off-by: Stephen P. Smith
---
cache.h | 5 ++---
date.c | 27 +--
t/helper/test-date.c | 26 ++
As part of a previous patch submission[1], a cleanup patch was
suggested to remove a now unnecessary passing of a date environment
variable to the production code.
While the two patches in the set could easily be submitted as a single
patch, I split the removal of the getenv() call into a second
p
Junio C Hamano writes:
> Jeff King writes:
>
>> So in my mind there's an endgame we'd like to eventually reach where
>> the option added by your patch isn't needed anymore. But we're a long
>> way from that. And it's not entirely clear where we'd draw the line
>> anyway.
>
> All true and very go
On 2019-09-08 at 21:21:22, Jeff King wrote:
> But it's not clear from that whether asciidoc's docbook5 backend inserts
> an extra newline, or if it's part of the xml translation. Looking at the
> actual XML, I see:
>
>
> hand resolve the conflict in the working directory, and update
> the i
On Sun, Sep 08, 2019 at 04:13:08PM +0200, SZEDER Gábor wrote:
> OTOH, these "stripped namespace" messages come from 'xmlto', are not
> warnings but have that "Note:" prefix, and, trusting that you did
> check the results thoroughly, are apparently not a sign of any
> rendering issues. So I think
On Sat, Sep 07, 2019 at 04:06:48PM +0200, Martin Ågren wrote:
> So of these steps:
>
> 0. Get Asciidoctor (v1) in shape.
>
> 1. Switch the default to Asciidoctor (v1).
>
> 2. Drop AsciiDoc to have faster Asciidoctor-processing, avoid xmlto
> and support Asciidoctor 2. And to avoid th
On Sun, Sep 08, 2019 at 05:18:07PM +, brian m. carlson wrote:
> > -2. hand resolve the conflict in the working directory, and
> > update the
> > +2. hand resolve the conflict in the working directory, and
> > update the
> > index file to bring it into a sta
On 2019-09-07 at 23:41:46, Warren He wrote:
> Brian, thanks for looking. The only thing I can come up with to say about
> having
> lots of refs is that at least that part of this isn't brand new code. The part
> that collects ref info uses the same routines as `git log --decorate`. Do you
> recall
Demonstrate that a decoration filter given with --decorate-refs-exclude
is inadvertently overruled by --simplify-by-decoration.
Reported-by: Étienne SERVAIS
Signed-off-by: René Scharfe
---
t/t4202-log.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/t/t4202-log.sh b/t/t42
Load a default set of ref name decorations at the first lookup. This
frees direct and indirect callers from doing so. They can still do it
if they want to use a filter or are interested in full decorations
instead of the default short ones -- the first load_ref_decorations()
call wins.
This mean
On 2019-09-08 at 10:48:33, Jeff King wrote:
> Some of them seem bad, though:
>
> ---
> a/745f6812895b31c02b29bdfe4ae8e5498f776c26-asciidoctor/home/peff/share/man/man1/git-am.1
> +++
> b/303729d86b6965222bf4b3a6f95932e12648-asciidoctor/home/peff/share/man/man1/git-am.1
> [...]
> @@ -1
Jeff King writes:
> So in my mind there's an endgame we'd like to eventually reach where
> the option added by your patch isn't needed anymore. But we're a long
> way from that. And it's not entirely clear where we'd draw the line
> anyway.
All true and very good "thinking out loud".
> So in th
Hi Jeff,
On 04/09/19 03:41PM, Jeff King wrote:
[snip]
> The project page has a section to point people in the right direction
> for first-time contributions. I've left it blank for now, but I think it
> makes sense to point one (or both) of:
>
> - https://git-scm.com/docs/MyFirstContribution
>
Thanks for giving this some thought.
> I don't think this can directly be the culprit, because that ssh's stdout
> will be
> hooked to a pipe talking to Git, not to the original stdout of "git fetch". It
> should not have even received a descriptor that is a copy of the original
> stdout (nor std
On Sat, Sep 07, 2019 at 05:07:46PM +, brian m. carlson wrote:
> Our documentation toolchain has traditionally been built around DocBook
> 4.5. This version of DocBook is the last DTD-based version of DocBook.
> In 2009, DocBook 5 was introduced using namespaces and its syntax is
> expressed in
On Sat, Sep 07, 2019 at 05:07:46PM +, brian m. carlson wrote:
> Our documentation toolchain has traditionally been built around DocBook
> 4.5. This version of DocBook is the last DTD-based version of DocBook.
> In 2009, DocBook 5 was introduced using namespaces and its syntax is
> expressed i
On Sat, Sep 07, 2019 at 02:56:36PM -0400, Taylor Blau wrote:
> So, the patch here looks obviously correct, and I don't think it needs a
> test or anything like that... besides: what is there to test? :).
There's no functional change, so as long as this has coverage in the
regular suite (and I thi
On Sat, Sep 07, 2019 at 11:50:41PM +, Douglas Graham wrote:
> We have a parallel build that occasionally fails with the error message
> "make: write error". Make prints that error message as it is exiting when
> it detects that it has seen errors while writing to stdout. The error it
> is en
On Sat, Sep 07, 2019 at 03:36:46PM -0600, Eric Freese wrote:
> Using the new flag will omit symbolic refs from the output.
>
> Without this flag, it is possible to get this behavior by using the
> `%(symref)` formatting field name and piping output through grep to
> include only those refs that d
On Sat, Sep 07, 2019 at 07:28:21PM -0400, Taylor Blau wrote:
> > diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
> > index 465153e853..b71ab2f135 100644
> > --- a/builtin/for-each-ref.c
> > +++ b/builtin/for-each-ref.c
> > @@ -18,7 +18,7 @@ int cmd_for_each_ref(int argc, const char **
Eric Wong wrote:
> By renaming the "hash" field to "_hash", it's easy to spot
> improper initialization of hashmap_entry structs which
> can leave "hashmap_entry.next" uninitialized.
Junio, I'm planning to reroll this series.
(Sorry for not following up sooner)
Would you prefer I drop 04/11 "has
23 matches
Mail list logo
