All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>, phillip.wood@dunelm.org.uk
Cc: git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
	"Emily Shaffer" <emilyshaffer@google.com>,
	"Jeff King" <peff@peff.net>, "René Scharfe" <l.s.r@web.de>
Subject: Re: [PATCH v2 0/8] Makefile: generate a hook-list.h, prep for config-based-hooks
Date: Mon, 27 Sep 2021 19:01:59 +0100	[thread overview]
Message-ID: <6e7d5945-d64f-9511-9668-b453c20c086c@gmail.com> (raw)
In-Reply-To: <87pmsu1eao.fsf@evledraar.gmail.com>

On 27/09/2021 11:38, Ævar Arnfjörð Bjarmason wrote:
> 
> On Mon, Sep 27 2021, Phillip Wood wrote:
> 
>> On 26/09/2021 20:03, Ævar Arnfjörð Bjarmason wrote:
>>> This series is an incremental restart of the now-ejected
>>> es/config-based-hooks and ab/config-based-hooks-base topics. See [1]
>>> for a summary of the plan and progression.
>>> In v2 the "sed" invocation that generates the new hook-list.h has
>>> been
>>> changed to be portable under POSIX. See the thread starting at
>>> https://lore.kernel.org/git/92471ff9-7573-c3e4-e9fd-63a5cbf5738f@gmail.com/;
>>> The portability issue is AFAICT theoretical in that any "sed"
>>> command
>>> I've tried accepts the old version (I tried the large list of OS's
>>> listed in [2]), but better safe than sorry.
>>> Other changes:
>>>    * I noticed that the run-command.h inclusion in transport.c become
>>>      redundant, I removed that and validated the other ones that have
>>>      the new hook.h, they all still need run-command.h.
>>>    * A whitespace change in v1 in a change to the Makefile makes the
>>>      diff for 8/8 easier to read.
>>> 1. http://lore.kernel.org/git/cover-0.8-00000000000-20210923T095326Z-avarab@gmail.com
>>> 2. https://lore.kernel.org/git/87fstt3gzd.fsf@evledraar.gmail.com/
>>> [...]
>>> 8:  80aae4d5c13 ! 8:  7420267ce09 hook-list.h: add a generated list of hooks, like config-list.h
>>>       @@ Makefile: XDIFF_LIB = xdiff/lib.a
>>>         generated-hdrs: $(GENERATED_H)
>>>               @@ Makefile: git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS)
>>> $(GITLIBS)
>>>       + 		$(filter %.o,$^) $(LIBS)
>>>                help.sp help.s help.o: command-list.h
>>>       ++hook.sp hook.s hook.o: hook-list.h
>>>               -builtin/help.sp builtin/help.s builtin/help.o:
>>> config-list.h GIT-PREFIX
>>>       -+hook.sp hook.s hook.o: hook-list.h
>>>       -+
>>>        +builtin/help.sp builtin/help.s builtin/help.o: config-list.h hook-list.h GIT-PREFIX
>>
>> This is billed as a whitespace change above but this line has actually
>> changed since the last version - was that intentional?
> 
> I think you're mistaken here,

Yes you're right, looking more closely it is a context line in the range 
diff that has changed, sorry.

> it is a whitespace-only change to the
> end-state, but the diff and range-diff are confusing. If I diff the two
> Makefiles I end up with when applying v1 and v2 I get:
> 
> @@ -2217,7 +2210,6 @@ git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS)
>   		$(filter %.o,$^) $(LIBS)
>   
>   help.sp help.s help.o: command-list.h
> -
>   hook.sp hook.s hook.o: hook-list.h
>   
>   builtin/help.sp builtin/help.s builtin/help.o: config-list.h hook-list.h GIT-PREFIX
> 
> I.e. only the line between the old command-list.h and new hook-list.h
> line is gone.
> 
> But the diff for v1 is D/A/A/A and for v2 A/D/A (D = Deletion, A =
> Addition).
> 
> I.e. it's one of those times when "git diff" produces a valid diff, and
> one that's actually smaller than couldu have been produced with a
> v2-like diff given the change in v1.
> 
> As an aside I've sometimes wished we had a --diff-algorithm=maximal or
> something, i.e. there's a lot of cases where by just adding one line to
> the diff you can produce a bigger but IMO less confusing one.

Yes especially when it splits the diff just to keep an empty line or 
closing brace as context even though the line itself is not really 
interesting. Python's diff-lib has an option to ignore "junk" when 
determining which lines are unchanged, I keep meaning to see how it 
affects the diff but have never got round to it (the library uses a 
different slower algorithm for calculating the diff as well).

Best Wishes

Phillip

> 
> In any case, the end state looks better & the diff for v2 is more
> intuitive to look at.
> 
>>>         builtin/help.sp builtin/help.s builtin/help.o: EXTRA_CPPFLAGS = \
>>>         	'-DGIT_HTML_PATH="$(htmldir_relative_SQ)"' \
>>>       @@ generate-hooklist.sh (new)
>>>        +static const char *hook_name_list[] = {
>>>        +EOF
>>>        +
>>>       -+sed -n -e '/^~~~~*$/ {x; s/^.*$/	"&",/; p;}; x' \
>>>       ++sed -n \
>>>       ++	-e '/^~~~~*$/ {x; s/^.*$/	"&",/; p;}' \
>>>       ++	-e 'x' \
>>>        +	<Documentation/githooks.txt |
>>>        +	LC_ALL=C sort
>>>        +
>>
>> The sed change looks good
> 
> Thanks for confirming.
> 


      reply	other threads:[~2021-09-27 18:02 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-23 10:29 [PATCH 0/8] Makefile: generate a hook-list.h, prep for config-based-hooks Ævar Arnfjörð Bjarmason
2021-09-23 10:29 ` [PATCH 1/8] Makefile: mark "check" target as .PHONY Ævar Arnfjörð Bjarmason
2021-09-23 10:29 ` [PATCH 2/8] Makefile: stop hardcoding {command,config}-list.h Ævar Arnfjörð Bjarmason
2021-09-23 10:29 ` [PATCH 3/8] Makefile: don't perform "mv $@+ $@" dance for $(GENERATED_H) Ævar Arnfjörð Bjarmason
2021-09-23 10:29 ` [PATCH 4/8] Makefile: remove an out-of-date comment Ævar Arnfjörð Bjarmason
2021-09-23 10:30 ` [PATCH 5/8] hook.[ch]: move find_hook() from run-command.c to hook.c Ævar Arnfjörð Bjarmason
2021-09-23 10:30 ` [PATCH 6/8] hook.c: add a hook_exists() wrapper and use it in bugreport.c Ævar Arnfjörð Bjarmason
2021-09-23 10:30 ` [PATCH 7/8] hook.c users: use "hook_exists()" instead of "find_hook()" Ævar Arnfjörð Bjarmason
2021-09-23 10:30 ` [PATCH 8/8] hook-list.h: add a generated list of hooks, like config-list.h Ævar Arnfjörð Bjarmason
2021-09-24 10:19   ` Phillip Wood
2021-09-24 15:51     ` Junio C Hamano
2021-09-24 16:39       ` René Scharfe
2021-09-24 19:30     ` Ævar Arnfjörð Bjarmason
2021-09-24 19:56       ` René Scharfe
2021-09-24 20:09         ` Ævar Arnfjörð Bjarmason
2021-09-27  9:24       ` Phillip Wood
2021-09-27 10:36         ` Ævar Arnfjörð Bjarmason
2021-11-15 22:04   ` Mike Hommey
2021-11-15 22:26     ` Ævar Arnfjörð Bjarmason
2021-11-15 22:40       ` Mike Hommey
2021-11-15 22:49         ` Ævar Arnfjörð Bjarmason
2021-11-15 23:00           ` Mike Hommey
2021-11-16 12:01             ` Ævar Arnfjörð Bjarmason
2021-11-17  8:39               ` Junio C Hamano
2021-09-26 19:03 ` [PATCH v2 0/8] Makefile: generate a hook-list.h, prep for config-based-hooks Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 1/8] Makefile: mark "check" target as .PHONY Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 2/8] Makefile: stop hardcoding {command,config}-list.h Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 3/8] Makefile: don't perform "mv $@+ $@" dance for $(GENERATED_H) Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 4/8] Makefile: remove an out-of-date comment Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 5/8] hook.[ch]: move find_hook() from run-command.c to hook.c Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 6/8] hook.c: add a hook_exists() wrapper and use it in bugreport.c Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 7/8] hook.c users: use "hook_exists()" instead of "find_hook()" Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 8/8] hook-list.h: add a generated list of hooks, like config-list.h Ævar Arnfjörð Bjarmason
2021-09-27 16:48     ` Junio C Hamano
2021-09-27 18:00       ` René Scharfe
2021-09-27 20:23         ` Junio C Hamano
2021-09-27  9:30   ` [PATCH v2 0/8] Makefile: generate a hook-list.h, prep for config-based-hooks Phillip Wood
2021-09-27 10:38     ` Ævar Arnfjörð Bjarmason
2021-09-27 18:01       ` Phillip Wood [this message]

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=6e7d5945-d64f-9511-9668-b453c20c086c@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=avarab@gmail.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=l.s.r@web.de \
    --cc=peff@peff.net \
    --cc=phillip.wood@dunelm.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.