mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: "SZEDER Gábor" <>
Subject: Re: What's cooking in git.git (Apr 2018, #04; Mon, 30)
Date: Wed, 02 May 2018 10:36:30 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> ("SZEDER =?utf-8?Q?G=C3=A1bor=22's?= message of "Mon, 30 Apr 2018 15:33:55 +0000")

SZEDER Gábor <> writes:

> On Mon, Apr 30, 2018 at 5:25 AM, Junio C Hamano <> wrote:
>> * js/rebase-i-clean-msg-after-fixup-continue (2018-04-30) 4 commits
>>   - rebase --skip: clean up commit message after a failed fixup/squash
>>   - sequencer: always commit without editing when asked for
>>   - rebase -i: Handle "combination of <n> commits" with GETTEXT_POISON
>>   - rebase -i: demonstrate bugs with fixup!/squash! commit messages
>>   "git rebase -i" sometimes left intermediate "# This is a
>>   combination of N commits" message meant for the human consumption
>>   inside an editor in the final result in certain corner cases, which
>>   has been fixed.
>>   Will merge to 'next'.
> This topic branches off from v2.16.3.  However, its last patch uses
> the sequencer's parse_head() function, which was only added in
> v2.17.0-rc0~110^2~6 (sequencer: try to commit without forking 'git
> commit', 2017-11-24), in topic 'pw/sequencer-in-process-commit',
> leading to compilation errors.

For a low-impact and ralatively old issue like this, it is OK for a
fix to use supporting code that only exists in more recent codebase
and become unmergeable to anything older than the concurrent 'maint'
track as of the time when the fix is written.  Even though it is
sometimes nicer if the fix were written to be mergeable to codebase
near the point where the issue originates, it is often not worth
doing so if it requires bending backwards to refrain from using a
newer and more convenient facility.

Thanks for catching my wishful thinking and carelessness before it
propagated to 'next'.  I try to check tips of individual topic
branches and also the integratoin result, but sometimes I get
trusting too much and get sloppy when dealing with too many topics
in flight.

  parent reply	other threads:[~2018-05-02  1:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-30  3:25 What's cooking in git.git (Apr 2018, #04; Mon, 30) Junio C Hamano
2018-04-30 15:33 ` SZEDER Gábor
2018-05-01 13:46   ` Johannes Schindelin
2018-05-02  3:59     ` Junio C Hamano
2018-05-02  6:53       ` Johannes Schindelin
2018-05-02 10:46         ` Junio C Hamano
2018-05-02  1:36   ` Junio C Hamano [this message]
2018-04-30 19:17 ` js/no-pager-shorthand [was: What's cooking in git.git (Apr 2018, #04; Mon, 30)] Johannes Sixt
2018-05-01 11:57   ` Johannes Schindelin
2018-05-01 14:58     ` Johannes Sixt
2018-05-01 18:10       ` Eric Sunshine
2018-05-02  1:43         ` js/no-pager-shorthand [ Junio C Hamano
2018-05-01 18:46     ` js/no-pager-shorthand [was: What's cooking in git.git (Apr 2018, #04; Mon, 30)] Ævar Arnfjörð Bjarmason
2018-05-02 23:17 ` What's cooking in git.git (Apr 2018, #04; Mon, 30) Brandon Williams
2018-05-04 18:04 ` Elijah Newren
2018-05-07  4:39   ` 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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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

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).