[libvirt] [PATCH rust] git: add config file telling git-publish how to send patches

The "git-publish" tool is a useful git extension for sending patch series for code review. It automatically creates versioned tags each time code on a branch is sent, so that there is a record of each version. It also remembers the cover letter so it does not need re-entering each time the series is reposted. With this config file present it is now sufficient[1] to run $ git publish to send all patches in a branch to the list for review, with the correct subject prefix added for this non-core libvirt module. [1] Assuming your $HOME/.gitconfig has an SMTP server listed at least e.g. [sendemail] smtpserver = smtp.example.com Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- .gitpublish | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 .gitpublish diff --git a/.gitpublish b/.gitpublish new file mode 100644 index 0000000..a86d7a7 --- /dev/null +++ b/.gitpublish @@ -0,0 +1,4 @@ +[gitpublishprofile "default"] +base = master +to = libvir-list@redhat.com +prefix = PATCH rust -- 2.14.3

On Mon, Apr 23, 2018 at 01:54:32PM +0100, Daniel P. Berrangé wrote:
The "git-publish" tool is a useful git extension for sending patch series for code review. It automatically creates versioned tags each time code on a branch is sent, so that there is a record of each version. It also remembers the cover letter so it does not need re-entering each time the series is reposted.
With this config file present it is now sufficient[1] to run
$ git publish
to send all patches in a branch to the list for review, with the correct subject prefix added for this non-core libvirt module.
[1] Assuming your $HOME/.gitconfig has an SMTP server listed at least e.g.
[sendemail] smtpserver = smtp.example.com
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- .gitpublish | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 .gitpublish
diff --git a/.gitpublish b/.gitpublish new file mode 100644 index 0000000..a86d7a7 --- /dev/null +++ b/.gitpublish @@ -0,0 +1,4 @@ +[gitpublishprofile "default"] +base = master +to = libvir-list@redhat.com +prefix = PATCH rust
I found the reverse order, i.e. 'rust PATCH' to be both nicer and more useful. (not to mention more common) For example, in some downstream lists I use a simple text match against 'libvirt PATCH', which also catches any subsequent version Jano
-- 2.14.3
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On Mon, Apr 23, 2018 at 03:20:53PM +0200, Ján Tomko wrote:
On Mon, Apr 23, 2018 at 01:54:32PM +0100, Daniel P. Berrangé wrote:
The "git-publish" tool is a useful git extension for sending patch series for code review. It automatically creates versioned tags each time code on a branch is sent, so that there is a record of each version. It also remembers the cover letter so it does not need re-entering each time the series is reposted.
With this config file present it is now sufficient[1] to run
$ git publish
to send all patches in a branch to the list for review, with the correct subject prefix added for this non-core libvirt module.
[1] Assuming your $HOME/.gitconfig has an SMTP server listed at least e.g.
[sendemail] smtpserver = smtp.example.com
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> --- .gitpublish | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 .gitpublish
diff --git a/.gitpublish b/.gitpublish new file mode 100644 index 0000000..a86d7a7 --- /dev/null +++ b/.gitpublish @@ -0,0 +1,4 @@ +[gitpublishprofile "default"] +base = master +to = libvir-list@redhat.com +prefix = PATCH rust
I found the reverse order, i.e. 'rust PATCH' to be both nicer and more useful. (not to mention more common)
For example, in some downstream lists I use a simple text match against 'libvirt PATCH', which also catches any subsequent version
I'm not really seeing why it would make any functional difference to ability to match subjects. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

On Mon, Apr 23, 2018 at 02:32:11PM +0100, Daniel P. Berrangé wrote:
On Mon, Apr 23, 2018 at 03:20:53PM +0200, Ján Tomko wrote:
I found the reverse order, i.e. 'rust PATCH' to be both nicer and more useful. (not to mention more common)
For example, in some downstream lists I use a simple text match against 'libvirt PATCH', which also catches any subsequent version
I'm not really seeing why it would make any functional difference to ability to match subjects.
I assume in v2 it would become 'PATCHv2 libvirt', which does not contain the 'PATCH libvirt' string, unlike 'libvirt PATCHv2' and 'libvirt PATCH' Jano

On Mon, 2018-04-23 at 15:20 +0200, Ján Tomko wrote: > On Mon, Apr 23, 2018 at 01:54:32PM +0100, Daniel P. Berrangé wrote:
+[gitpublishprofile "default"] +base = master +to = libvir-list@redhat.com +prefix = PATCH rust
I found the reverse order, i.e. 'rust PATCH' to be both nicer and more useful. (not to mention more common)
Agreed, 'module PATCH' seems to be the de-facto standard, so we should codify that instead of the opposite. -- Andrea Bolognani / Red Hat / Virtualization

On Mon, Apr 23, 2018 at 03:39:13PM +0200, Andrea Bolognani wrote:
On Mon, 2018-04-23 at 15:20 +0200, Ján Tomko wrote: > On Mon, Apr 23, 2018 at 01:54:32PM +0100, Daniel P. Berrangé wrote:
+[gitpublishprofile "default"] +base = master +to = libvir-list@redhat.com +prefix = PATCH rust
I found the reverse order, i.e. 'rust PATCH' to be both nicer and more useful. (not to mention more common)
Agreed, 'module PATCH' seems to be the de-facto standard, so we should codify that instead of the opposite.
Ok, since consensus seems to be for this, I'll swap these patches around before pushing them. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
participants (3)
-
Andrea Bolognani
-
Daniel P. Berrangé
-
Ján Tomko