From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH 0/2] stash: handle pathspec magic again
Date: Mon, 18 Mar 2019 13:39:34 +0900 [thread overview]
Message-ID: <xmqq8sxc6bjt.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1903111714430.41@tvgsbejvaqbjf.bet> (Johannes Schindelin's message of "Mon, 11 Mar 2019 17:25:26 +0100 (STD)")
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> To appease you enough that you stop complaining about the current, or
> previous, state of `ps/stash-in-c`.
> ...
First of all, you do not have to appease me. What happened in the
past has happened already, and whether I complain or not, the fact
that the history we came up with before pushing the topic to 'next'
was suboptimal. Nothing short of kicking it out of 'next' and
redoing as if it were a fresh topic would fix that, but we all
agreed that it is not the best way to spend our developer and
reviewer resources.
> Fine. But in that case, I would appreciate not being reminded of the
> messiness. Not unless you let me do something about it. Don't put me
> between a rock and a hard place, please.
You had been given plenty of chance to do something about it after
you added "oh, it was wrong not to have a legacy fallback, and here
is a patch on the top". This is not the time to revisit the issue.
Gagging me won't change the fact that the history we ended up is
messy. Without getting reminded of our past mistake(s) ourselves,
what else encourages us to do better the next time?
The lesson I personally learned is that yielding to the wish to
hastily push things that are not ready to 'next' will leave us mess.
I hope the lesson submitters and mentors have learned is not that by
bombarding reviewers with too many iterations that do not address an
issue, a topic can be pushed through with the issue unresolved with
reviewer fatigue.
next prev parent reply other threads:[~2019-03-18 4:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-07 15:29 [PATCH 0/2] stash: handle pathspec magic again Johannes Schindelin via GitGitGadget
2019-03-07 15:29 ` [PATCH 1/2] legacy stash: fix "rudimentary backport of -q" Johannes Schindelin via GitGitGadget
2019-03-11 7:27 ` Junio C Hamano
2019-03-07 15:29 ` [PATCH 2/2] built-in stash: handle :(glob) pathspecs again Johannes Schindelin via GitGitGadget
2019-03-11 7:28 ` Junio C Hamano
2019-03-11 16:27 ` Johannes Schindelin
2019-03-11 22:19 ` Thomas Gummerer
2019-03-08 1:37 ` [PATCH 0/2] stash: handle pathspec magic again Junio C Hamano
2019-03-08 16:12 ` Johannes Schindelin
2019-03-10 0:56 ` Junio C Hamano
2019-03-11 16:25 ` Johannes Schindelin
2019-03-18 4:39 ` Junio C Hamano [this message]
2019-03-18 7:02 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq8sxc6bjt.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).