From: Junio C Hamano <gitster@pobox.com>
To: "SZEDER Gábor" <szeder.dev@gmail.com>
Cc: Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH] completion: restore removed line continuating backslash
Date: Tue, 14 Feb 2017 18:41:22 -0800 [thread overview]
Message-ID: <xmqqtw7w41m5.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAM0VKjmU57saSfyRuoWfC+UZFNypH1Wp9X33VgzPq9fatD=qtg@mail.gmail.com> ("SZEDER Gábor"'s message of "Wed, 15 Feb 2017 02:35:28 +0100")
SZEDER Gábor <szeder.dev@gmail.com> writes:
>> If you feel uncomfortable and want these to cook longer, please tell
>> me so.
>
> Well, it was mainly my surprise that a 20+ patch series arriving so
> late that it gets queued on top of -rc0 would still make it into the
> release.
It all depends on what area the changes are about ;-)
Not meaning to make light of your contribution, but if the upcoming
version of Git shipped with a slightly broken completion, and the
breakage is severe enough, the only thing we need to do is to do a
maintenance release that reverts a single script. Distro packagers
may do that for us. While waiting, the user can choose not to load
the completion and can keep using Git just fine. A broken
"mergetool" would be similar in that a workaround to inspect "git
diff" is available. If we break "pull" or "commit" on the other
hand, the necessary workaround would be a lot more involved.
Some changes in low-impact areas can wait without reducing the
end-user value of the new release, but if the risk of regression is
small, I favour merging them, rather than postponing them for one
cycle, if only to reduce the number of patches that I need to hold
onto. Patches to clarify existing documentation fall into this
category.
My perception of "risk of regression" obviously is affected by the
size of the series, and 20+ is certainly on the larger side. But
other things also come into the picture. Patches from an author who
knows the area the patches touch very well and with track record of
not causing embarrassing regressions, would make me feel safer than
patches from others, for example.
next prev parent reply other threads:[~2017-02-15 2:41 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-03 2:48 [PATCHv2 00/21] completion: various __gitdir()-related improvements SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 01/21] completion: improve __git_refs()'s in-code documentation SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 02/21] completion tests: don't add test cruft to the test repository SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 03/21] completion tests: make the $cur variable local to the test helper functions SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 04/21] completion tests: consolidate getting path of current working directory SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 05/21] completion tests: check __gitdir()'s output in the error cases SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 06/21] completion tests: add tests for the __git_refs() helper function SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 07/21] completion: ensure that the repository path given on the command line exists SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 08/21] completion: fix most spots not respecting 'git --git-dir=<path>' SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 09/21] completion: respect 'git --git-dir=<path>' when listing remote refs SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 10/21] completion: list refs from remote when remote's name matches a directory SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 11/21] completion: don't list 'HEAD' when trying refs completion outside of a repo SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 12/21] completion: list short refs from a remote given as a URL SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 13/21] completion: don't offer commands when 'git --opt' needs an argument SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 14/21] completion: fix completion after 'git -C <path>' SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 15/21] rev-parse: add '--absolute-git-dir' option SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 16/21] completion: respect 'git -C <path>' SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 17/21] completion: don't use __gitdir() for git commands SZEDER Gábor
2017-02-13 19:20 ` [PATCH] completion: restore removed line continuating backslash SZEDER Gábor
2017-02-13 20:45 ` Junio C Hamano
2017-02-15 1:35 ` SZEDER Gábor
2017-02-15 2:41 ` Junio C Hamano [this message]
2017-02-15 13:06 ` SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 18/21] completion: consolidate silencing errors from git commands SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 19/21] completion: don't guard git executions with __gitdir() SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 20/21] completion: extract repository discovery from __gitdir() SZEDER Gábor
2017-02-03 2:48 ` [PATCHv2 21/21] completion: cache the path to the repository SZEDER Gábor
2017-02-06 21:29 ` [PATCHv2 00/21] completion: various __gitdir()-related improvements Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqtw7w41m5.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=szeder.dev@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.
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.