Re: On-branch topic description support?

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jul 21, 2022, 18:58 UTC
Message-ID: <220721.861quethn4.gmgdl@evledraar.gmail.com>
In-Reply-To: <20220721182645.45xrwf2buohibcaw@meerkat.local>

On Thu, Jul 21 2022, Konstantin Ryabitsev wrote:

Show 15 quoted lines

> On Thu, Jul 21, 2022 at 11:02:26AM -0700, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> 
>> > But this is worse in that "git rebase" will get rid of it by default.
>> 
>> FWIW, I think I like this much better than Konstantin's "there is an
>> empty commit at the bottom", for exactly the same reason why I like
>> the original "empty commit at the tip", i.e. simply because we can
>> strip away the "extra" commit that holds the topic description
>> without having to change all the "real" commits.
>
> I'm happy to consider alternatives if I can have a reliable way of tracking
> "the series we're working on starts at this commit". I know that this is
> antithetical to git's design, but I also can't think of anything else that
> reliably survives rebases.

Aside from any discussion of how such a "cover letter" thingy gets represented in the DAG, I wonder if rebase should be less aggressive about wiping away merge commits in general.

It's really handy to e.g. fix something where you've got repeated merges of the "master" into your branch.

But if you've got some novel merge structure that's existing purely within your branch perhaps we should at least show some advice() before proceeding, or suggest --rebase-merges...

I haven't thought through all the edge cases with that, just food for thought.