git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: Re: On-branch topic description support?
Date: Thu, 21 Jul 2022 08:05:39 -0700	[thread overview]
Message-ID: <xmqq35eumrp8.fsf@gitster.g> (raw)
In-Reply-To: <xmqqilnr1hff.fsf@gitster.g> (Junio C. Hamano's message of "Wed, 20 Jul 2022 16:40:52 -0700")

Junio C Hamano <gitster@pobox.com> writes:

>  * "git merge" would learn an option to recognize that the branch
>    being merged has such an empty commit at the tip, and instead
>    merge the parent of the tip of the branch into the integration
>    branch, while using the log message of the discarded tip commit
>    in the log message of the merge itself.

An issue that needs to be worked out at the Porcelain level is that
this layout will make "git branch --[no-]merged master", which is an
effective way to list what's in and what's left out of the 'master'
integration branch, more or less useless.  A topic branch with the
cover letter commit at the tip may want to be merged to 'next' and
then after cooking for a while merged down to 'master', and each
time it gets merged, the merge has to leave the cover letter commit
alone.  In spirit, such a merge commit merges the topic "fully", but
at the topological level, the topic is not (and will never be)
merged fully, and "git branch --merged next" will not show.

I guess once the topic hits the oldest integration track that it
meant to go, we could "pop" the cover letter commit out of the
topic, and at that point it would appear to have been merged to
'master' as well as to 'next'.  But it would be nice if we did not
have to discard the cover letter commit only to please "git branch".
IOW, it would be helpful to teach "git branch --[no-]merged" to
compute the "right thing" in such a layout.

  parent reply	other threads:[~2022-07-21 15:05 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-20 23:40 On-branch topic description support? Junio C Hamano
2022-07-21  0:52 ` Shaoxuan Yuan
2022-07-21  5:25 ` Elijah Newren
2022-07-21  6:11   ` Junio C Hamano
2022-07-21 14:41   ` Konstantin Ryabitsev
2022-07-21 16:06   ` Philip Oakley
2022-07-21 17:29     ` Junio C Hamano
2022-07-21 14:53 ` Ævar Arnfjörð Bjarmason
2022-07-21 16:26   ` Konstantin Ryabitsev
2022-07-21 17:35     ` Junio C Hamano
2022-07-21 17:51       ` Ævar Arnfjörð Bjarmason
2022-07-21 17:16   ` Junio C Hamano
2022-07-21 17:49     ` Ævar Arnfjörð Bjarmason
2022-07-21 18:02       ` Junio C Hamano
2022-07-21 18:26         ` Konstantin Ryabitsev
2022-07-21 18:58           ` Ævar Arnfjörð Bjarmason
2022-07-21 19:13           ` Konstantin Ryabitsev
2022-07-21 20:01             ` Junio C Hamano
2022-07-21 20:19               ` Konstantin Ryabitsev
2022-07-21 20:48                 ` Junio C Hamano
2022-07-21 15:05 ` Junio C Hamano [this message]
2022-07-21 15:29   ` rsbecker
2022-07-21 15:39     ` Konstantin Ryabitsev
2022-07-21 15:57       ` rsbecker
2022-07-22  3:15 ` Bagas Sanjaya

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=xmqq35eumrp8.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    /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 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 NNTP newsgroup(s).