From: Sean Allred <allred.sean@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)
Date: Thu, 15 Dec 2022 05:55:39 -0600 [thread overview]
Message-ID: <87k02svpgy.fsf@gmail.com> (raw)
In-Reply-To: <xmqqiliewbje.fsf@gitster.g>
> * sa/git-var-empty (2022-11-27) 2 commits
> (merged to 'next' on 2022-12-01 at 3b81dcb382)
> + var: allow GIT_EDITOR to return null
> + var: do not print usage() with a correct invocation
>
> "git var UNKNOWN_VARIABLE" and "git var VARIABLE" with the variable
> given an empty value used to behave identically. Now the latter
> just gives an empty output, while the former still gives an error
> message.
> source: <pull.1434.v3.git.1669472277.gitgitgadget@gmail.com>
After reading gitworkflows.txt and maintaingit.txt, I take it 'next' is
a proving ground for the larger community to have a chance to suss out
any bugs/regressions. I'm going to assume no further input is needed
from me regarding this topic (unless of course I've got a bug!), but let
me know if I'm mistaken :-) (and thanks to all the folks who've already
provided review!)
Is now a good time to resume the conversation of exposing
GIT_SEQUENCE_EDITOR variable within git-var [1]? I expect the patch to
be mostly the same, but instead following the now-corrected pattern laid
out for GIT_EDITOR (and updated to use the new test helper functions).
Should I then base my branch on 'next' or upon 'sa/git-var-empty'
specifically (now merged to 'next')?
[1]: https://lore.kernel.org/git/pull.1424.git.1668972017089.gitgitgadget@gmail.com/T/#u
--
Sean Allred
next prev parent reply other threads:[~2022-12-15 12:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 9:59 What's cooking in git.git (Dec 2022, #05; Wed, 14) Junio C Hamano
2022-12-14 10:44 ` Junio C Hamano
2022-12-14 19:46 ` Taylor Blau
2022-12-14 15:09 ` Derrick Stolee
2022-12-14 23:50 ` Junio C Hamano
2022-12-14 19:09 ` Jeff Hostetler
2022-12-14 23:50 ` Junio C Hamano
2022-12-14 19:18 ` Jeff Hostetler
2022-12-15 22:37 ` Junio C Hamano
2022-12-15 9:14 ` ag/merge-strategies-in-c (was: What's cooking in git.git (Dec 2022, #05; Wed, 14)) Ævar Arnfjörð Bjarmason
2022-12-15 12:55 ` Phillip Wood
2022-12-15 15:32 ` Ævar Arnfjörð Bjarmason
2022-12-15 16:27 ` Phillip Wood
2022-12-15 16:29 ` Ævar Arnfjörð Bjarmason
2022-12-15 9:33 ` ab/remove--super-prefix & ab/submodule-no-abspath " Ævar Arnfjörð Bjarmason
2022-12-15 9:49 ` js/bisect-in-c " Ævar Arnfjörð Bjarmason
2022-12-15 11:55 ` Sean Allred [this message]
2022-12-15 22:45 ` What's cooking in git.git (Dec 2022, #05; Wed, 14) Junio C Hamano
2022-12-15 23:09 ` Junio C Hamano
2022-12-16 15:33 ` ds/bundle-uri-4* (was Re: What's cooking in git.git (Dec 2022, #05; Wed, 14)) Derrick Stolee
2022-12-16 22:55 ` Junio C Hamano
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=87k02svpgy.fsf@gmail.com \
--to=allred.sean@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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.