| Message ID | 20250718-new-tag-git-fetcher-v2-1-11240d481a05@bootlin.com |
|---|---|
| State | Accepted, archived |
| Commit | 85b31a55d114a1430868233d56573b470fef8908 |
| Headers | show |
| Series | Update the Git fetcher tag and rev descriptions | expand |
On Fri, 2025-07-18 at 11:06 +0200, Antonin Godard via lists.yoctoproject.org wrote: > After commit d591d7633fe8 ("fetch/git: Rework tag parameter handling"), > update the description of the tag= parameter for the Git fetcher. > > Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> > --- > doc/bitbake-user-manual/bitbake-user-manual-fetching.rst | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst b/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst > index a2c2432db1..51c9a81e03 100644 > --- a/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst > +++ b/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst > @@ -439,10 +439,11 @@ This fetcher supports the following parameters: > - *"rev":* The revision to use for the checkout. The default is > "master". > > -- *"tag":* Specifies a tag to use for the checkout. To correctly > - resolve tags, BitBake must access the network. For that reason, tags > - are often not used. As far as Git is concerned, the "tag" parameter > - behaves effectively the same as the "rev" parameter. > +- *"tag":* Specifies a tag to match against the supplied revision (``rev=``). > + This does not replace the ``rev`` parameter: the ``tag`` parameter should > + only be specified if you want to verify that the tag commit SHA matches the > + supplied ``rev`` SHA. The ``tag`` parameter is optional, but strongly > + recommended if the checked out revision is a tag. This isn't quite right since the behaviour of "tag" alone didn't change, we just altered the behaviour allowing it to be specified with rev, which makes it much more useful. It should probably say: ''' *"tag":* Specifies a tag to use when fetching. To correctly resolve tags, BitBake must access the network. If a ``rev`` parameter or SRCREV is also specified, network access is not necessary to resolve the tag and instead, it is verified that they both resolve to the same commit SHA at unpack time. The ``tag`` parameter is optional, but strongly recommended if the checked out revision is a tag. ''' Cheers, Richard
diff --git a/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst b/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst index a2c2432db1..51c9a81e03 100644 --- a/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst +++ b/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst @@ -439,10 +439,11 @@ This fetcher supports the following parameters: - *"rev":* The revision to use for the checkout. The default is "master". -- *"tag":* Specifies a tag to use for the checkout. To correctly - resolve tags, BitBake must access the network. For that reason, tags - are often not used. As far as Git is concerned, the "tag" parameter - behaves effectively the same as the "rev" parameter. +- *"tag":* Specifies a tag to match against the supplied revision (``rev=``). + This does not replace the ``rev`` parameter: the ``tag`` parameter should + only be specified if you want to verify that the tag commit SHA matches the + supplied ``rev`` SHA. The ``tag`` parameter is optional, but strongly + recommended if the checked out revision is a tag. - *"subpath":* Limits the checkout to a specific subpath of the tree. By default, the whole tree is checked out.
After commit d591d7633fe8 ("fetch/git: Rework tag parameter handling"), update the description of the tag= parameter for the Git fetcher. Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> --- doc/bitbake-user-manual/bitbake-user-manual-fetching.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)