From: <rsbecker@nexbridge.com>
To: "'Konstantin Ryabitsev'" <konstantin@linuxfoundation.org>
Cc: "'Junio C Hamano'" <gitster@pobox.com>, <git@vger.kernel.org>
Subject: RE: On-branch topic description support?
Date: Thu, 21 Jul 2022 11:57:11 -0400 [thread overview]
Message-ID: <010301d89d1a$8cdc54b0$a694fe10$@nexbridge.com> (raw)
In-Reply-To: <20220721153955.lnfqfilri24i2yw6@meerkat.local>
On July 21, 2022 11:40 AM, Konstantin Ryabitsev wrote:
>On Thu, Jul 21, 2022 at 11:29:20AM -0400, rsbecker@nexbridge.com wrote:
>> I might be missing something here, but could not a description follow
>> similar semantics to how git describe works on tags? Anchor the
>> description on the commit where the branch was spawned, then determine
>> the appropriate description based on things like --first-parent.
>> Again, I'm probably in the weeds.
>
>I think the trouble is that "commit where the branch was spawned" is not reliable
>due to:
>
>- rebasing the work on a different branch
>- reordering commits (including the first commit in the series)
>
>This is the main reason why I actually want to stick the empty commit with the
>cover letter not at the tip of the branch, but at the start of the series, so as to
>clearly demarcate where the series of commits we're interested in starts (at least
>while the author is working on them -- when it sent off upstream that commit can
>get removed/moved).
That process may be more suitable outside the git team where merge --squash is commonplace and the whole series goes into next, main, maint as a single commit as the empty commit will simply vanish. Although, with that said, for the git team's committer process, having a starting point commit in the history also has some obvious advantages, for example, starting and ending points in history for git bisect when things go terribly wrong.
--R
next prev parent reply other threads:[~2022-07-21 15:57 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
2022-07-21 15:29 ` rsbecker
2022-07-21 15:39 ` Konstantin Ryabitsev
2022-07-21 15:57 ` rsbecker [this message]
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='010301d89d1a$8cdc54b0$a694fe10$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=konstantin@linuxfoundation.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 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.