How to Install and Uninstall git-publish.noarch Package on Fedora 36
Last updated: November 17,2024
1. Install "git-publish.noarch" package
Please follow the instructions below to install git-publish.noarch on Fedora 36
$
sudo dnf update
Copied
$
sudo dnf install
git-publish.noarch
Copied
2. Uninstall "git-publish.noarch" package
Please follow the instructions below to uninstall git-publish.noarch on Fedora 36:
$
sudo dnf remove
git-publish.noarch
Copied
$
sudo dnf autoremove
Copied
3. Information about the git-publish.noarch package on Fedora 36
Last metadata expiration check: 5:49:43 ago on Thu Sep 8 02:05:26 2022.
Available Packages
Name : git-publish
Version : 1.8.1
Release : 1.fc36
Architecture : noarch
Size : 27 k
Source : git-publish-1.8.1-1.fc36.src.rpm
Repository : updates
Summary : Prepare and store patch revisions as git tags
URL : https://github.com/stefanha/git-publish
License : MIT
Description : git-publish handles repetitive and time-consuming details of managing patch
: email submission. It works with individual patches as well as patch series and
: has support for pull request emails.
:
: Each revision is stored as a git tag including the cover letter (if any). This
: makes it easy to refer back to previous revisions of a patch. Numbering is
: handled automatically and the To:/Cc: email addresses are remembered across
: revisions to save you retyping them.
:
: Many projects have conventions for submitting patches. It is possible to
: encode them as a .gitpublish file and hooks/ scripts. This automatically uses
: the right settings and can run a coding style checker or linting tools before
: emails are sent.
Available Packages
Name : git-publish
Version : 1.8.1
Release : 1.fc36
Architecture : noarch
Size : 27 k
Source : git-publish-1.8.1-1.fc36.src.rpm
Repository : updates
Summary : Prepare and store patch revisions as git tags
URL : https://github.com/stefanha/git-publish
License : MIT
Description : git-publish handles repetitive and time-consuming details of managing patch
: email submission. It works with individual patches as well as patch series and
: has support for pull request emails.
:
: Each revision is stored as a git tag including the cover letter (if any). This
: makes it easy to refer back to previous revisions of a patch. Numbering is
: handled automatically and the To:/Cc: email addresses are remembered across
: revisions to save you retyping them.
:
: Many projects have conventions for submitting patches. It is possible to
: encode them as a .gitpublish file and hooks/ scripts. This automatically uses
: the right settings and can run a coding style checker or linting tools before
: emails are sent.