How to Install and Uninstall git-publish.noarch Package on Fedora 35
Last updated: January 12,2025
1. Install "git-publish.noarch" package
Learn how to install git-publish.noarch on Fedora 35
$
sudo dnf update
Copied
$
sudo dnf install
git-publish.noarch
Copied
2. Uninstall "git-publish.noarch" package
In this section, we are going to explain the necessary steps to uninstall git-publish.noarch on Fedora 35:
$
sudo dnf remove
git-publish.noarch
Copied
$
sudo dnf autoremove
Copied
3. Information about the git-publish.noarch package on Fedora 35
Last metadata expiration check: 3:55:40 ago on Wed Sep 7 08:25:01 2022.
Available Packages
Name : git-publish
Version : 1.8.1
Release : 1.fc35
Architecture : noarch
Size : 27 k
Source : git-publish-1.8.1-1.fc35.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.fc35
Architecture : noarch
Size : 27 k
Source : git-publish-1.8.1-1.fc35.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.