From: Junio C Hamano <gitster@pobox.com>
To: Harald Nordgren <haraldnordgren@gmail.com>
Cc: Harald Nordgren via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Ramsay Jones <ramsay@ramsayjones.plus.com>,
"D. Ben Knoble" <ben.knoble@gmail.com>,
Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>,
Marc Branchaud <marcnarc@gmail.com>,
Phillip Wood <phillip.wood123@gmail.com>
Subject: Re: [PATCH v13 0/2] checkout: --track=fetch
Date: Wed, 17 Jun 2026 19:50:53 -0700 [thread overview]
Message-ID: <xmqqtsr0tvci.fsf@gitster.g> (raw)
In-Reply-To: <CAHwyqnXLceLXzRrW_7TB8JM+Ur92gw5QkYeKjzOGbWX+f_yLjw@mail.gmail.com> (Harald Nordgren's message of "Thu, 18 Jun 2026 00:10:36 +0200")
Harald Nordgren <haraldnordgren@gmail.com> writes:
> But can I offer some (unsolicited) feedback on this review process in
> particular? Given that it seems unlikely to hit 'master' at this
> point, I want to say that it's the wrong order of things to dig into
> code specific feedback, before deciding if we even want the feature at
> all. We are wasting each other's time. I have pushed on despite
> initial negative feedback, that's on me. But I also cannot lay flat, I
> like the idea so I keep pushing. Now we have v13, maybe soon v14, of a
> topic that has slim chances of passing.
>
> I would have been much happier if you shut this topic down directly.
>
> Imagine all the review time spent on this that could have been better
> spent elsewhere.
You are forgetting that there are two things a topic author can and
should do: addressing higher-level design issues (e.g., Counter "is
it a good idea to begin with?" with "it is, because in this context
you haven't thought about, it would make the user experience
better", to help reviewers understand and hopefully agree with your
viewpoint) and addressing mechanical implementation issues (e.g.,
Respond to "it is wasteful and adds maintenance burden to dupplicate
the logic here and there" with "Here is an updated implementation
based on better refactoring"). The latter is easier in a sense,
especially when the reviewers say something like "I am not sure if
this is a good idea to begin with, but assuming it is, here are the
things I find in your implementation". But the former needs to be
addressed eventually before the topic can gain wider support
(remember, it does not have to be sold to _me_ 100% and make me say
"oh, I cannot believe Git did not have this feature for 20 years!";
you only need to convince me that it is OK to have it as an opt-in
feature, that is a lot lower bar to cross. In addition, I do not
have to agree with it at all, as long as others whose judgement I
trust well enough support the feature).
prev parent reply other threads:[~2026-06-18 2:50 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-24 10:03 [PATCH] checkout: add --fetch to fetch remote before resolving start-point Harald Nordgren via GitGitGadget
2026-04-24 13:48 ` Ramsay Jones
2026-04-24 17:12 ` D. Ben Knoble
2026-04-25 17:24 ` Comments on Phillip's review Harald Nordgren
2026-04-25 17:44 ` Wrong subject line Harald Nordgren
2026-04-24 17:38 ` [PATCH] checkout: add --fetch to fetch remote before resolving start-point Kristoffer Haugsbakk
2026-04-25 17:41 ` Comments on Phillip's review Harald Nordgren
2026-04-25 17:44 ` Wrong subject line Harald Nordgren
2026-04-26 7:07 ` Kristoffer Haugsbakk
2026-04-26 15:15 ` [PATCH] remote: add --set-head option to 'git remote add' Harald Nordgren
2026-04-24 17:42 ` [PATCH] checkout: add --fetch to fetch remote before resolving start-point Marc Branchaud
2026-04-25 17:48 ` Wrong subject line Harald Nordgren
2026-04-24 22:21 ` [PATCH] checkout: add --fetch to fetch remote before resolving start-point Junio C Hamano
2026-04-25 2:54 ` Junio C Hamano
2026-04-25 17:58 ` Multiple remotes Harald Nordgren
2026-04-25 21:57 ` Ben Knoble
2026-04-25 22:54 ` gh Harald Nordgren
2026-04-25 18:12 ` [PATCH v2] checkout: add --fetch to fetch remote before resolving start-point Harald Nordgren via GitGitGadget
2026-04-26 7:24 ` [PATCH v3] " Harald Nordgren via GitGitGadget
2026-04-26 15:54 ` Ramsay Jones
2026-04-26 18:32 ` [PATCH v4] " Harald Nordgren via GitGitGadget
2026-04-28 1:47 ` Junio C Hamano
2026-04-28 8:44 ` [PATCH] " Harald Nordgren
2026-04-28 9:03 ` [PATCH v5] checkout: extend --track with a "fetch" mode to refresh start-point Harald Nordgren via GitGitGadget
2026-05-03 20:59 ` Junio C Hamano
2026-05-03 22:32 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-05-03 22:31 ` [PATCH v6] checkout: extend --track with a "fetch" mode to refresh start-point Harald Nordgren via GitGitGadget
2026-05-07 20:12 ` Harald Nordgren
2026-05-08 13:15 ` Phillip Wood
2026-05-08 22:40 ` [PATCH] checkout: add --fetch to fetch remote before resolving start-point Harald Nordgren
2026-05-08 22:52 ` [PATCH v7] checkout: extend --track with a "fetch" mode to refresh start-point Harald Nordgren via GitGitGadget
2026-05-11 13:16 ` Phillip Wood
2026-05-11 13:47 ` [PATCH v8] " Harald Nordgren via GitGitGadget
2026-05-12 0:32 ` Junio C Hamano
2026-05-18 8:06 ` Harald Nordgren
2026-05-12 10:55 ` [PATCH v9] " Harald Nordgren via GitGitGadget
2026-05-18 8:04 ` [PATCH v10] " Harald Nordgren via GitGitGadget
2026-05-19 6:16 ` Junio C Hamano
2026-05-19 7:52 ` Harald Nordgren
2026-05-19 8:16 ` Junio C Hamano
2026-05-19 8:32 ` Harald Nordgren
2026-05-19 8:38 ` Harald Nordgren
2026-05-19 7:58 ` [PATCH v11] " Harald Nordgren via GitGitGadget
2026-05-19 10:34 ` Junio C Hamano
2026-05-21 9:49 ` Phillip Wood
2026-05-21 10:24 ` Harald Nordgren
2026-05-21 12:58 ` Junio C Hamano
2026-05-21 14:06 ` Phillip Wood
2026-05-21 23:53 ` Junio C Hamano
2026-06-13 17:38 ` Harald Nordgren
2026-05-21 10:20 ` [PATCH v12] " Harald Nordgren via GitGitGadget
2026-05-23 19:48 ` [PATCH v13 0/2] checkout: --track=fetch Harald Nordgren via GitGitGadget
2026-05-23 19:48 ` [PATCH v13 1/2] branch: expose helpers for finding the remote owning a tracking ref Harald Nordgren via GitGitGadget
2026-05-23 19:48 ` [PATCH v13 2/2] checkout: extend --track with a "fetch" mode to refresh start-point Harald Nordgren via GitGitGadget
2026-06-17 19:15 ` [PATCH v13 0/2] checkout: --track=fetch Junio C Hamano
2026-06-17 22:10 ` Harald Nordgren
2026-06-18 2:50 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqtsr0tvci.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ben.knoble@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=haraldnordgren@gmail.com \
--cc=kristofferhaugsbakk@fastmail.com \
--cc=marcnarc@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=ramsay@ramsayjones.plus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.