tools.linux.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Linus Torvalds <torvalds@linuxfoundation.org>
Cc: Junio C Hamano <junio@pobox.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	users@kernel.org, tools@linux.kernel.org
Subject: Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
Date: Tue, 14 Oct 2025 05:39:00 +0200	[thread overview]
Message-ID: <20251014033900.GA3126@1wt.eu> (raw)
In-Reply-To: <CAHk-=wh--VXgwQ3s8DLeag6cegsD9cPcvkmbVft0Gesy2aGPsA@mail.gmail.com>

On Mon, Oct 13, 2025 at 02:44:28PM -0700, Linus Torvalds wrote:
> So rather than doing a separate branch, rebasing things there, and
> going back and rebasing away the things in my original branch, doing
> just 'git rebase -i" in the original branch and having some way to say
> "this is the start of this series", and a "this is the end of the
> series", and having git rebase create a set of linear series with
> merges that delineate them might be quite convenient.

FWIW I'm using "git rebase -i" a lot, that's probably the command that
really makes git magical from the developer's perspective. While I know
it's possible to keep empty commits, it"s usually not welcome because
the purpose of rebases is to be able to rework a series by moving things
around and eliminate those that have been nicely integrated.

Thus I think that what would really be nice (and that I've been missing
many times) is a type of commit that git recognizes as a delimiter, i.e.
it doesn't contain data, but *something* (maybe a dummy diff on /dev/null
vs itself?) allows git rebase and git am to say "OK that's not the regular
empty commit, it's one I have to keep anyway". Then one specific option
of git am or git rebase could be used to turn that commit into a merge
one.

This would allow to keep the history linear the for the longest possible
time with cover patches at the end (or maybe the beginning, like 0/X),
it would ease running git am on a patch series starting at zero, and
would let the merge commit be created at the final point, maybe even
just on the side of the final recipient (you in your case).

> I say that without having actually tried it, but from a "I think I
> would have found that useful in several situations" kind of way.

I'm one of those. On projects moving slower than the kernel, it's easy
to avoid merge commits and keep the history linear for easier backports,
but clearly series delimiters are missing.

Thanks,
Willy

  parent reply	other threads:[~2025-10-14  3:39 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-11  5:59 In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers) Paolo Bonzini
2025-10-11  6:13 ` Willy Tarreau
2025-10-11  6:33   ` Paolo Bonzini
2025-10-15  8:56     ` Geert Uytterhoeven
2025-10-11  6:39   ` Jiri Slaby
2025-10-11 10:33   ` Mark Brown
2025-10-12 23:27     ` Jason Gunthorpe
2025-10-13  8:18       ` Vlastimil Babka (SUSE)
2025-10-13  8:27         ` Paolo Bonzini
2025-10-13  8:42           ` Willy Tarreau
2025-10-13  8:48             ` Jiri Slaby
2025-10-13  8:56               ` Willy Tarreau
2025-10-13 11:21                 ` Laurent Pinchart
2025-10-13 14:26                   ` [workflows]Re: " Steven Rostedt
2025-10-13 14:39                     ` Laurent Pinchart
2025-10-13 14:59                       ` Steven Rostedt
2025-10-13 15:04                         ` Laurent Pinchart
2025-10-13 15:44                           ` Steven Rostedt
2025-10-13 11:03           ` Mark Brown
2025-10-13 11:49             ` James Bottomley
2025-10-13 12:15               ` Mark Brown
2025-10-13 12:29               ` Paolo Bonzini
2025-10-13 12:47                 ` James Bottomley
2025-10-13 13:02                   ` Jürgen Groß
2025-10-15 18:05                   ` Jeff Johnson
2025-10-16 16:47     ` Linus Torvalds
2025-10-13 12:21 ` Michael S. Tsirkin
2025-10-13 17:00   ` Linus Torvalds
2025-10-13 18:14     ` Paolo Bonzini
2025-10-13 18:53       ` Linus Torvalds
2025-10-13 20:12         ` Junio C Hamano
2025-10-13 21:44           ` Linus Torvalds
2025-10-13 23:22             ` Sasha Levin
2025-10-14  1:29               ` Linus Torvalds
2025-10-14  3:39             ` Willy Tarreau [this message]
2025-10-16 14:52               ` Geert Uytterhoeven
2025-10-16 15:08                 ` Jason Gunthorpe
2025-10-16 15:33                   ` Geert Uytterhoeven
2025-10-13 22:31         ` Paolo Bonzini
2025-10-14  6:47           ` Jiri Slaby
2025-10-13 21:59     ` Theodore Ts'o
2025-10-13 23:09     ` Michael S. Tsirkin
2025-10-14  1:23       ` Linus Torvalds
2025-10-14 10:38         ` Michael S. Tsirkin
2025-10-14 16:56           ` Linus Torvalds
2025-10-14 18:05             ` Luck, Tony
2025-10-14 18:41               ` Linus Torvalds
2025-10-14 19:09                 ` Paolo Bonzini
2025-10-14 21:10                 ` Jason Gunthorpe
2025-10-15  7:37                 ` Geert Uytterhoeven
2025-10-15  7:33     ` Geert Uytterhoeven
2025-10-15  9:38       ` Miguel Ojeda
2025-10-15 12:11         ` Mark Brown
2025-10-15 13:50           ` James Bottomley
2025-10-15 13:59             ` Jürgen Groß
2025-10-15 15:08             ` Mark Brown
2025-10-15 15:14             ` Peter Zijlstra
2025-10-15 15:18               ` [workflows]Re: " Steven Rostedt
2025-10-15 15:53                 ` Peter Zijlstra
2025-10-15 15:59                   ` Steven Rostedt
2025-10-15 16:06                     ` Peter Zijlstra
2025-10-15 16:15                       ` Steven Rostedt
2025-10-15 16:43                         ` Mark Brown
2025-10-15 16:15                       ` Vlastimil Babka (SUSE)
2025-10-15 16:44                         ` Steven Rostedt
2025-10-15 16:58                           ` Konstantin Ryabitsev
2025-10-16  9:28                             ` Matthieu Baerts
2025-10-15 17:01                           ` Miguel Ojeda
2025-10-15 18:40                       ` Laurent Pinchart
2025-10-16  7:32                         ` Peter Zijlstra
2025-10-16  8:20                           ` Vlastimil Babka (SUSE)
2025-10-16 13:58                             ` Steven Rostedt
2025-10-15 14:37           ` Miguel Ojeda
2025-10-15 14:50         ` [workflows]Re: " Steven Rostedt
2025-10-15 13:51       ` Martin K. Petersen
2025-10-15 14:16         ` Konstantin Ryabitsev
2025-10-15 14:42           ` Miguel Ojeda
2025-10-15 15:03             ` Jason Gunthorpe
2025-10-15 14:55           ` [workflows]Re: " Steven Rostedt
2025-10-15 17:34           ` Martin K. Petersen
2025-10-15 14:51         ` Geert Uytterhoeven

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=20251014033900.GA3126@1wt.eu \
    --to=w@1wt.eu \
    --cc=junio@pobox.com \
    --cc=konstantin@linuxfoundation.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=tools@linux.kernel.org \
    --cc=torvalds@linuxfoundation.org \
    --cc=users@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).