[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 2/6] docs/devel: add git-publish for patch submitting
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH v2 2/6] docs/devel: add git-publish for patch submitting |
Date: |
Fri, 6 Dec 2024 11:45:58 +0000 |
User-agent: |
Mutt/2.2.13 (2024-03-09) |
On Fri, Dec 06, 2024 at 11:43:11AM +0000, Peter Maydell wrote:
> On Fri, 6 Dec 2024 at 11:32, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Thu, Dec 05, 2024 at 02:22:37PM -0800, Pierrick Bouvier wrote:
> > > Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
> > > ---
> > > docs/devel/submitting-a-patch.rst | 19 +++++++++++++++++++
> > > 1 file changed, 19 insertions(+)
> > >
> > > diff --git a/docs/devel/submitting-a-patch.rst
> > > b/docs/devel/submitting-a-patch.rst
> > > index 03b2ac298aa..f8b7fc59544 100644
> > > --- a/docs/devel/submitting-a-patch.rst
> > > +++ b/docs/devel/submitting-a-patch.rst
> > > @@ -235,6 +235,25 @@ to another list.) ``git send-email`` (`step-by-step
> > > setup guide
> > > works best for delivering the patch without mangling it, but
> > > attachments can be used as a last resort on a first-time submission.
> > >
> > > +.. _use_git_publish:
> > > +
> > > +Use git-publish
> > > +~~~~~~~~~~~~~~~
> > > +
> > > +If you already configured git send-email, you can simply use `git-publish
> > > +<https://github.com/stefanha/git-publish>`__ to send series.
> > > +
> > > +::
> > > +
> > > + $ git checkout master -b my-feature
> > > + $ # work on new commits, add your 'Signed-off-by' lines to each
> > > + $ git publish
> > > + $ ... more work, rebase on master, ...
> > > + $ git publish # will send a v2
> > > +
> > > +Each time you post a series, git-publish will create a local tag with
> > > the format
> > > +``<branchname>-v<version>`` to record the patch series.
> >
> > Lets also mention
> >
> > "When sending patch emails, 'git publish' will consult the output
> > of 'scripts/get_maintainers.pl' and automatically CC anyone listed
> > as maintainers of the affected code. Generally you should accept the
> > suggested CC list, but there may sometimes be scenarios where it is
> > appropriate to cut it down (eg on certain large tree-wide cleanups),
> > or augment it with other interested people"
> >
> > Second, lets say something about pull requests
> >
> > "When a subsystem maintainer is ready to send a pull request, the
> > 'git publish --pull' command will triggering GPG tag signing,
> > publish the branch to the git remote name specified by the
> > 'remote.pushDefault' config option, and send the email series'
>
> We don't do pull requests for the normal "end developer submits
> a patch" process, and given the prevalence of the github/gitlab
> "all contributions go in as pull requests" model, I think that
> talking about pull requests here (except to say "we don't do them")
> would be confusing. If we want to document how you can use git publish
> for pull request submission we can do that in
> docs/devel/submitting-a-pull-request.rst.
Ah yes, I agree with that.
With 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 :|
- [PATCH v2 0/6] Enhance documentation for new developers, Pierrick Bouvier, 2024/12/05
- [PATCH v2 4/6] docs/devel: add information on how to setup build environments, Pierrick Bouvier, 2024/12/05
- [PATCH v2 3/6] docs/devel: add b4 for patch retrieval, Pierrick Bouvier, 2024/12/05
- [PATCH v2 5/6] docs: add a codebase section, Pierrick Bouvier, 2024/12/05
- [PATCH v2 6/6] docs: add a glossary, Pierrick Bouvier, 2024/12/05