Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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. In fact, I thought one of the newer "b4" subcommands that is used to accept a patch series with a cover letter creates exactly this sort of topology, when told to apply the topic to the tip of the integration branch? I do prefer to see a tool that it can use the same "format" of data for both input and output, and I think your "there is a redundant merge commit at the tip, with topic description" topology can be that input format, which would be recreated at the receiving end if the receiver happens to have the same base when applying it and the final integration branch was also at the same base.
