* Re: [PATCH v2 0/2] environment: move ignore_case into repo_config_values
From: Junio C Hamano @ 2026-06-18 13:14 UTC (permalink / raw)
To: Tian Yuchen; +Cc: git, ps, phillip.wood123, johannes.schindelin, stolee
In-Reply-To: <20260618114207.605211-1-cat@malon.dev>
Tian Yuchen <cat@malon.dev> writes:
> Related materials:
>
> [1] In this patch to migrate protect_hfs and protect_ntfs, the approach
> of introducing getters has been endorsed.
>
> [2] Derrick Stolee's previous attempt. The reasons for the failure are
> also mentioned in [1].
[1] here refers to the starting message of the whole hfs/ntfs thing.
Do you mean that people must read the entire thread to find out what
the reasons for the failure was? For that matter, it is not clear,
unless readers read the whole thread, where the approach of using
getters was "endorsed", either.
> [1] https://lore.kernel.org/git/20260606143412.15443-1-cat@malon.dev/
> [2] https://lore.kernel.org/git/2b4198c09cb6c04c60608d19072d419503dfe5df.1685716421.git.gitgitgadget@gmail.com/
> Changes since V1:
>
> - s/repo_get_ignore_case()/repo_ignore_case()
>
> - Use repo->initialized instead of repo->gitdir
I do not think I have any objections to these changes from the
previous iteration. There may be some other things in the new
iteration but I'll have to go in and read the patches to find them
out (if they exist).
Thanks.
^ permalink raw reply
* Re: [PATCH v5 2/2] graph: indent visual root in graph
From: Junio C Hamano @ 2026-06-18 13:31 UTC (permalink / raw)
To: Pablo Sabater
Cc: Jeff King, git, ayu.chandekar, chandrapratap3519,
christian.couder, jltobler, karthik.188, phillip.wood,
siddharthasthana31
In-Reply-To: <CAN5EUNSQY2oK7BE4J9Y8APfkP6eJxta050OUu=RoJYhXOjX_OA@mail.gmail.com>
Pablo Sabater <pabloosabaterr@gmail.com> writes:
> Should I work with 'next' as a base to have dd4bc01c0a? (Sorry I've
> just worked with master).
As dd4bc01c (revision: use priority queue for non-limited streaming
walks, 2026-05-27) is already in 'master', you should be able to
work with 'master' that is no stale than 6e148f82 (Merge branch
'kk/streaming-walk-pqueue', 2026-06-16).
^ permalink raw reply
* Re: [PATCH v14 4/6] branch: add --prune-merged <branch>
From: Phillip Wood @ 2026-06-18 13:42 UTC (permalink / raw)
To: Harald Nordgren
Cc: Harald Nordgren via GitGitGadget, git, Kristoffer Haugsbakk,
Johannes Sixt
In-Reply-To: <CAHwyqnUsjpCHfS=eBphmkdDGYpQZ_LQUJi1mjrxV8ZXi+w4yhg@mail.gmail.com>
Hi Harald
On 16/06/2026 20:15, Harald Nordgren wrote:
>>> diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
>>> index 4e7deddc04..27ea1319bb 100755
>>> --- a/t/t3200-branch.sh
>>> +++ b/t/t3200-branch.sh
>>> @@ -1809,4 +1809,205 @@ test_expect_success '--forked requires a value' '
>>> test_grep "requires a value" err
>>> '
>>>
>>> +test_expect_success '--prune-merged: setup' '
>>> + test_create_repo pm-upstream &&
>>
>> The rest of this test would be easier to read if we did
>>
>> (
>> cd pm-upstream &&
>> ...
>> )
>>
>> rather than prefixing every command with "-C pm-upstream"
>
> I feel like the discussion to nest or not to nest has come up many
> times in other topics as well. I don't feel strongly about either way,
> but I just want to flag that if I change it now, another reviewer
> might ask me to change it back later.
>
> Should the rules be to nest inside of setup functions (and helpers?)
> but not inside the actual tests?
I think it depends on how many commands you're running in a row in the
same directory. In this case we're running quite a few commands so it
seems clearer to use a subshell. In the later tests we're switching
between repositories and running fewer commands in each one so it is
less clear that using subshells is clearer. Also later on we're using
test_config() which I don't think works in a subshell because it relies
on test_when_finished().
One thing I've just thought of related to this patch is whether we want
to protect branches that are the upstreams of branches that are not
slated for deletion. With stacked branches it is possible that a branch
has been merged but has other branches stacked on top of it that have
not been merged. If we build an strset of branches that we want to
delete, then loop over all branches and if there are any that are not in
the to be deleted set which have their upstream in that set we'd remove
the upstream branch from the set. Once we've done that we can convert
the set to an strvec to pass to delete_branches()
Thanks
Phillip
>
>>> + test_commit -C pm-upstream base &&
>>> + git -C pm-upstream checkout -b next &&
>>> + test_commit -C pm-upstream one-commit &&
>>> + test_commit -C pm-upstream two-commit &&
>>> + git -C pm-upstream branch one HEAD~ &&
>>> + git -C pm-upstream branch two HEAD &&
>>> + git -C pm-upstream branch wip main &&
>>> + git -C pm-upstream checkout main &&
>>> + test_create_repo pm-fork
>>> +'
>>> +
>>> +test_expect_success '--prune-merged deletes branches integrated into upstream' '
>>> + test_when_finished "rm -rf pm-merged" &&
>>> + git clone pm-upstream pm-merged &&
>>> + git -C pm-merged remote add fork ../pm-fork &&
>>> + test_config -C pm-merged remote.pushDefault fork &&
>>> + test_config -C pm-merged push.default current &&
>>
>> So we clone upstream and add fork as the default push remote. I find the
>> pm- prefixes rather distracting. It would be clearer to me if we just
>> called the repositories "upstream", "fork" and "repo"
>
> Good point.
>
>>> + test_must_fail git -C pm-local rev-parse --verify refs/heads/one
>>> +'
>>> +
>>> +test_expect_success '--prune-merged warns instead of erroring on un-integrated commits' '
>>> + test_when_finished "rm -rf pm-unmerged" &&
>>> + git clone pm-upstream pm-unmerged &&
>>> + git -C pm-unmerged remote add fork ../pm-fork &&
>>> + test_config -C pm-unmerged remote.pushDefault fork &&
>>> + test_config -C pm-unmerged push.default current &&
>>> + git -C pm-unmerged checkout -b wip origin/wip &&
>>> + git -C pm-unmerged branch --set-upstream-to=origin/next wip &&
>>> + test_commit -C pm-unmerged local-only &&
>>> + git -C pm-unmerged checkout - &&
>>> +
>>> + git -C pm-unmerged branch --prune-merged "origin/*" 2>err &&
>>> + test_grep "not fully merged" err &&
>>> + test_grep ! "If you are sure you want to delete it" err &&
>>
>> I'm always suspicious of test_grep when we know what the output should
>> look like - it might be better to use test_cmp. This test does not check
>> that we also delete branches that are merged when we see one that isn't.
>>
>> I'm going to stop here - the tests I've read seem to me to be too much
>> like unit tests checking one aspect of the implementation in isolation
>> rather than checking that the whole feature works as expected.
>
> I'll respond to the rest here: Excellent points regarding the testing
> aboce, I will take a look at doing this.
>
>
> Harald
>
^ permalink raw reply
* Re: [PATCH v15 0/7] branch: delete-merged
From: Phillip Wood @ 2026-06-18 13:48 UTC (permalink / raw)
To: Harald Nordgren, phillip.wood
Cc: Harald Nordgren via GitGitGadget, git, Kristoffer Haugsbakk,
Johannes Sixt
In-Reply-To: <CAHwyqnWFM2jskm6soEu58tp_TgO3fmuODD-yTiK6-4Hpv8SMLQ@mail.gmail.com>
Hi Harald
On 17/06/2026 20:11, Harald Nordgren wrote:
>> Right but you sent that version a few hours after I'd posted a partial
>> review which concluded by saying I'd finish it the next day. If you send
>> a new version when you are waiting for further comments it clutters the
>> list because you know you're going to have to post another revision when
>> you get the rest of the comments. Anyone reviewing the interim version
>> is wasting their time. When you receive review comments, by all means
>> start thinking about them and updating your local copy but please don't
>> post a new version until the discussion on the previous version has
>> settled down.
>
> That's fair. Sorry about that.
>
> Will you let me know when your review here is finished?
I've just sent a mail with another comment but that concudes this round
unless you have any questions about it.
>
> I received the same feedback from Junio before, so I'm not unaware of
> this problem. I am trying to slow down. I often prepare the work as
> soon as I get some comments -- I'm on paternity leave so I have a lot
> of time when the baby is sleeping --
Congratulations - I hope the baby is sleeping at night as well in the day!
> then I actively hold off on
> sending to not overload the rest of you. But at the same time I think
> it's valuable to keep up a certain pace. It's a balancing act.
It is worth waiting for the discussion to settle on each round, I'll try
and be clear when I've finished looking at each revision. I'm sure other
folks would appreciate you looking at their patches and commenting on
them while you're waiting for feedback on yours, especially the GSoC
project students.
Thanks
Phillip
^ permalink raw reply
* [PATCH] zlib: properly clamp to uLong
From: Johannes Schindelin via GitGitGadget @ 2026-06-18 13:50 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Johannes Schindelin
From: Johannes Schindelin <johannes.schindelin@gmx.de>
On platforms where `unsigned long` and `size_t` differ in bit size, we
want to clamp the buffers we pass to zlib to the former's size, as per
d05d666977 (git-zlib: handle data streams larger than 4GB, 2026-05-08).
The logic introduced in that commit performs a clamping to the bits,
though, which fails to do what is needed here: If too many bytes are
available in the buffers, we need to clamp to the maximum value of an
`unsigned long`. Otherwise, we ask zlib to use too small buffers, in the
worst case using 0 as the size (think: a value whose 32 lowest bits are
all zero).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
zlib: properly clamp to uLong
I re-read this logic earlier this week... and I am quite convinced that
it needs to be fixed.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2153%2Fdscho%2Ffix-ulong-clamping-for-zlib-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2153/dscho/fix-ulong-clamping-for-zlib-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2153
git-zlib.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/git-zlib.c b/git-zlib.c
index b91cb323ae..d21adb3bf5 100644
--- a/git-zlib.c
+++ b/git-zlib.c
@@ -38,12 +38,17 @@ static inline uInt zlib_buf_cap(unsigned long len)
return (ZLIB_BUF_MAX < len) ? ZLIB_BUF_MAX : len;
}
+static inline uLong zlib_uLong_cap(size_t s)
+{
+ return s < ULONG_MAX_VALUE ? (uLong)s : ULONG_MAX_VALUE;
+}
+
static void zlib_pre_call(git_zstream *s)
{
s->z.next_in = s->next_in;
s->z.next_out = s->next_out;
- s->z.total_in = (uLong)(s->total_in & ULONG_MAX_VALUE);
- s->z.total_out = (uLong)(s->total_out & ULONG_MAX_VALUE);
+ s->z.total_in = zlib_uLong_cap(s->total_in);
+ s->z.total_out = zlib_uLong_cap(s->total_out);
s->z.avail_in = zlib_buf_cap(s->avail_in);
s->z.avail_out = zlib_buf_cap(s->avail_out);
}
@@ -60,7 +65,7 @@ static void zlib_post_call(git_zstream *s, int status)
* We track our own totals and verify only the low bits match.
*/
if ((s->z.total_out & ULONG_MAX_VALUE) !=
- ((s->total_out + bytes_produced) & ULONG_MAX_VALUE))
+ ((zlib_uLong_cap(s->total_out) + bytes_produced) & ULONG_MAX_VALUE))
BUG("total_out mismatch");
/*
* zlib does not update total_in when it returns Z_NEED_DICT,
@@ -68,7 +73,7 @@ static void zlib_post_call(git_zstream *s, int status)
*/
if (status != Z_NEED_DICT &&
(s->z.total_in & ULONG_MAX_VALUE) !=
- ((s->total_in + bytes_consumed) & ULONG_MAX_VALUE))
+ ((zlib_uLong_cap(s->total_in) + bytes_consumed) & ULONG_MAX_VALUE))
BUG("total_in mismatch");
s->total_out += bytes_produced;
base-commit: 7a094d68a27e321a99c8ab6b700909e503904bd9
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH] gitlab-ci: migrate Windows builds away from Chocolatey
From: Justin Tobler @ 2026-06-18 14:03 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <ajOE2XMBzgrXxbH8@pks.im>
On 26/06/18 07:40AM, Patrick Steinhardt wrote:
> On Wed, Jun 17, 2026 at 03:03:39PM -0500, Justin Tobler wrote:
> > On 26/06/15 02:21PM, Patrick Steinhardt wrote:
> > > before_script:
> > > - *windows_before_script
> > > - - choco install -y git meson ninja rust-ms
> > > - - Import-Module $env:ChocolateyInstall\helpers\chocolateyProfile.psm1
> > > - - refreshenv
> > > + - ./ci/install-dependencies.ps1
> > > + - $env:Path = "C:\Meson;C:\Rust\bin;$env:Path"
> >
> > I assume Git is already discoverable on the path?
>
> Good question -- in fact it's not, but in Meson we know to use the
> well-known path of "C:\Program Files\Git" automatically and that's why
> we don't have to add it here. That certainly is a bit hacky, but I'm not
> sure whether we need to change it.
>
> Just let me know if you think so.
If it's only Meson that needs to locate Git and it is already capable of
doing that without updating the path here, this is probably fine as-is.
We could maybe explain this to future reader in a comment? But I'm not
sure it matters too much and is likely not worth a reroll IMO.
Overall this patch looks good to me.
-Justin
^ permalink raw reply
* Re: [PATCH v2 7/8] refs: fix recursing `get_main_ref_store()` with "onbranch" config
From: Justin Tobler @ 2026-06-18 14:15 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Karthik Nayak, Jeff King
In-Reply-To: <ajOJM8EvGWWkYNuL@pks.im>
On 26/06/18 07:59AM, Patrick Steinhardt wrote:
> On Wed, Jun 17, 2026 at 01:41:40PM -0500, Justin Tobler wrote:
> > Is this really the best signal to indicate that a repository ref store
> > has not been initialized? Temporarily setting the storage format to
> > REF_STORAGE_FORMAT_UNKNOWN feels rather awkward and suggests to me that
> > `include_by_branch()` probably shouldn't be using it to begin with if
> > its not reliable.
>
> True, but we don't really have a better signal to the best of my
> knowledge. Ideally, we'd be able to use the existence `r->refs_private`
> as signal. But that doesn't really work as the reference database is
> lazily constructed, and the recursion happens in the exact function that
> would construct it in the first place. And there indeed are cases where
> reading the configuration is the first caller of `get_main_ref_store()`.
Ok, my first thought was also whether we could use the existence of the
ref store as a signal, but I guess that won't work here.
> My first internal iteration tried to make this non-lazily constructed so
> that we can use it as a proper signal. But that led to a bunch of
> problems where we now parsed configuration way earlier than we currently
> do, and that in turn led to all kinds of errors. I was able to fix all
> of those errors except one: we expect `git config set` to work in a
> misconfigured repository so that the user can fix the misconfig without
> having to manually edit the Git configuration files. But when
> constructing the refdb eagerly we will die early in such cases.
>
> We could again work around that issue, but that unfortunately evolved
> into a proper mess that I eventually discarded as unworkable. I think
> this is an inherent design flaw: constructing the refdb requires us to
> be able to parse the configuration, but constructing the configuration
> may require us to construct the refdb. So this awkwardness is built into
> Git's design, unfortunately.
>
> So I'd really love to have a better signal, as I fully agree that the
> above workaround is nothing more but a hack. But I'm just not sure what
> that signal would be. And this version here does exactly what we want:
> we honor "onbranch" conditionals in all cases, except when constructing
> the main reference store. Even if it's ugly.
Could we embed an `initialized` boolean in `struct ref_store` that gets
set when the ref store is properly initialized and use that as a signal
instead? I'm not sure how complex introducing this would be though.
-Justin
^ permalink raw reply
* [PATCH] help: prompt user to run corrected command on typo
From: calicomills @ 2026-06-18 14:26 UTC (permalink / raw)
To: git; +Cc: gitster
From 0dc9e5c4593611b75e7003e8fdbea9370524c05b Mon Sep 17 00:00:00 2001
From: calicomills <jishnuck26@gmail.com>
Date: Thu, 18 Jun 2026 19:47:12 +0530
Subject: [PATCH] help: prompt user to run corrected command on typo
When a user mistypes a git command and there is exactly one similar
command, git currently prints a suggestion but exits, requiring the
user to retype the corrected command manually.
Instead, when stdin and stderr are both connected to a terminal and
there is a single best match, prompt the user with:
Did you mean 'git checkout neo'? [y/N]
The full corrected invocation (command + original arguments) is shown
in the prompt so the user knows exactly what will run. Answering 'y'
re-executes git with the corrected command and all original arguments.
Answering anything else exits as before.
When there are multiple similarly-named commands, or when running
non-interactively (scripts, pipes), the original behaviour of printing
the suggestion list and exiting is preserved.
The help_unknown_cmd() signature is updated to accept the full args
vector so the prompt can include the original arguments alongside the
corrected command name.
Add tests to t9003 covering:
- non-interactive single match: falls back to suggestion list
- non-interactive multiple matches: falls back to suggestion list
- interactive single match, 'y': corrected command runs (TTY prereq)
- interactive single match, 'n': exits cleanly (TTY prereq)
Signed-off-by: calicomills <jishnuck26@gmail.com>
---
builtin/help.c | 2 +-
git.c | 2 +-
help.c | 40 ++++++++++++++++++++++------
help.h | 3 ++-
t/t9003-help-autocorrect.sh | 53 +++++++++++++++++++++++++++++++++++++
5 files changed, 89 insertions(+), 11 deletions(-)
diff --git a/builtin/help.c b/builtin/help.c
index a140339999..b17e61ccc8 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -618,7 +618,7 @@ static char *check_git_cmd(const char *cmd)
}
if (exclude_guides)
- return help_unknown_cmd(cmd);
+ return help_unknown_cmd(cmd, NULL);
return xstrdup(cmd);
}
diff --git a/git.c b/git.c
index 36f08891ef..d379cc85bb 100644
--- a/git.c
+++ b/git.c
@@ -994,7 +994,7 @@ int cmd_main(int argc, const char **argv)
exit(1);
}
if (!done_help) {
- char *assumed = help_unknown_cmd(cmd);
+ char *assumed = help_unknown_cmd(cmd, &args);
strvec_replace(&args, 0, assumed);
free(assumed);
cmd = args.v[0];
diff --git a/help.c b/help.c
index 46241492ce..30f32a7206 100644
--- a/help.c
+++ b/help.c
@@ -641,7 +641,7 @@ static const char bad_interpreter_advice[] =
N_("'%s' appears to be a git command, but we were not\n"
"able to execute it. Maybe git-%s is broken?");
-char *help_unknown_cmd(const char *cmd)
+char *help_unknown_cmd(const char *cmd, const struct strvec *args)
{
struct help_unknown_cmd_config cfg = { 0 };
int i, n, best_similarity = 0;
@@ -762,13 +762,37 @@ char *help_unknown_cmd(const char *cmd)
fprintf_ln(stderr, _("git: '%s' is not a git command. See 'git --help'."), cmd);
if (SIMILAR_ENOUGH(best_similarity)) {
- fprintf_ln(stderr,
- Q_("\nThe most similar command is",
- "\nThe most similar commands are",
- n));
-
- for (i = 0; i < n; i++)
- fprintf(stderr, "\t%s\n", main_cmds.names[i]->name);
+ if (n == 1 && isatty(0) && isatty(2)) {
+ char *answer;
+ struct strbuf msg = STRBUF_INIT;
+ struct strbuf full_cmd = STRBUF_INIT;
+ strbuf_addstr(&full_cmd, main_cmds.names[0]->name);
+ if (args) {
+ for (size_t j = 1; j < args->nr; j++) {
+ strbuf_addch(&full_cmd, ' ');
+ strbuf_addstr(&full_cmd, args->v[j]);
+ }
+ }
+ strbuf_addf(&msg, _("\nDid you mean 'git %s'? [y/N] "),
+ full_cmd.buf);
+ strbuf_release(&full_cmd);
+ answer = git_prompt(msg.buf, PROMPT_ECHO);
+ strbuf_release(&msg);
+ if (starts_with(answer, "y") || starts_with(answer, "Y")) {
+ char *assumed = xstrdup(main_cmds.names[0]->name);
+ cmdnames_release(&cfg.aliases);
+ cmdnames_release(&main_cmds);
+ cmdnames_release(&other_cmds);
+ return assumed;
+ }
+ } else {
+ fprintf_ln(stderr,
+ Q_("\nThe most similar command is",
+ "\nThe most similar commands are",
+ n));
+ for (i = 0; i < n; i++)
+ fprintf(stderr, "\t%s\n", main_cmds.names[i]->name);
+ }
}
exit(1);
diff --git a/help.h b/help.h
index c54bf0977d..a8c465b3df 100644
--- a/help.h
+++ b/help.h
@@ -32,7 +32,8 @@ void list_all_other_cmds(struct string_list *list);
void list_cmds_by_category(struct string_list *list,
const char *category);
void list_cmds_by_config(struct string_list *list);
-char *help_unknown_cmd(const char *cmd);
+#include "strvec.h"
+char *help_unknown_cmd(const char *cmd, const struct strvec *args);
void load_command_list(const char *prefix,
struct cmdnames *main_cmds,
struct cmdnames *other_cmds);
diff --git a/t/t9003-help-autocorrect.sh b/t/t9003-help-autocorrect.sh
index 8da318d2b5..6fe2da1595 100755
--- a/t/t9003-help-autocorrect.sh
+++ b/t/t9003-help-autocorrect.sh
@@ -70,4 +70,57 @@ test_expect_success 'autocorrect works in work tree created from bare repo' '
git -C worktree -c help.autocorrect=immediate status
'
+# Default behaviour (no help.autocorrect set): when there is exactly one
+# similar command but the session is non-interactive, fall back to printing
+# the suggestion list and exiting rather than showing a prompt.
+test_expect_success 'default: single match non-interactive shows suggestion and fails' '
+ test_might_fail git config --unset help.autocorrect &&
+
+ test_must_fail git lfg 2>actual &&
+ grep "most similar command" actual &&
+ grep "lgf" actual
+'
+
+test_expect_success 'default: multiple matches non-interactive shows list and fails' '
+ test_might_fail git config --unset help.autocorrect &&
+
+ test_must_fail git com 2>actual &&
+ grep "most similar commands" actual &&
+ grep "commit" actual
+'
+
+# Interactive prompt tests require a real TTY. On macOS the TTY prereq is
+# skipped due to IO::Pty reliability issues; these tests run on Linux CI.
+test_expect_success TTY 'default: single match interactive, answer y runs command' '
+ git config --unset help.autocorrect &&
+
+ write_script git-typotest <<-\EOF &&
+ echo typotest-ran
+ EOF
+ PATH="$PATH:." export PATH &&
+
+ # Feed "y" to /dev/tty via a wrapper that answers the prompt
+ write_script answer-prompt <<-\EOF &&
+ # Write the answer to the controlling terminal
+ printf "y\n" >/dev/tty
+ exec "$@"
+ EOF
+
+ test_terminal ./answer-prompt git typotest 2>err >out &&
+ grep "typotest-ran" out &&
+ grep "Did you mean" err
+'
+
+test_expect_success TTY 'default: single match interactive, answer n exits cleanly' '
+ git config --unset help.autocorrect &&
+
+ write_script answer-prompt-no <<-\EOF &&
+ printf "n\n" >/dev/tty
+ exec "$@"
+ EOF
+
+ test_must_fail test_terminal ./answer-prompt-no git typotest 2>err &&
+ grep "Did you mean" err
+'
+
test_done
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v2] SubmittingPatches: address design critiques
From: Kristoffer Haugsbakk @ 2026-06-18 14:43 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <xmqqpl1oteoi.fsf@gitster.g>
On Thu, Jun 18, 2026, at 10:50, Junio C Hamano wrote:
> Contributors sometimes fail to answer fundamental design or
> viability comments from reviewers and submit subsequent rounds
> without addressing them. When design decisions are resolved on the
> mailing list, the final justification should be recorded in the
> commit messages.
It’s useful to explain design decisions etc. that were not committed to
in the commit message. It’s yet another thing that might be far from
obvious during review, but when the message is written only the option
that was landed on is explained.
>[snip]
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index f042bb5aaf..bbe759f3d9 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -51,6 +51,21 @@ area.
> respond to them with "Reply-All" on the mailing list, while taking
> them into account while preparing an updated set of patches.
> +
> +You should be particularly mindful of critiques regarding the
> +high-level design or viability of your proposal (e.g., questioning
> +whether the feature is worth implementing, or if the chosen approach
> +is appropriate). Defend your design decisions on the list first, to
> +avoid wasting effort on an implementation whose design is not yet
> +solid.
To take it to the other extreme, there are “contributions” which are
design decisions *only*, no implementation. Namely emails which sketch a
design like a new option. Those are often met with a stock response
saying:[1] submit some code, doesn’t have to implement it fully, but we
will need some code to proceed here. I’ve never understood that stance,
and I don’t think it harmonizes with the sentence here of sparing effort
if the design is not solid.
Many of these emails are straightforward.
1. I want this thing
2. I can implement it but I don’t know if *would be* accepted (and
implementing things here would be a lot of effort for me, personally)
3. Would it be?
And the only thing I personally would change is to weaken “would be?” to
“could be?”. Then with that out in the world, maybe someone finds this
message this day or the next week or month and reports that at least
they would like this thing.
Some people could change something small in this code base as easily as
they could propose the change idea for it (so it seems to me). They
would just have to take a walk and watch a movie to let their
subconscious process whether it was a good idea or not... But for most
people, committing to implementing something in a new codebase without
spooky assistance (...) is a task that takes a lot of effort.
To illustrate a related point, there are at least three kinds of Git
users out there:
1. Experienced C developers
2. Experienced Git developers (heavy overlap with (1))
3. Experienced and partisan Git users (knows it, believes in it)
You can imagine someone from group number 1 who is *not* in group number
3 use a weekend to implement something. But then when it is submitted it
turns out that is a very “centralized CVS” idea which doesn’t fit into
git(1) at all. That’s easily spotted by group number 3 by just looking
at the proposed docs or design. Now that group number 1 individual might
just have a bunch of code that is dead weight for any proper Git
workflow.
So I don’t understand this canned response.
There is the unofficial project idea tracker on the GitGitGadget
fork. But it seems weird to post things there and not on the mailing
list.
† 1: From `git show todo:CannedResponses`:
| [make us come to you, begging]
|
| I've seen from time to time people ask "I am thinking of doing this;
| will a patch be accepted? If so, I'll work on it." before showing
| any work, and my response always has been:
|
| (1) We don't know how useful and interesting your contribution would
| be for our audience, until we see it; and
|
| (2) If you truly believe in your work (find it useful, find writing
| it fun, etc.), that would be incentive enough for you to work
| on it, whether or not the result will land in my tree. You
| should instead aim for something so brilliant that we would
| come to you begging for your permission to include it in our
| project.
Note that point (2) is a bit more ambitious than it looks; if the
idea is to implement your own thing for your own fork/tree and then
maintain it yourself if upstream git.git doesn not accept it, well,
now you need to learn how to maintain a fork for however long you
want that feature. If you did not already know that.
> ++
> +Make sure that any new version is accompanied by a much clearer
> +explanation and justification (in the cover letter, your responses,
> +and in the revised commit messages). Aim to make the reviewers say
> +"it is now clear why we may want to do this with the updated version".
> ++
> +Topics that fail to address fundamental design critiques without
> +resolution will not be considered ready for merging.
Nicely explained.
> ++
> It is often beneficial to allow some time for reviewers to provide
> feedback before sending a new version, rather than sending an updated
> series immediately after receiving a review. This helps collect broader
> @@ -323,6 +338,10 @@ The body should provide a meaningful commit message, which:
>
> . alternate solutions considered but discarded, if any.
>
> +. records the resolution of design or viability concerns raised by the
> + community during the review, if any, ensuring the historical record
> + explains why the chosen approach was accepted over alternatives.
> +
Okay.
> [[present-tense]]
>[snip]
^ permalink raw reply
* Re: t5563-simple-http-auth failures with v2.55.0-rc0
From: Todd Zullinger @ 2026-06-18 14:49 UTC (permalink / raw)
To: Matthew John Cheetham; +Cc: git@vger.kernel.org
In-Reply-To: <20260612180203.s2qSgDUs@teonanacatl.net>
Hi,
I wrote:
> Matthew John Cheetham wrote:
>> Thanks for the report. The failure is not in Git, it is a libcurl
>> behaviour change, and there is already an open upstream issue:
>>
>> https://github.com/curl/curl/issues/21943
>> "Negotiate ignored with --anyauth" (Dan Fandrich, 2026-06-10)
>>
>> Dan also bisected it to the same commit I had locally,
>> `8f71d0fde515` ("creds: hold credentials", curl PR #21548).
> [...]
>> Daniel Stenberg has acknowledged the curl issue but has not yet
>> posted a fix. I will follow curl#21943 and, if the upstream answer
>> is "the new behaviour is intended", come back here with a proposal
>> for what Git should do about `http.emptyAuth` and test 18.
>
> Excellent. This is it good hands all around.
[...]
>
> If there is a curl update, I imagine it will be picked up
> reasonably quickly in Fedora (and elsewhere that was testing
> 8.21.0 release candidates) and there will hopefully be no
> strong need to make any changes on the git side.
I saw Fedora picked up curl-8.21.0-rc3 this morning and
confirmed it resolves the git test failures. Someone else
has already commented on the upstream curl issue to note
that.
Thanks,
--
Todd
^ permalink raw reply
* Re: [PATCH v2 7/8] refs: fix recursing `get_main_ref_store()` with "onbranch" config
From: Patrick Steinhardt @ 2026-06-18 14:51 UTC (permalink / raw)
To: Justin Tobler; +Cc: git, Karthik Nayak, Jeff King
In-Reply-To: <ajP7W7KsXz4Wk262@denethor>
On Thu, Jun 18, 2026 at 09:15:00AM -0500, Justin Tobler wrote:
> On 26/06/18 07:59AM, Patrick Steinhardt wrote:
> > On Wed, Jun 17, 2026 at 01:41:40PM -0500, Justin Tobler wrote:
> > > Is this really the best signal to indicate that a repository ref store
> > > has not been initialized? Temporarily setting the storage format to
> > > REF_STORAGE_FORMAT_UNKNOWN feels rather awkward and suggests to me that
> > > `include_by_branch()` probably shouldn't be using it to begin with if
> > > its not reliable.
> >
> > True, but we don't really have a better signal to the best of my
> > knowledge. Ideally, we'd be able to use the existence `r->refs_private`
> > as signal. But that doesn't really work as the reference database is
> > lazily constructed, and the recursion happens in the exact function that
> > would construct it in the first place. And there indeed are cases where
> > reading the configuration is the first caller of `get_main_ref_store()`.
>
> Ok, my first thought was also whether we could use the existence of the
> ref store as a signal, but I guess that won't work here.
>
> > My first internal iteration tried to make this non-lazily constructed so
> > that we can use it as a proper signal. But that led to a bunch of
> > problems where we now parsed configuration way earlier than we currently
> > do, and that in turn led to all kinds of errors. I was able to fix all
> > of those errors except one: we expect `git config set` to work in a
> > misconfigured repository so that the user can fix the misconfig without
> > having to manually edit the Git configuration files. But when
> > constructing the refdb eagerly we will die early in such cases.
> >
> > We could again work around that issue, but that unfortunately evolved
> > into a proper mess that I eventually discarded as unworkable. I think
> > this is an inherent design flaw: constructing the refdb requires us to
> > be able to parse the configuration, but constructing the configuration
> > may require us to construct the refdb. So this awkwardness is built into
> > Git's design, unfortunately.
> >
> > So I'd really love to have a better signal, as I fully agree that the
> > above workaround is nothing more but a hack. But I'm just not sure what
> > that signal would be. And this version here does exactly what we want:
> > we honor "onbranch" conditionals in all cases, except when constructing
> > the main reference store. Even if it's ugly.
>
> Could we embed an `initialized` boolean in `struct ref_store` that gets
> set when the ref store is properly initialized and use that as a signal
> instead? I'm not sure how complex introducing this would be though.
We could, but I'm not sure what that would really buy us. It would
basically be one more bit of state that we have to track going forward,
and thus one more source of inconsistencies.
Patrick
^ permalink raw reply
* Re: t5563-simple-http-auth failures with v2.55.0-rc0
From: Matthew John Cheetham @ 2026-06-18 15:02 UTC (permalink / raw)
To: Todd Zullinger; +Cc: git@vger.kernel.org
In-Reply-To: <20260618144953.l6Ng-dvv@teonanacatl.net>
On 2026-06-18 15:49, Todd Zullinger wrote:
> I saw Fedora picked up curl-8.21.0-rc3 this morning and
> confirmed it resolves the git test failures. Someone else
> has already commented on the upstream curl issue to note
> that.
Thanks for confirming rc3 fixes things!
The CURLOPT_USERPWD = ":" behaviour was never codified in curl's
documentation, but given the fix they've put in place it's probably a
good sign we can continue to rely on this.
I may propose a patch to curl documentation's patch to say that this
behaviour is expected and supported, if the they don't do it themselves
soon already.
Thanks,
Matthew
^ permalink raw reply
* Re: [PATCH] Fix typo in MaintNotes regarding versioning scheme
From: Junio C Hamano @ 2026-06-18 15:08 UTC (permalink / raw)
To: Tuomas Ahola; +Cc: Silas Poulson, gitgitgadget, git
In-Reply-To: <20260618114837.0_RVf%taahol@utu.fi>
Tuomas Ahola <taahol@utu.fi> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>
>> Silas Poulson <silas@dyalog.com> writes:
>>
>> > I'm aware this is a very minor change, but it would be good to not let
>> > this fall through the cracks.
>>
>> Thanks for noticing a typo.
>>
>> Will update before the next issue is sent to the mailing list. No
>> point in changing it before that.
>
> On that occasion, please consider also these fixes:
Thanks. Will squash in. The next issue of Maintotes will come
right after 2.55 final gets tagged, so we have a bit more time.
^ permalink raw reply
* Re: [PATCH v2 0/7] More work supporting objects larger than 4GB on Windows
From: Junio C Hamano @ 2026-06-18 15:08 UTC (permalink / raw)
To: Patrick Steinhardt
Cc: Johannes Schindelin via GitGitGadget, git, Kristofer Karlsson,
Johannes Schindelin
In-Reply-To: <ajPhBn7n1wR-sii4@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> On Mon, Jun 15, 2026 at 11:52:22AM +0000, Johannes Schindelin via GitGitGadget wrote:
>> This patch series tries to address the problems pointed out by the expensive
>> tests that now run in CI: t5608 and t7508 verify various aspects about
>> objects larger than 4GB, which Git does not currently handle correctly when
>> run on a platform where size_t is 64-bit and unsigned long is 32-bit.
>>
>> Changes vs v1:
>>
>> * Rebased onto master, which merged ps/odb-source-loose (with which these
>> patches previously conflicted rather badly).
>> * Removed superfluous size_t s variables (thanks, Patrick!).
>
> I skimmed those parts that I was previously commenting on and am
> happy with those changes. Thanks!
Thanks. I looked at them and found nothing iffy, either.
^ permalink raw reply
* Re: [PATCH] SubmittingPatches: address design critiques
From: Michael Montalbo @ 2026-06-18 15:17 UTC (permalink / raw)
To: Michael Montalbo; +Cc: git, Junio C Hamano
On Wed, Jun 17, 2026 at 8:53 PM Michael Montalbo <mmontalbo@gmail.com> wrote:
>
> Junio C Hamano wrote:
> > +You would want to be particularly mindful of critiques regarding the
> > +high-level design or viability of your proposal (e.g., questioning
> > +whether the feature is worth implementing, or if the chosen approach
> > +is appropriate). You want to defend your design decisions on the list
> > +first, because you do not want to spend too much effort in the
> > +implementation if the design is not yet solid.
>
> Two small suggestions: open with a direct imperative and replace
> "effort in the implementation" with "effort on the implementation".
>
> [B]e particularly mindful of...
> ... too much effort [on] the implementation...
(resending to fix threading)
Maybe we can even more directly say:
Do not spend too much effort on the implementation if the design is not
yet solid. Be able to defend your design decisions on the list first.
^ permalink raw reply
* Re: [PATCH v2] SubmittingPatches: address design critiques
From: Michael Montalbo @ 2026-06-18 15:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <gitster@pobox.com> wrote:
> +You should be particularly mindful of critiques regarding the
> +high-level design or viability of your proposal (e.g., questioning
> +whether the feature is worth implementing, or if the chosen approach
> +is appropriate). Defend your design decisions on the list first, to
> +avoid wasting effort on an implementation whose design is not yet
> +solid.
> ++
> +Make sure that any new version is accompanied by a much clearer
> +explanation and justification (in the cover letter, your responses,
> +and in the revised commit messages). Aim to make the reviewers say
> +"it is now clear why we may want to do this with the updated version".
> ++
> +Topics that fail to address fundamental design critiques without
> +resolution will not be considered ready for merging.
This wording looks good to me.
^ permalink raw reply
* Re: [PATCH] SubmittingPatches: address design critiques
From: Junio C Hamano @ 2026-06-18 15:40 UTC (permalink / raw)
To: Michael Montalbo; +Cc: git
In-Reply-To: <CAC2QwmJdF+YzAQE3WDEaUrurLVkYcAA0Cgs1YAqyxYcQ0jKfqA@mail.gmail.com>
Michael Montalbo <mmontalbo@gmail.com> writes:
> Two small suggestions: open with a direct imperative and replace
> "effort in the implementation" with "effort on the implementation".
>
> [B]e particularly mindful of...
> ... too much effort [on] the implementation...
Yeah, I started from something like that then toned it down, but I
agree that it is more appropriate to be more assertive here.
> Maybe it would help to spell out what the explanation/justification is
> for more explicitly (though it may be a bit redundant with the
> "meaningful message" blurb):
Yeah, and it depends on what kind of higher level issues the
reviewer comment is about, so ...
> Make sure that any new version explains and justifies those
> design decisions more clearly: why the change is worth making,
> what alternatives were considered, and why the chosen approach
> is correct. Put that justification in the cover letter, your
> responses, and the revised commit messages. Aim to make the
> reviewers say "it is now clear why we may want to do this with
> the updated version".
... I find the beginning part of the above very much better than
what I had in my version, but part of the first sentence after the
colon is probably a bit too much.
I'll send out v3 sometime before the next week.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 0/7] Introduce fetch.followRemoteHEAD config variable
From: Junio C Hamano @ 2026-06-18 15:47 UTC (permalink / raw)
To: Matt Hunter; +Cc: git, Bence Ferdinandy, Jeff King
In-Reply-To: <DJBVYP58YNTU.LQ7VXFIQE84H@lfurio.us>
"Matt Hunter" <m@lfurio.us> writes:
>> Other than that, this looks excellent. Thanks.
>
> Thanks for the great feedback and consideration!
>
> If you like, I can apply the appropriate NEEDSWORK comment, possibly add
> a warning to 'fetch.followRemoteHEAD' parsing (matching the 'remote'
> side), and we can call this good to go for now.
Sounds like a plan. Thanks.
^ permalink raw reply
* Re: [PATCH v2 7/8] refs: fix recursing `get_main_ref_store()` with "onbranch" config
From: Justin Tobler @ 2026-06-18 15:53 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Karthik Nayak, Jeff King
In-Reply-To: <ajQF1yyCUOdzC4Jq@pks.im>
On 26/06/18 04:51PM, Patrick Steinhardt wrote:
> On Thu, Jun 18, 2026 at 09:15:00AM -0500, Justin Tobler wrote:
> > Could we embed an `initialized` boolean in `struct ref_store` that gets
> > set when the ref store is properly initialized and use that as a signal
> > instead? I'm not sure how complex introducing this would be though.
>
> We could, but I'm not sure what that would really buy us. It would
> basically be one more bit of state that we have to track going forward,
> and thus one more source of inconsistencies.
My naive thought here is that if the ref store knows when it is
initialized, this could be used as a more reliable signal by
`include_by_branch()`. I guess the problem though would be that, at that
point in time, we are still inside `ref_store_init()` and thus the ref
store is not fully initialized anyways.
I was hoping we could avoid the hack of temporarily setting the ref
format here, but introducing state specific to tracking whether its ok
to parse onbranch conditions in the config is probably not worth it I
guess.
-Justin
^ permalink raw reply
* Re: [PATCH v4] ref-filter: restore prefix-scoped iteration
From: Junio C Hamano @ 2026-06-18 15:54 UTC (permalink / raw)
To: Tamir Duberstein
Cc: git, Karthik Nayak, Patrick Steinhardt, Victoria Dye, ZheNing Hu
In-Reply-To: <20260612-fix-git-branch-regression-v4-1-f150038c02f4@gmail.com>
Tamir Duberstein <tamird@gmail.com> writes:
> Changes in v4:
> - Explain the historical references in the commit message.
> - Run the new performance cases with both ref backends.
> - Drop the Assisted-by trailer.
> - Link to v3: https://patch.msgid.link/20260610-fix-git-branch-regression-v3-1-6fd48fad7a53@gmail.com
This seems to fully address comments by Patrick in
https://lore.kernel.org/git/aivx-7VOKE_TC50R@pks.im/
Let me mark the topic for 'next'. Thanks all who discussed this patch.
^ permalink raw reply
* Re: [PATCH v5 2/2] graph: indent visual root in graph
From: Jeff King @ 2026-06-18 16:05 UTC (permalink / raw)
To: Pablo Sabater
Cc: Kristofer Karlsson, git, ayu.chandekar, chandrapratap3519,
christian.couder, gitster, jltobler, karthik.188, phillip.wood,
siddharthasthana31
In-Reply-To: <CAN5EUNSQY2oK7BE4J9Y8APfkP6eJxta050OUu=RoJYhXOjX_OA@mail.gmail.com>
On Thu, Jun 18, 2026 at 02:42:16PM +0200, Pablo Sabater wrote:
> > > + for (cl = graph->revs->commits; cl; cl = cl->next) {
> > > + if (get_commit_action(graph->revs, cl->item) != commit_show)
> > > + continue;
> [...]
> > I'm not sure what the solution is. This function wants to peek ahead in
> > queue order, possibly through multiple entries. But a heap-based queue
> > inherently only supports peeking at the first entry.
>
> Yeah, I haven't read dd4bc01c0a yet but from what you say it prob
> won't work anymore, I didn't know about that series, about the
> lookahead I think it could still work with some tweaks, the important
> part is to set the three lookahead flags.
Thanks for looking into it. I meant to also cc the Kristofer, the author
of dd4bc01c0a, for any thoughts (adding him now).
> From what I understood, we can only get the direct next commit, but no
> more reliably ordered.
Right. There are other queue implementations that could allow full
in-order traversal (e.g., a binary tree), but our prio_queue does not. I
suspect performance for other cases would suffer if we switched the
underlying data structure.
> The flags should be fine:
>
> - 'is_next_visible' could need to traverse multiple entries, but it
> doesn't need them to be in order. We just need to know if something
> will be rendered after.
Yeah, this one seems easy. We are just setting a bit based on whether
we'd find any commit to show. So order doesn't matter.
> - 'next_has_column' only needs the first entry.
But this was the one I was worried about. Walking the linked list in
order will find us the next commit we're going to show, and the result
of the flag depends on graph_find_new_column_by_commit(). Is it OK to
find _any_ such commit?
(I'm looking at this purely based on reading the existing code, and
haven't really thought hard about the problem space).
> - 'is_next_visual_root' only needs the first entry to know if it could
> be a visual root, and also if it is not the last one (but we don't
> need them to be ordered for this last part).
This one just iterates looking for any other commit we'll show after the
next one. So finding any two entries would be equivalent to the current
code (though we only get to this loop if the first one passes the test
for graph_is_visual_root_candidate).
So if you say order doesn't matter for checking the column and the
visual-root-candidate function, I'm happy to believe you. It makes life
much easier. :)
> Should I work with 'next' as a base to have dd4bc01c0a? (Sorry I've
> just worked with master).
As Junio noted, that's already in master, so I think you're OK to just
base there.
But for future reference, no, you probably don't want to build off of
'next'. If your commit has a dependency on another topic it is best to
build directly off of that topic (and note it in the cover letter of the
series). That way you do not accidentally depend on other things in
'next' which might not ever make it to 'master' (and would thus hold
your topic hostage).
-Peff
^ permalink raw reply
* Re: [PATCH v5 2/2] graph: indent visual root in graph
From: Jeff King @ 2026-06-18 16:07 UTC (permalink / raw)
To: Pablo Sabater
Cc: Kristofer Karlsson, git, ayu.chandekar, chandrapratap3519,
christian.couder, gitster, jltobler, karthik.188, phillip.wood,
siddharthasthana31
In-Reply-To: <20260618160504.GA818042@coredump.intra.peff.net>
On Thu, Jun 18, 2026 at 12:05:05PM -0400, Jeff King wrote:
> > From what I understood, we can only get the direct next commit, but no
> > more reliably ordered.
>
> Right. There are other queue implementations that could allow full
> in-order traversal (e.g., a binary tree), but our prio_queue does not. I
> suspect performance for other cases would suffer if we switched the
> underlying data structure.
BTW, there's one extra trick here in the iteration: you might see
commits in _both_ revs->commits and revs->commit_queue. So you'll have
to iterate over both of them (and I guess push the loop body into a
function to avoid duplication).
We may eventually settle on having just one queue sturcture, but I think
dd4bc01c0a used that to avoid disrupting existing callers.
-Peff
^ permalink raw reply
* Re: [PATCH v14 4/6] branch: add --prune-merged <branch>
From: Junio C Hamano @ 2026-06-18 16:08 UTC (permalink / raw)
To: Phillip Wood
Cc: Harald Nordgren, Harald Nordgren via GitGitGadget, git,
Kristoffer Haugsbakk, Johannes Sixt
In-Reply-To: <37f2a483-c8bf-4c24-84de-c6233cc20b25@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
> One thing I've just thought of related to this patch is whether we want
> to protect branches that are the upstreams of branches that are not
> slated for deletion. With stacked branches it is possible that a branch
> has been merged but has other branches stacked on top of it that have
> not been merged.
An interesting point. We do have "this topic is built on the result
of merging these other topics into main" and I expect the practice
is wide spread. These base topics may graduate first, but other
topics may still be updated.
But when you rewrite these other topics, wouldn't you leave their
bases untouched? IOW, a new iteration (i.e. "rebase -i") would
reuse the base that was used in an earlier iteration, i.e. the
result of an earlier merge of the other topics, some of which might
have been pruned since then, into an older 'main', so it is OK to
lose these other topics once they have graduated, simply because you
wouldn't be recreating the merge that you used as the base of this
remaining topic, no?
Or am I missing something?
Thanks.
^ permalink raw reply
* Re: t5563-simple-http-auth failures with v2.55.0-rc0
From: Junio C Hamano @ 2026-06-18 16:18 UTC (permalink / raw)
To: Todd Zullinger; +Cc: Matthew John Cheetham, git@vger.kernel.org
In-Reply-To: <20260618144953.l6Ng-dvv@teonanacatl.net>
Todd Zullinger <tmz@pobox.com> writes:
> I saw Fedora picked up curl-8.21.0-rc3 this morning and
> confirmed it resolves the git test failures. Someone else
> has already commented on the upstream curl issue to note
> that.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] SubmittingPatches: address design critiques
From: Junio C Hamano @ 2026-06-18 16:26 UTC (permalink / raw)
To: Kristoffer Haugsbakk; +Cc: git
In-Reply-To: <95cd81dc-baea-4318-9f01-6a795f8eb5bb@app.fastmail.com>
"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
> You can imagine someone from group number 1 who is *not* in group number
> 3 use a weekend to implement something. But then when it is submitted it
> turns out that is a very “centralized CVS” idea which doesn’t fit into
> git(1) at all. That’s easily spotted by group number 3 by just looking
> at the proposed docs or design. Now that group number 1 individual might
> just have a bunch of code that is dead weight for any proper Git
> workflow.
That depends on how obviously wrong the idea is. If your proposal
is to write another CVS into Git, that may be too obvious it may not
fly, but the thing is, "proposals" that get the canned response you
quoted are often vague enough that crucial details that divide
"iffy" and "obviously wrong" are missing.
One way to make these proposals sufficiently clear to allow
reviewers to tell the difference is with a code that builds. There
may be other ways, but that is one obvious way to start a meaningful
discussion.
^ 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