* Re: What's cooking in git.git (Aug 2020, #07; Thu, 27)
From: Taylor Blau @ 2020-08-28 0:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Taylor Blau, git
In-Reply-To: <xmqqzh6foe44.fsf@gitster.c.googlers.com>
On Thu, Aug 27, 2020 at 04:36:43PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Thu, Aug 27, 2020 at 02:43:02PM -0700, Junio C Hamano wrote:
> >
> >> * tb/repack-clearing-midx (2020-08-26) 1 commit
> >> (merged to 'next' on 2020-08-27 at a465875cbb)
> >> + builtin/repack.c: invalidate MIDX only when necessary
> >>
> >> When a packfile is removed by "git repack", multi-pack-index gets
> >> cleared; the code was taught to do so less aggressively by first
> >> checking if the midx actually refers to a pack that no longer
> >> exists.
> >>
> >> Will merge to 'master'.
> >
> > This seems to break t7700 when run with midx support:
> >
> > $ git checkout e08f7bb093
> > HEAD is now at e08f7bb093 builtin/repack.c: invalidate MIDX only when necessary
> >
> > $ make && (cd t && GIT_TEST_MULTI_PACK_INDEX=1 ./t7700-repack.sh -i)
> > [...]
> > + git repack -a -d
> > Enumerating objects: 10, done.
> > Counting objects: 100% (10/10), done.
> > Delta compression using up to 16 threads
> > Compressing objects: 100% (5/5), done.
> > Writing objects: 100% (10/10), done.
> > Total 10 (delta 1), reused 10 (delta 1), pack-reused 0
> > fatal: error preparing packfile from multi-pack-index
> > error: last command exited with $?=128
> > not ok 6 - packed obs in alt ODB are repacked when local repo has packs
> > #
> > # rm -f .git/objects/pack/* &&
> > # echo new_content >>file1 &&
> > # git add file1 &&
> > # test_tick &&
> > # git commit -m more_content &&
> > # git repack &&
> > # git repack -a -d &&
> > # test_no_missing_in_packs
> >
> > I didn't look into whether it's a bug in the actual code, or just a
> > weird interaction with the way GIT_TEST_MULTI_PACK_INDEX triggers
> > git-repack to write a midx. But either way we should figure that out
> > before it graduates.
>
> Thanks for stopping us ;-)
Thanks indeed. I started looking into this tonight thinking that it'd be
an easy fix, but I think there is a deeper bug that is worth
investigating further.
Let's eject this for now. If the bug turns out to be easier than I
thought, I'll send the patch again, otherwise I'll send it with my
larger series when that's ready.
Thanks,
Taylor
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2020, #07; Thu, 27)
From: Junio C Hamano @ 2020-08-27 23:36 UTC (permalink / raw)
To: Jeff King; +Cc: Taylor Blau, git
In-Reply-To: <20200827233454.GA3973432@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Aug 27, 2020 at 02:43:02PM -0700, Junio C Hamano wrote:
>
>> * tb/repack-clearing-midx (2020-08-26) 1 commit
>> (merged to 'next' on 2020-08-27 at a465875cbb)
>> + builtin/repack.c: invalidate MIDX only when necessary
>>
>> When a packfile is removed by "git repack", multi-pack-index gets
>> cleared; the code was taught to do so less aggressively by first
>> checking if the midx actually refers to a pack that no longer
>> exists.
>>
>> Will merge to 'master'.
>
> This seems to break t7700 when run with midx support:
>
> $ git checkout e08f7bb093
> HEAD is now at e08f7bb093 builtin/repack.c: invalidate MIDX only when necessary
>
> $ make && (cd t && GIT_TEST_MULTI_PACK_INDEX=1 ./t7700-repack.sh -i)
> [...]
> + git repack -a -d
> Enumerating objects: 10, done.
> Counting objects: 100% (10/10), done.
> Delta compression using up to 16 threads
> Compressing objects: 100% (5/5), done.
> Writing objects: 100% (10/10), done.
> Total 10 (delta 1), reused 10 (delta 1), pack-reused 0
> fatal: error preparing packfile from multi-pack-index
> error: last command exited with $?=128
> not ok 6 - packed obs in alt ODB are repacked when local repo has packs
> #
> # rm -f .git/objects/pack/* &&
> # echo new_content >>file1 &&
> # git add file1 &&
> # test_tick &&
> # git commit -m more_content &&
> # git repack &&
> # git repack -a -d &&
> # test_no_missing_in_packs
>
> I didn't look into whether it's a bug in the actual code, or just a
> weird interaction with the way GIT_TEST_MULTI_PACK_INDEX triggers
> git-repack to write a midx. But either way we should figure that out
> before it graduates.
Thanks for stopping us ;-)
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2020, #07; Thu, 27)
From: Jeff King @ 2020-08-27 23:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Taylor Blau, git
In-Reply-To: <xmqqh7snpxy1.fsf@gitster.c.googlers.com>
On Thu, Aug 27, 2020 at 02:43:02PM -0700, Junio C Hamano wrote:
> * tb/repack-clearing-midx (2020-08-26) 1 commit
> (merged to 'next' on 2020-08-27 at a465875cbb)
> + builtin/repack.c: invalidate MIDX only when necessary
>
> When a packfile is removed by "git repack", multi-pack-index gets
> cleared; the code was taught to do so less aggressively by first
> checking if the midx actually refers to a pack that no longer
> exists.
>
> Will merge to 'master'.
This seems to break t7700 when run with midx support:
$ git checkout e08f7bb093
HEAD is now at e08f7bb093 builtin/repack.c: invalidate MIDX only when necessary
$ make && (cd t && GIT_TEST_MULTI_PACK_INDEX=1 ./t7700-repack.sh -i)
[...]
+ git repack -a -d
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 16 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (10/10), done.
Total 10 (delta 1), reused 10 (delta 1), pack-reused 0
fatal: error preparing packfile from multi-pack-index
error: last command exited with $?=128
not ok 6 - packed obs in alt ODB are repacked when local repo has packs
#
# rm -f .git/objects/pack/* &&
# echo new_content >>file1 &&
# git add file1 &&
# test_tick &&
# git commit -m more_content &&
# git repack &&
# git repack -a -d &&
# test_no_missing_in_packs
I didn't look into whether it's a bug in the actual code, or just a
weird interaction with the way GIT_TEST_MULTI_PACK_INDEX triggers
git-repack to write a midx. But either way we should figure that out
before it graduates.
-Peff
^ permalink raw reply
* Re: [PATCH] send-email: do not prompt for In-Reply-To
From: Drew DeVault @ 2020-08-27 23:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlo Marcelo Arenas Belón, git
In-Reply-To: <xmqq4konptab.fsf@gitster.c.googlers.com>
On Thu Aug 27, 2020 at 7:23 PM EDT, Junio C Hamano wrote:
> Carlo and I were discussing how best to describe the behaviour we
> have better to the users, which is unrelated to any code change that
> would be required to "make it harder make it easier."
>
> We need to do so to help users in the meantime, before any behaviour
> change (which need to happen over several releases, as outlined
> earlier) happens.
Ah, I see what you mean. I'll add some messaging like that in my v2, but
the point's likely moot anyway since I expect to have the patch ready
for the next release.
^ permalink raw reply
* Re: [PATCH] send-email: do not prompt for In-Reply-To
From: Junio C Hamano @ 2020-08-27 23:23 UTC (permalink / raw)
To: Drew DeVault; +Cc: Carlo Marcelo Arenas Belón, git
In-Reply-To: <C585GT9K2V93.4O470Q21FXFD@homura>
"Drew DeVault" <sir@cmpwn.com> writes:
> On Thu Aug 27, 2020 at 6:57 PM EDT, Junio C Hamano wrote:
>> To help those who do not want to add this header, it would probably
>> be more helpful to tell what to do when prompted (like "you can give
>> an empty answer to tell the command that you are not responding to
>> any message").
>
> I don't like this solution. We should make it harder to do the wrong
> thing, and easier to do the right thing.
Carlo and I were discussing how best to describe the behaviour we
have better to the users, which is unrelated to any code change that
would be required to "make it harder make it easier."
We need to do so to help users in the meantime, before any behaviour
change (which need to happen over several releases, as outlined
earlier) happens.
^ permalink raw reply
* Re: [PATCH] send-email: do not prompt for In-Reply-To
From: Drew DeVault @ 2020-08-27 23:05 UTC (permalink / raw)
To: Drew DeVault, Junio C Hamano, Carlo Marcelo Arenas Belón; +Cc: git
In-Reply-To: <C585GT9K2V93.4O470Q21FXFD@homura>
Oh, and I should mention the fact that this breaking change is less
severe than we initially thought, only breaking an edge case - when --to
is not specified - so it's likely to have a pretty small impact. We'll
find out when someone emails us to complain, I suppose.
^ permalink raw reply
* Re: [PATCH] send-email: do not prompt for In-Reply-To
From: Drew DeVault @ 2020-08-27 22:59 UTC (permalink / raw)
To: Junio C Hamano, Carlo Marcelo Arenas Belón; +Cc: Drew DeVault, git
In-Reply-To: <xmqqd03bpuh7.fsf@gitster.c.googlers.com>
On Thu Aug 27, 2020 at 6:57 PM EDT, Junio C Hamano wrote:
> To help those who do not want to add this header, it would probably
> be more helpful to tell what to do when prompted (like "you can give
> an empty answer to tell the command that you are not responding to
> any message").
I don't like this solution. We should make it harder to do the wrong
thing, and easier to do the right thing.
It would be helpful for git to take an opinionated stance on the right
way to send emails with it, since no one else is really in the position
to. This behavior has confused many people that I've spoken with and
makes for a rough introduction to a tool which people are already loathe
to learn. git send-email is really the best way to send emails with git,
and will save the user a lot of trouble in the future if they figure it
out, so I want it to be as easy to figure out as possible.
Even so, I understand the concerns raised so far. I haven't started on
v2 yet, but my rough plan is to add a config option along the lines of
sendemail.verbosePrompts, defaulted to on for now, which enables the
present-day behavior, along with a message stating the intention to
change the behavior in a future release, and an invitation to comment on
the mailing list.
The behavior of this flag if set to false would be equivalent to
removing the $prompting condition in the if statement which controls
whether or not this prompt is shown.
^ permalink raw reply
* Re: [PATCH] po: add missing letter for French message
From: Junio C Hamano @ 2020-08-27 23:04 UTC (permalink / raw)
To: brian m. carlson; +Cc: git, Jean-Noël Avila
In-Reply-To: <20200827223527.36788-1-sandals@crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> Add the missing "e" in "de". While it is possible in French to omit it,
> that only occurs with an apostrophe and only when the next word starts
> with a vowel or mute h, which is not the case here.
>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
> I noticed this the other day when trying to delete a remote branch that
> I'd already deleted. I'm not sure what the preferred approach is for
> this, whether Junio should pick it up or whether Jean-Noël will want to
> incorporate it first, but I've CC'd both so y'all can fight it out.
Unless it is in the pre-release period (in which case I'd prefer not
to touch po/ myself at all, to give i18n/l10n teams a stable base to
work from), I can take it dircetly as long as somebody from the l10n
team for the language gives an Ack, as I cannot read most of the
files under po/ directory.
Thanks.
> po/fr.po | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/po/fr.po b/po/fr.po
> index d20fc440ab..75b1e75f6a 100644
> --- a/po/fr.po
> +++ b/po/fr.po
> @@ -6503,7 +6503,7 @@ msgstr "'%s' ne peut pas être résolue comme une branche"
> #: remote.c:1088
> #, c-format
> msgid "unable to delete '%s': remote ref does not exist"
> -msgstr "suppression d '%s' impossible : la référence distante n'existe pas"
> +msgstr "suppression de '%s' impossible : la référence distante n'existe pas"
>
> #: remote.c:1100
> #, c-format
^ permalink raw reply
* Re: [PATCH] send-email: do not prompt for In-Reply-To
From: Junio C Hamano @ 2020-08-27 22:57 UTC (permalink / raw)
To: Carlo Marcelo Arenas Belón; +Cc: Drew DeVault, git
In-Reply-To: <20200827220249.GA71190@Carlos-MBP>
Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:
> On Thu, Aug 27, 2020 at 12:34:02PM -0700, Junio C Hamano wrote:
>>
>> That feels both understandable and bogus at the same time. To:
>> is pretty much required (yes, you can use cc: and bcc: without any
>> address on To:, but that is not something you'd usually do to send
>> patches to mailing lists), so lack of it means either asking
>> interactively or aborting. But other things like in-reply-to are
>> optional, and tying the decision to prompt for them or not does not
>> feel OK.
>
> but trying to "fix" this breaks 10 year old tests, so it is obvious
> that everyone already expects it to work this way (probably hidden
> by the fact most people don't let git-send-email prompt for "To:")
Oh, I agree with that 100%.
> -Only necessary if --compose is also set. If --compose
> -is not set, this will be prompted for.
> +If --compose is not set, and there is no known "To:" this will be prompted for.
The updated sentence structure, with or without the mention of
"to:", reads much better than the original.
The original told them that they must give it from the command line
in "--compose" mode, because they will not be given the chance to
give it interactively, and the intended target audience was those
who want to send a message with in-reply-to (which is natural, as
this is a description for that option).
The updated message says the same thing, but is audience-neutral and
tries to be more useful to folks who are not responding to any
message. I.e. outside "--compose" mode, you'll be asked if you want
to make it a response, unless you gave "to:".
By losing the "we won't ask so you must give it from the command
line" message in the original, the resulting description has become
easier to follow, I think. Those who do want to add the header,
when they reach this description in the manual, already knows that
there is a command line option.
To help those who do not want to add this header, it would probably
be more helpful to tell what to do when prompted (like "you can give
an empty answer to tell the command that you are not responding to
any message").
Thanks.
^ permalink raw reply
* [PATCH] po: add missing letter for French message
From: brian m. carlson @ 2020-08-27 22:35 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jean-Noël Avila
Add the missing "e" in "de". While it is possible in French to omit it,
that only occurs with an apostrophe and only when the next word starts
with a vowel or mute h, which is not the case here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
I noticed this the other day when trying to delete a remote branch that
I'd already deleted. I'm not sure what the preferred approach is for
this, whether Junio should pick it up or whether Jean-Noël will want to
incorporate it first, but I've CC'd both so y'all can fight it out.
po/fr.po | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/po/fr.po b/po/fr.po
index d20fc440ab..75b1e75f6a 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -6503,7 +6503,7 @@ msgstr "'%s' ne peut pas être résolue comme une branche"
#: remote.c:1088
#, c-format
msgid "unable to delete '%s': remote ref does not exist"
-msgstr "suppression d '%s' impossible : la référence distante n'existe pas"
+msgstr "suppression de '%s' impossible : la référence distante n'existe pas"
#: remote.c:1100
#, c-format
^ permalink raw reply related
* Re: [PATCH] send-email: do not prompt for In-Reply-To
From: Carlo Marcelo Arenas Belón @ 2020-08-27 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Drew DeVault, git
In-Reply-To: <xmqqtuwnq3x1.fsf@gitster.c.googlers.com>
On Thu, Aug 27, 2020 at 12:34:02PM -0700, Junio C Hamano wrote:
>
> That feels both understandable and bogus at the same time. To:
> is pretty much required (yes, you can use cc: and bcc: without any
> address on To:, but that is not something you'd usually do to send
> patches to mailing lists), so lack of it means either asking
> interactively or aborting. But other things like in-reply-to are
> optional, and tying the decision to prompt for them or not does not
> feel OK.
but trying to "fix" this breaks 10 year old tests, so it is obvious
that everyone already expects it to work this way (probably hidden
by the fact most people don't let git-send-email prompt for "To:")
the patch after the scissors attempts to document the current "Legacy"
behaviour which should be worth doing regardless of what is done with
this patch.
but I suspect it might be worth adding a new configuration flag like
the one that was propossed so that the prompting could be set per
repository to either "Always" (for when forgetting it will break the
threads in lists that care, like this one) and "Never" (for when the
lists explicitally ask mails to be send without one, because they
use patchew or equivalent (ex: qemu-devel[1])).
Carlo
[1] https://wiki.qemu.org/Contribute/SubmitAPatch
--- >8 ---
Subject: [PATCH] send-email: document logic for In-Reply-To prompting
Eventhough there doesn't seem to be a good reason for it, it is
the way it has been implemented for the last 10 years.
Document the current behaviour (which the tests also depend on)
before it can be tweaked by a future per repository setting.
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
---
Documentation/git-send-email.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 0a69810147..8e9ebb3fac 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -108,8 +108,7 @@ illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`:
[PATCH v2 2/3] New tests
[PATCH v2 3/3] Implementation
+
-Only necessary if --compose is also set. If --compose
-is not set, this will be prompted for.
+If --compose is not set, and there is no known "To:" this will be prompted for.
--subject=<string>::
Specify the initial subject of the email thread.
--
2.28.0.424.gade71fd49b
^ permalink raw reply related
* What's cooking in git.git (Aug 2020, #07; Thu, 27)
From: Junio C Hamano @ 2020-08-27 21:43 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'seen' (formerly 'pu'---proposed updates) while commits prefixed
with '+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to 'master']
* en/mem-pool (2020-08-18) 3 commits
(merged to 'next' on 2020-08-19 at eff9ad46f0)
+ mem-pool: use consistent pool variable name
+ mem-pool: use more standard initialization and finalization
+ mem-pool: add convenience functions for strdup and strndup
API update.
* hn/refs-fetch-head-is-special (2020-08-19) 4 commits
(merged to 'next' on 2020-08-21 at def233ab43)
+ refs: read FETCH_HEAD and MERGE_HEAD generically
+ refs: move gitdir into base ref_store
+ refs: fix comment about submodule ref_stores
+ refs: split off reading loose ref data in separate function
(this branch is used by hn/refs-pseudorefs.)
The FETCH_HEAD is now always read from the filesystem regardless of
the ref backend in use, as its format is much richer than the
normal refs, and written directly by "git fetch" as a plain file..
* jk/leakfix (2020-08-17) 7 commits
(merged to 'next' on 2020-08-21 at a8b25a2657)
+ submodule--helper: fix leak of core.worktree value
+ config: fix leak in git_config_get_expiry_in_days()
+ config: drop git_config_get_string_const()
+ config: fix leaks from git_config_get_string_const()
+ checkout: fix leak of non-existent branch names
+ submodule--helper: use strbuf_release() to free strbufs
+ clear_pattern_list(): clear embedded hashmaps
Code clean-up.
* rz/complete-more-options (2020-08-19) 2 commits
(merged to 'next' on 2020-08-21 at ba8f4c8cb1)
+ completion: add GIT_COMPLETION_SHOW_ALL env var
+ parse-options: add --git-completion-helper-all
Command line completion (in contrib/) usually omits redundant,
deprecated and/or dangerous options from its output; it learned to
optionally include all of them.
--------------------------------------------------
[New Topics]
* jc/remove-pack-redundant (2020-08-25) 1 commit
- pack-redundant: gauge the usage before proposing its removal
The first step to remove "git pack-redundant" by soliciting
objections.
* ps/ref-transaction-hook (2020-08-25) 1 commit
(merged to 'next' on 2020-08-27 at 49b3fb8349)
+ refs: remove lookup cache for reference-transaction hook
Code simplification by removing ineffective optimization.
Will merge to 'master'.
* jc/undash-in-tree-git-callers (2020-08-27) 3 commits
(merged to 'next' on 2020-08-27 at 671fa2f87e)
+ credential-cache: use child_process.args
+ cvsexportcommit: do not run git programs in dashed form
+ transport-helper: do not run git-remote-ext etc. in dashed form
(this branch is used by jc/war-on-dashed-git.)
A handful of places in in-tree code still relied on being able to
execute the git subcommands, especially built-ins, in "git-foo"
form, which have been corrected.
Will merge to 'master'.
* jc/war-on-dashed-git (2020-08-27) 1 commit
- git: catch an attempt to run "git-foo"
(this branch uses jc/undash-in-tree-git-callers.)
The first step to remove on-disk binaries for built-in subcommands
by soliciting objections.
On hold for now.
* jk/rev-input-given-fix (2020-08-26) 1 commit
(merged to 'next' on 2020-08-27 at da291a327c)
+ revision: set rev_input_given in handle_revision_arg()
Feeding "$ZERO_OID" to "git log --ignore-missing --stdin", and
running "git log --ignore-missing $ZERO_OID" fell back to start
digging from HEAD; it has been corrected to become a no-op, like
"git log --tags=no-tag-matches-this-pattern" does.
Will merge to 'master'.
* tb/repack-clearing-midx (2020-08-26) 1 commit
(merged to 'next' on 2020-08-27 at a465875cbb)
+ builtin/repack.c: invalidate MIDX only when necessary
When a packfile is removed by "git repack", multi-pack-index gets
cleared; the code was taught to do so less aggressively by first
checking if the midx actually refers to a pack that no longer
exists.
Will merge to 'master'.
* jc/run-command-use-embedded-args (2020-08-26) 1 commit
(merged to 'next' on 2020-08-27 at c2b688e8e9)
+ run_command: teach API users to use embedded 'args' more
Various callers of run_command API has been modernized.
Will merge to 'master'.
* es/worktree-repair (2020-08-27) 5 commits
- init: make --separate-git-dir work from within linked worktree
- init: teach --separate-git-dir to repair linked worktrees
- worktree: teach "repair" to fix outgoing links to worktrees
- worktree: teach "repair" to fix worktree back-links to main worktree
- worktree: add skeleton "repair" command
"git worktree repair" command to correct on-disk pointers between
the repository and its secondary working trees.
Expecting a reroll.
* jk/worktree-check-clean-leakfix (2020-08-27) 1 commit
- worktree: fix leak in check_clean_worktree()
Leakfix.
Will merge to 'next'.
* so/pretty-abbrev-doc (2020-08-27) 1 commit
- pretty-options.txt: fix --no-abbrev-commit description
Documentation update for "--no-abbrev-commit".
Will merge to 'next'.
* ss/submodule-summary-in-c-fixes (2020-08-27) 3 commits
- t7421: eliminate 'grep' check in t7421.4 for mingw compatibility
- submodule: fix style in function definition
- submodule: eliminate unused parameters from print_submodule_summary()
(this branch uses ss/submodule-summary-in-c.)
Fixups to a topic in 'next'.
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* tb/bloom-improvements (2020-08-11) 14 commits
- builtin/commit-graph.c: introduce '--max-new-filters=<n>'
- commit-graph: rename 'split_commit_graph_opts'
- commit-graph: add large-filters bitmap chunk
- commit-graph.c: sort index into commits list
- bloom/diff: properly short-circuit on max_changes
- bloom: use provided 'struct bloom_filter_settings'
- csum-file.h: introduce 'hashwrite_be64()'
- bloom: split 'get_bloom_filter()' in two
- commit-graph.c: store maximum changed paths
- commit-graph: respect 'commitGraph.readChangedPaths'
- t/helper/test-read-graph.c: prepare repo settings
- commit-graph: pass a 'struct repository *' in more places
- t4216: use an '&&'-chain
- commit-graph: introduce 'get_bloom_filter_settings()'
Misc Bloom filter improvements.
Expecting a reroll.
It seems that the review is getting closer to result in another update.
cf. <20200811220503.GC66656@syl.lan>
* es/config-hooks (2020-07-30) 6 commits
- hook: add 'run' subcommand
- parse-options: parse into argv_array
- hook: add --porcelain to list command
- hook: add list command
- hook: scaffolding for git-hook subcommand
- doc: propose hooks managed by the config
The "hooks defined in config" topic.
Expecting a reroll.
Now jk/strvec is in 'master', we may want to see the topic reworked
on top of it. Are there unresolved issues, or does the topic need
a round of detailed review?
cf. <xmqqmu3i9kvg.fsf@gitster.c.googlers.com>
* mt/grep-sparse-checkout (2020-06-12) 6 commits
- config: add setting to ignore sparsity patterns in some cmds
- grep: honor sparse checkout patterns
- config: correctly read worktree configs in submodules
- t/helper/test-config: facilitate addition of new cli options
- t/helper/test-config: return exit codes consistently
- doc: grep: unify info on configuration variables
"git grep" has been tweaked to be limited to the sparse checkout
paths.
Review needed on 4/6; otherwise looking sane.
cf. <CABPp-BGdEyEeajYZj_rdxp=MyEQdszuyjVTax=hhYj3fOtRQUQ@mail.gmail.com>
* ls/mergetool-meld-auto-merge (2020-07-12) 2 commits
- SQUASH???
- Support auto-merge for meld to follow the vim-diff behavior
The 'meld' backend of the "git mergetool" learned to give the
underlying 'meld' the '--auto-merge' option, which would help
reduce the amount of text that requires manual merging.
Expecting a reroll.
* mf/submodule-summary-with-correct-repository (2020-06-24) 2 commits
- submodule: use submodule repository when preparing summary
- revision: use repository from rev_info when parsing commits
"git diff/show" on a change that involves a submodule used to read
the information on commits in the submodule from a wrong repository
and gave a wrong information when the commit-graph is involved.
Needs tests.
* dr/push-remoteref-fix (2020-04-23) 1 commit
- remote.c: fix handling of %(push:remoteref)
The "%(push:remoteref)" placeholder in the "--format=" argument of
"git format-patch" (and friends) only showed what got explicitly
configured, not what ref at the receiving end would be updated when
"git push" was used, as it ignored the default behaviour (e.g. update
the same ref as the source).
Expecting a reroll.
cf. <20200416152145.wp2zeibxmuyas6y6@feanor>
* mr/bisect-in-c-2 (2020-07-17) 14 commits
. SQUASH??? do not add new users of git_path_bisect_head()
. bisect--helper: retire `--bisect-autostart` subcommand
. bisect--helper: retire `--write-terms` subcommand
. bisect--helper: retire `--check-expected-revs` subcommand
. bisect--helper: reimplement `bisect_state` & `bisect_head` shell functions in C
. bisect--helper: retire `--next-all` subcommand
. bisect--helper: retire `--bisect-clean-state` subcommand
. bisect--helper: finish porting `bisect_start()` to C
. bisect--helper: reimplement `bisect_next` and `bisect_auto_next` shell functions in C
. bisect: call 'clear_commit_marks_all()' in 'bisect_next_all()'
. bisect--helper: reimplement `bisect_autostart` shell function in C
. bisect--helper: introduce new `write_in_file()` function
. bisect--helper: use '-res' in 'cmd_bisect__helper' return
. bisect--helper: BUG() in cmd_*() on invalid subcommand
Rewrite of the remainder of "git bisect" script in C continues.
Needs more work.
Ejected out of 'seen'; al/bisect-first-parent topic has a bit of
textual conflict with this topic.
* mk/use-size-t-in-zlib (2018-10-15) 1 commit
- zlib.c: use size_t for size
The wrapper to call into zlib followed our long tradition to use
"unsigned long" for sizes of regions in memory, which have been
updated to use "size_t".
--------------------------------------------------
[Cooking]
* jk/refspecs-cleanup (2020-08-17) 2 commits
(merged to 'next' on 2020-08-24 at 807a080ebf)
+ refspec: make sure stack refspec_item variables are zeroed
+ refspec: fix documentation referring to refspec_item
(this branch is used by jk/refspecs-negative.)
Preliminary code clean-up before introducing "negative refspec".
Will merge to 'master'.
* rs/checkout-no-overlay-pathspec-fix (2020-08-22) 1 commit
(merged to 'next' on 2020-08-27 at 277e39346d)
+ checkout, restore: make pathspec recursive
"git restore/checkout --no-overlay" with wildcarded pathspec
mistakenly removed matching paths in subdirectories, which has been
corrected.
Will merge to 'master'.
* al/bisect-first-parent (2020-08-22) 1 commit
(merged to 'next' on 2020-08-24 at f95fbf45a6)
+ bisect: add first-parent option to documentation
Finishing touches.
Will merge to 'master'.
* js/no-builtins-on-disk-option (2020-08-24) 3 commits
- ci: stop linking built-ins to the dashed versions
- install: optionally skip linking/copying the built-ins
- msvc: copy the correct `.pdb` files in the Makefile target `install`
The installation procedure learned to optionally omit "git-foo"
executable files for each 'foo' built-in subcommand, which are only
required by old timers that still rely on the age old promise that
prepending "git --exec-path" output to PATH early in their script
will keep the "git-foo" calls they wrote working.
The old attempt to remove these executables from the disk failed in
the 1.6 era; it may be worth attempting again, but I think it is
worth to keep this topic separate from such a policy change to help
it graduate early.
cf. https://public-inbox.org/git/7vprnzt7d5.fsf@gitster.siamese.dyndns.org/
* jt/threaded-index-pack (2020-08-27) 9 commits
- builtin/index-pack.c: fix some sparse warnings
- fixup! index-pack: make quantum of work smaller
- index-pack: make quantum of work smaller
- index-pack: make resolve_delta() assume base data
- index-pack: calculate {ref,ofs}_{first,last} early
- index-pack: remove redundant child field
- index-pack: unify threaded and unthreaded code
- index-pack: remove redundant parameter
- Documentation: deltaBaseCacheLimit is per-thread
"git index-pack" learned to resolve deltified objects with greater
parallelism.
* hn/refs-pseudorefs (2020-08-21) 4 commits
(merged to 'next' on 2020-08-24 at 3579abe8ff)
+ sequencer: treat REVERT_HEAD as a pseudo ref
+ builtin/commit: suggest update-ref for pseudoref removal
+ sequencer: treat CHERRY_PICK_HEAD as a pseudo ref
+ refs: make refs_ref_exists public
Accesses to two pseudorefs have been updated to properly use ref
API.
Will merge to 'master'.
* jt/promisor-pack-fix (2020-08-20) 1 commit
(merged to 'next' on 2020-08-24 at cd26d30d8d)
+ fetch-pack: in partial clone, pass --promisor
Updates into a lazy/partial clone with a submodule did not work
well with transfer.fsckobjects set.
Will merge to 'master'.
* hv/ref-filter-trailers-atom-parsing-fix (2020-08-21) 2 commits
(merged to 'next' on 2020-08-24 at 79b27f3263)
+ ref-filter: 'contents:trailers' show error if `:` is missing
+ t6300: unify %(trailers) and %(contents:trailers) tests
The parser for "git for-each-ref --format=..." was too loose when
parsing the "%(trailers...)" atom, and forgot that "trailers" and
"trailers:<modifers>" are the only two allowed forms, which has
been corrected.
Will merge to 'master'.
* jc/ident-whose-ident (2020-08-21) 1 commit
(merged to 'next' on 2020-08-27 at caf5149c28)
+ ident: say whose identity is missing when giving user.name hint
Error message update.
Will merge to 'master'.
* jk/index-pack-w-more-threads (2020-08-21) 3 commits
(merged to 'next' on 2020-08-24 at 18f18a5b66)
+ index-pack: adjust default threading cap
+ p5302: count up to online-cpus for thread tests
+ p5302: disable thread-count parameter tests by default
Long ago, we decided to use 3 threads by default when running the
index-pack task in parallel, which has been adjusted a bit upwards.
Will merge to 'master'.
* rp/apply-cached-doc (2020-08-20) 1 commit
(merged to 'next' on 2020-08-27 at 1d610f08ea)
+ git-apply.txt: update descriptions of --cached, --index
The description of --cached/--index options in "git apply --help"
has been updated.
Will merge to 'master'.
* dd/diff-customize-index-line-abbrev (2020-08-21) 2 commits
(merged to 'next' on 2020-08-24 at 74e842a2c8)
+ diff: index-line: respect --abbrev in object's name
+ t4013: improve diff-post-processor logic
The output from the "diff" family of the commands had abbreviated
object names of blobs involved in the patch, but its length was not
affected by the --abbrev option. Now it is.
Will merge to 'master'.
* hv/ref-filter-misc (2020-08-17) 9 commits
(merged to 'next' on 2020-08-27 at c015fa6b0f)
+ ref-filter: add `sanitize` option for 'subject' atom
+ format-support: move `format_sanitized_subject()` from pretty
+ pretty: refactor `format_sanitized_subject()`
+ ref-filter: add `short` modifier to 'parent' atom
+ ref-filter: add `short` modifier to 'tree' atom
+ ref-filter: rename `objectname` related functions and fields
+ ref-filter: modify error messages in `grab_objectname()`
+ ref-filter: refactor `grab_objectname()`
+ ref-filter: support different email formats
The "--format=" option to the "for-each-ref" command and friends
learned a few more tricks, e.g. the ":short" suffix that applies to
"objectname" now also can be used for "parent", "tree", etc.
Will merge to 'master'.
* jk/refspecs-negative (2020-08-21) 1 commit
- refspec: add support for negative refspecs
(this branch uses jk/refspecs-cleanup.)
"negative refspecs"
* jt/fetch-pack-loosen-validation-with-packfile-uri (2020-08-24) 3 commits
(merged to 'next' on 2020-08-27 at efd171f172)
+ fetch-pack: make packfile URIs work with transfer.fsckobjects
+ fetch-pack: document only_packfile in get_pack()
+ (various): document from_promisor parameter
Bugfix for "git fetch" when the packfile URI capability is in use.
Will merge to 'master'.
* mr/diff-hide-stat-wo-textual-change (2020-08-19) 1 commit
(merged to 'next' on 2020-08-27 at b9e97254ae)
+ diff: teach --stat to ignore uninteresting modifications
"git diff --stat -w" showed 0-line changes for paths whose changes
were only whitespaces, which was not intuitive. We now omit such
paths from the stat output.
Will merge to 'master'.
* pw/add-p-allowed-options-fix (2020-08-17) 2 commits
(merged to 'next' on 2020-08-27 at 6cd62753f7)
+ add -p: fix checking of user input
+ add -p: use ALLOC_GROW_BY instead of ALLOW_GROW
"git add -p" update.
Will merge to 'master'.
* jt/lazy-fetch (2020-08-18) 7 commits
(merged to 'next' on 2020-08-27 at 85f2319ba1)
+ fetch-pack: remove no_dependents code
+ promisor-remote: lazy-fetch objects in subprocess
+ fetch-pack: do not lazy-fetch during ref iteration
+ fetch: only populate existing_refs if needed
+ fetch: avoid reading submodule config until needed
+ fetch: allow refspecs specified through stdin
+ negotiator/noop: add noop fetch negotiator
Updates to on-demand fetching code in lazily cloned repositories.
Will merge to 'master'.
* jx/proc-receive-hook (2020-08-27) 10 commits
- doc: add documentation for the proc-receive hook
- transport: parse report options for tracking refs
- t5411: test updates of remote-tracking branches
- receive-pack: new config receive.procReceiveRefs
- doc: add document for capability report-status-v2
- New capability "report-status-v2" for git-push
- receive-pack: feed report options to post-receive
- receive-pack: add new proc-receive hook
- t5411: add basic test cases for proc-receive hook
- transport: not report a non-head push as a branch
"git receive-pack" that accepts requests by "git push" learned to
outsource most of the ref updates to the new "proc-receive" hook.
Looking good.
* pw/rebase-i-more-options (2020-08-26) 6 commits
(merged to 'next' on 2020-08-27 at c55cfeb247)
+ t3436: do not run git-merge-recursive in dashed form
(merged to 'next' on 2020-08-21 at ade71fd49b)
+ rebase: add --reset-author-date
+ rebase -i: support --ignore-date
+ rebase -i: support --committer-date-is-author-date
+ am: stop exporting GIT_COMMITTER_DATE
+ rebase -i: add --ignore-whitespace flag
"git rebase -i" learns a bit more options.
Will merge to 'master'.
* jk/slimmed-down (2020-08-13) 5 commits
(merged to 'next' on 2020-08-27 at bc8e9450c6)
+ drop vcs-svn experiment
+ make git-fast-import a builtin
+ make git-bugreport a builtin
+ make credential helpers builtins
+ Makefile: drop builtins from MSVC pdb list
Trim an unused binary and turn a bunch of commands into built-in.
Will merge to 'master'.
* ss/t7401-modernize (2020-08-21) 5 commits
(merged to 'next' on 2020-08-27 at 516cba9c64)
+ t7401: add a NEEDSWORK
+ t7401: change indentation for enhanced readability
+ t7401: change syntax of test_i18ncmp calls for clarity
+ t7401: use 'short' instead of 'verify' and cut in rev-parse calls
+ t7401: modernize style
Test clean-up.
Will merge to 'master'.
* ds/maintenance-part-2 (2020-08-25) 8 commits
- maintenance: add incremental-repack auto condition
- maintenance: auto-size incremental-repack batch
- maintenance: add incremental-repack task
- midx: use start_delayed_progress()
- midx: enable core.multiPackIndex by default
- maintenance: create auto condition for loose-objects
- maintenance: add loose-objects task
- maintenance: add prefetch task
(this branch uses ds/maintenance-part-1.)
"git maintenance", an extended big brother of "git gc", continues
to evolve.
* ss/submodule-summary-in-c (2020-08-12) 4 commits
(merged to 'next' on 2020-08-17 at 9bc352cb70)
+ submodule: port submodule subcommand 'summary' from shell to C
+ t7421: introduce a test script for verifying 'summary' output
+ submodule: rename helper functions to avoid ambiguity
+ submodule: remove extra line feeds between callback struct and macro
(this branch is used by ss/submodule-summary-in-c-fixes.)
Yet another subcommand of "git submodule" is getting rewritten in C.
Looking good.
* am/ci-wsfix (2020-08-21) 1 commit
(merged to 'next' on 2020-08-24 at 8491e031f1)
+ ci: fix inconsistent indentation
Aesthetic fix to a CI configuration file.
Will merge to 'master'.
* ds/maintenance-part-1 (2020-08-25) 11 commits
- maintenance: add trace2 regions for task execution
- maintenance: add auto condition for commit-graph task
- maintenance: use pointers to check --auto
- maintenance: create maintenance.<task>.enabled config
- maintenance: take a lock on the objects directory
- maintenance: add --task option
- maintenance: add commit-graph task
- maintenance: initialize task array
- maintenance: replace run_auto_gc()
- maintenance: add --quiet option
- maintenance: create basic maintenance runner
(this branch is used by ds/maintenance-part-2.)
A "git gc"'s big brother has been introduced to take care of more
repository maintenance tasks, not limited to the object database
cleaning.
Comments?
^ permalink raw reply
* Re: [PATCH] gitk: use the 'reference' format for the commit reference
From: Beat Bolli @ 2020-08-27 20:35 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Paul Mackerras, Git List
In-Reply-To: <CAPig+cRZEgu4GfMGSWQbs4cV9OGT9z7gKh8v8S+_sWmKFJd4Sg@mail.gmail.com>
On 27.08.20 18:26, Eric Sunshine wrote:
> On Thu, Aug 27, 2020 at 12:19 PM Beat Bolli <dev+git@drbeat.li> wrote:
>> Since 1f0fc1db85 (pretty: implement 'reference' format, 2019-11-19) in
>> the main Git repository, there's an officially blessed format for commit
>> references. Update gitk to also use this format.
>>
>> Signed-off-by: Beat Bolli <dev+git@drbeat.li>
>
> See this thread:
> https://lore.kernel.org/git/da9321b1bd56aafd16c8dcb99d5d628b79e2244e.1576100147.git.liu.denton@gmail.com/T/
Ooops, my memory is lacking!
Please ignore the noise...
^ permalink raw reply
* Re: post-checkout hook aborts rebase
From: Chris Torek @ 2020-08-27 20:32 UTC (permalink / raw)
To: Elijah Newren; +Cc: Junio C Hamano, Tom Rutherford, Git List
In-Reply-To: <CABPp-BEEmqdt2_OuNQFxyf6pkppBWptkcvuAYhWX8r+_Wr8-2g@mail.gmail.com>
> On Thu, Aug 27, 2020 at 12:07 PM Chris Torek <chris.torek@gmail.com> wrote:
> > The *last* checkout from the finished rebase perhaps *should* [invoke
a hook]
On Thu, Aug 27, 2020 at 1:11 PM Elijah Newren <newren@gmail.com> wrote:
> What do you mean by the "last checkout"? I believe a typical
> non-interactive rebase of N patches has only one checkout, and I don't
> see why running hooks for the starting point is relevant.
I meant for the final state after rewriting the commits -- but that's
actually the post-rewrite hook, not the post-checkout hook. I had them
conflated mentally when I wrote the above.
> If hooks are wanted for rebase, I'd still want to have rebase-specific
> ones, because most people who think of "checkout hooks" or "commit
> hooks" probably aren't going to think of them the way rebase or
> cherry-pick happen to use them. (And that might even be more true for
> --interactive and --rebase-merges cases.)
I agree with this.
Chris
^ permalink raw reply
* Re: post-checkout hook aborts rebase
From: Elijah Newren @ 2020-08-27 20:11 UTC (permalink / raw)
To: Chris Torek; +Cc: Junio C Hamano, Tom Rutherford, Git List
In-Reply-To: <CAPx1GvfXOMFDsXE74LiG_BG5Bqb+seHDWX69xGe49C240ORi6A@mail.gmail.com>
On Thu, Aug 27, 2020 at 12:07 PM Chris Torek <chris.torek@gmail.com> wrote:
>
> On Thu, Aug 27, 2020 at 8:51 AM Junio C Hamano <gitster@pobox.com> wrote:
> > I still suspect that the checkout run, merely as an implementation
> > detail of rebase (or any other git subcommand), should not trigger
> > any hook ...
>
> The *last* checkout from the finished rebase perhaps *should*, but
> other than that one, that seems logically correct.
What do you mean by the "last checkout"? I believe a typical
non-interactive rebase of N patches has only one checkout, and I don't
see why running hooks for the starting point is relevant.
If hooks are wanted for rebase, I'd still want to have rebase-specific
ones, because most people who think of "checkout hooks" or "commit
hooks" probably aren't going to think of them the way rebase or
cherry-pick happen to use them. (And that might even be more true for
--interactive and --rebase-merges cases.)
> > but before any such code change, at least let's update the
> > documentation to clarify what we mean by "the outcome".
> >
> > Hopefully something like the below may be a good starting point?
> >
> > Documentation/githooks.txt | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
> > index 31b601e4bc..cf95d6d02b 100644
> > --- a/Documentation/githooks.txt
> > +++ b/Documentation/githooks.txt
> > @@ -193,7 +193,9 @@ worktree. The hook is given three parameters: the ref of the previous HEAD,
> > the ref of the new HEAD (which may or may not have changed), and a flag
> > indicating whether the checkout was a branch checkout (changing branches,
> > flag=1) or a file checkout (retrieving a file from the index, flag=0).
> > -This hook cannot affect the outcome of `git switch` or `git checkout`.
> > +This hook cannot affect the outcome of `git switch` or `git checkout`,
> > +other than that the hook's exit status becomes the exit status of
> > +these two commands.
> >
> > It is also run after linkgit:git-clone[1], unless the `--no-checkout` (`-n`) option is
> > used. The first parameter given to the hook is the null-ref, the second the
>
> This looks good to me, and can either be independent of, or the first part of,
> any rebase update.
Patch looks good to me too.
^ permalink raw reply
* Re: [PATCH v19 00/10] New proc-receive hook for centralized workflow
From: Junio C Hamano @ 2020-08-27 19:57 UTC (permalink / raw)
To: Jiang Xin; +Cc: Git List, Jiang Xin
In-Reply-To: <20200827154551.5966-1-worldhello.net@gmail.com>
Jiang Xin <worldhello.net@gmail.com> writes:
> From: Jiang Xin <zhiyou.jx@alibaba-inc.com>
>
> ## Changes since v18
>
> 1. This series is based on "next" branch, in order to resolve a conflict
> with commit 95e7c38539 (refspec: make sure stack refspec_item
> variables are zeroed, 2020-08-14). See patch 9/10.
We cannot ever merge such a topic that depends on 'next' down to
'master' without dragging all the other topics that present in
'next', plus the merge commits that bring these topics to 'next'.
In this particular case, I think the conflict resolution is trivial
and more importantly, it is not a *new* conflict v19 introduces but
did not exist with v18. IOW, what is in 'seen' has already resolved
the same conflict between 95e7c38539 and this topic.
I've applied these directly on 'next' (call it c0), rebased the
result on the same base as v18 is queued on, and then merged the
rebased v19 (call it c1) with 'next' to make sure that the result
(call it c2) matches, i.e. tree of c0 and tree of c2 are identical.
I'll use c1 to replace what is queued in 'seen'.
A workable alternative would be to base these on top of the topic
that contains 95e7c38539 (i.e. jk/refspecs-cleanup). Then, this
topic is still taken hostage by that 'cleanup' topic, but at least
as long as that topic graduates, this topic can graduate to 'master'
without having to drag any other cruft with it.
Thanks.
^ permalink raw reply
* Re: [PATCH] send-email: do not prompt for In-Reply-To
From: Carlo Arenas @ 2020-08-27 19:46 UTC (permalink / raw)
To: Drew DeVault; +Cc: Junio C Hamano, git
In-Reply-To: <C5814BWVXMP3.1GJ83FMKYSFTY@homura>
On Thu, Aug 27, 2020 at 12:35 PM Drew DeVault <sir@cmpwn.com> wrote:
> Do you think this whole workstream could be averted by dropping the
> $prompting check in the in-reply-to branch?
>
> Or would that still constitute a breaking change to user workflows?
I think the "breaking change" is changing the default (which needs
fixing as well).
but an interesting idea would be to add a config so the prompting
could be skipped which would be something that people could add to
their per repository config (as needed).
Carlo
^ permalink raw reply
* Re: [PATCH] send-email: do not prompt for In-Reply-To
From: Drew DeVault @ 2020-08-27 19:34 UTC (permalink / raw)
To: Junio C Hamano, Carlo Marcelo Arenas Belón; +Cc: Drew DeVault, git
In-Reply-To: <xmqqtuwnq3x1.fsf@gitster.c.googlers.com>
Do you think this whole workstream could be averted by dropping the
$prompting check in the in-reply-to branch?
Or would that still constitute a breaking change to user workflows?
^ permalink raw reply
* Re: [PATCH] send-email: do not prompt for In-Reply-To
From: Carlo Marcelo Arenas Belón @ 2020-08-27 19:32 UTC (permalink / raw)
To: Drew DeVault; +Cc: Junio C Hamano, git
In-Reply-To: <C580VF2ZNJ0D.2WFFMIG1B5LO3@homura>
On Thu, Aug 27, 2020 at 03:23:00PM -0400, Drew DeVault wrote:
> I can reproduce both on git 2.28.0 and on github.com/git/git master.
and you use --compose to send an email thread directly instead of
doing first `git-format-patch -o`?
Carlo
^ permalink raw reply
* Re: [PATCH] send-email: do not prompt for In-Reply-To
From: Junio C Hamano @ 2020-08-27 19:34 UTC (permalink / raw)
To: Carlo Marcelo Arenas Belón; +Cc: Drew DeVault, git
In-Reply-To: <20200827192029.GA63138@Carlos-MBP>
Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:
> On Thu, Aug 27, 2020 at 03:14:57PM -0400, Drew DeVault wrote:
>> Do you have sendemail.to set in your local git config?
>
> I do and can't reproduce either; which version of git do you have this
> problem with?
Any recent version of git-send-email, I would say. The relevant
code snippets are:
my $prompting = 0;
if (!@initial_to && !defined $to_cmd) {
my $to = ask("$to_whom ",
default => "",
valid_re => qr/\@.*\./, confirm_only => 1);
push @initial_to, parse_address_line($to) if defined $to; #
$prompting++;
}
...
@initial_to = process_address_list(@initial_to);
@initial_cc = process_address_list(@initial_cc);
@initial_bcc = process_address_list(@initial_bcc);
if ($thread && !defined $initial_in_reply_to && $prompting) {
$initial_in_reply_to = ask(
__("Message-ID to be used as In-Reply-To for the first email (if any)? "),
default => "",
valid_re => qr/\@.*\./, confirm_only => 1);
}
where initial_to is set either from the command line or sendemail.to
configuration variable and before the control reaches this section
of the code. In addition to realizing "ah, To: address is not given
so we need to ask" and ask the to address, it says "since we have
already interatively asked the end-user anyway, we can and should
ask other things as well" by incrementing $prompting.
That feels both understandable and bogus at the same time. To:
is pretty much required (yes, you can use cc: and bcc: without any
address on To:, but that is not something you'd usually do to send
patches to mailing lists), so lack of it means either asking
interactively or aborting. But other things like in-reply-to are
optional, and tying the decision to prompt for them or not does not
feel OK.
^ permalink raw reply
* Re: [PATCH 1/5] worktree: add skeleton "repair" command
From: Eric Sunshine @ 2020-08-27 19:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Henré Botha, Jeff King
In-Reply-To: <xmqqr1rsqdga.fsf@gitster.c.googlers.com>
On Thu, Aug 27, 2020 at 12:08 PM Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
> > At this stage, the "repair" command is a mere skeleton; subsequent
> > commits will flesh out the functionality.
>
> Sounds good. It looked a bit odd to have skeleton test script only
> to reserve its test number, but it is just odd and not wrong.
The intent wasn't to reserve a test number. Rather, I was worried
about reviewer fatigue with patches [2/5] and [3/5] which are lengthy,
so I moved whatever boilerplate I could to [1/5] to make the later
patches a tiny bit shorter.
^ permalink raw reply
* Re: [PATCH] send-email: do not prompt for In-Reply-To
From: Drew DeVault @ 2020-08-27 19:23 UTC (permalink / raw)
To: Carlo Marcelo Arenas Belón; +Cc: Junio C Hamano, git
In-Reply-To: <20200827192029.GA63138@Carlos-MBP>
I can reproduce both on git 2.28.0 and on github.com/git/git master.
^ permalink raw reply
* Re: [PATCH] send-email: do not prompt for In-Reply-To
From: Drew DeVault @ 2020-08-27 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqy2lzq4h4.fsf@gitster.c.googlers.com>
On Thu Aug 27, 2020 at 3:21 PM EDT, Junio C Hamano wrote:
> Yes, and I'd assume most mailing list have a single to: address, and
> people use a repository to interact with just a single project, so I
> think it would be natural to have it in the per-repository
> configuration file. Is it true that you do not set it and that the
> lack of the configuration is why you are getting prompted?
No, this didn't make sense, I was mistaken. This shouldn't be the cause.
^ permalink raw reply
* Re: [PATCH] send-email: do not prompt for In-Reply-To
From: Carlo Marcelo Arenas Belón @ 2020-08-27 19:20 UTC (permalink / raw)
To: Drew DeVault; +Cc: Junio C Hamano, git
In-Reply-To: <C580P9BS4VYA.15I6SHXQQ35HF@homura>
On Thu, Aug 27, 2020 at 03:14:57PM -0400, Drew DeVault wrote:
> Do you have sendemail.to set in your local git config?
I do and can't reproduce either; which version of git do you have this
problem with?
Carlo
^ permalink raw reply
* Re: [PATCH] send-email: do not prompt for In-Reply-To
From: Junio C Hamano @ 2020-08-27 19:21 UTC (permalink / raw)
To: Drew DeVault; +Cc: git
In-Reply-To: <C580P9BS4VYA.15I6SHXQQ35HF@homura>
"Drew DeVault" <sir@cmpwn.com> writes:
> Do you have sendemail.to set in your local git config?
Yes, and I'd assume most mailing list have a single to: address, and
people use a repository to interact with just a single project, so I
think it would be natural to have it in the per-repository
configuration file. Is it true that you do not set it and that the
lack of the configuration is why you are getting prompted?
I suspect that it may not make much sense for the presense of
sendemail.to to affect prompting for other header fields (iow, my
not getting prompted might be a bug).
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox