From: Junio C Hamano <gitster@pobox.com>
To: Philip Oakley <philipoakley@iee.email>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Oct 2022, #06; Wed, 19)
Date: Thu, 20 Oct 2022 08:35:38 -0700 [thread overview]
Message-ID: <xmqqr0z2mrsl.fsf@gitster.g> (raw)
In-Reply-To: <e70b19de-d990-9844-6a0c-994ceabd9102@iee.email> (Philip Oakley's message of "Thu, 20 Oct 2022 12:57:45 +0100")
Philip Oakley <philipoakley@iee.email> writes:
> On 20/10/2022 02:34, Junio C Hamano wrote:
>> * po/glossary-around-traversal (2022-07-09) 3 commits
>> - glossary: add reachability bitmap description
>> - glossary: add commit graph description
>> - glossary: add Object DataBase (ODB) abbreviation
>>
>> The glossary entries for "commit-graph file" and "reachability
>> bitmap" have been added.
>>
>> Expecting a reroll.
>> cf. <dfe0c1ab-33f8-f13e-71ce-1829bb0d2d7f@iee.email>
>> source: <pull.1282.git.1657385781.gitgitgadget@gmail.com>
>>
> Hi Junio
>
> I'm close to re-submitting.
> Would you want the V2 to be rebased onto v2.38.1, or stay where it was
> dc8c8deaa6 (Prepare for 2.36.2, 2022-06-07).
> It's a clean merge so far.
Thanks.
I usually would prefer to see the topic not rebased, especially if a
rerolled topic still merges cleanly, and especially when the
original base chosen was an older maintenance track, not a commit
near the then-current tip of 'master'. Being queued on top of
then-current 'maint' (or older) is an indication that the topic can
be taken as "fixes" to the older maintenance release(s). I'd hate
to see something that used to be merge-able down to fix issues in
older maintenance tracks suddenly become limited only to future
releases [*]. It also makes it simpler to run "range-diff @{1}..."
and "diff @{1}" (it is essential for the latter to have the same
base) for sanity-checking the result of accepting a new round.
When the original base was not any of the maintenance tracks but was
near the tip of then-current 'master', I still prefer to see the
base kept unless there is a compelling reason to rebase. There is
one exception to this, though. When the original is so old, its
base can now be a descendant of some maintenance track, even if it
was near the tip of then-current 'master' when the topic was queued.
Such a topic is unlikely to be a "fix" and the value to keep it
merge-able to older maintenance tracks is much lower. So for such a
topic, I think a clean reroll on top of the last stable release
would be OK, and may even be preferable.
[Footnote]
* It is a different matter if I actually merge them down to future
maintenance releases, but for some distros that care to support
older maintenance tracks, being able to merge those topics that
are marked as "(merge X later to maint)" in the RelNotes would
make their life easier than having to cherry-pick them.
next prev parent reply other threads:[~2022-10-20 15:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-20 1:34 What's cooking in git.git (Oct 2022, #06; Wed, 19) Junio C Hamano
2022-10-20 11:57 ` Philip Oakley
2022-10-20 15:35 ` Junio C Hamano [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-10-20 1:31 Junio C Hamano
2022-10-20 6:18 ` Jeff King
2022-10-20 15:38 ` Junio C Hamano
2022-10-21 1:16 ` Michael McClimon
2022-10-21 4:55 ` Jeff King
2022-10-21 19:45 ` Glen Choo
2022-10-22 22:11 ` Jeff King
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=xmqqr0z2mrsl.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=philipoakley@iee.email \
/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).