Gwyn Ciesla via devel kirjoitti 28.1.2021 klo 0.09:
If the user doesn't 'git add .', or has a correct .gitignore, this should be a non issue.
Me being the quoted person with a workflow issue, I still think there is
a workflow issue.
Setting .gitignore is possible of course, but rather annoying and
repetitive. Each package has its own repository, so there are a lot of
.gitignore files to configure. Also, the names that need to be ignored
depend on package version, so it is either messy globbing (or perhaps
regexing, if that is supported?) or updating every time version
increases. And 'fedpkg local' generates multiple files and directories
at repository root, yet another multiplier. Doing it manually every time
means spending time with ignore rules instead of packaging software.
The other option of not using 'git add .' can also be described as
mentally filtering out all the irrelevant unstaged changes to find the
ones that should actually be added. That adds cognitive burden, slows
things down and leads to mistakes every now and then. It does not help
to say "do not make mistakes" if the task is inherently error-prone.
Such filtering is something a computer should do, which leads us back to
.gitignore.
Perhaps a script could create the correct ignore globs for all
repositories in one go and that would be it, and have it in the template
for new repositories, too? Just an idea, perhaps not worth the effort
and complexity.
It would help much if 'fedpkg local' would only generate anything in a
single directory with constant name - 'build' or whatever.
(Oh, and for the original question about deprecating 'fedpkg local' - I
don't know. Before this discussion started, I was happily using 'fedpkg
local' and did not even know what mock was. I have to get in terms with
mock to form an opinion.)
The only times I use the git command in fedpkg is to merge between branches, or add/remove packages. If you're just doing changes to things already tracked, such as the spec, sources, patches, scripts, etc, fedpkg commit will add them for you. It also spits out a warning if you commit a spec with a Patch not tracked in git, which is nice.
Thank you for this advice Gwyn, and the same goes for Josh for useful
git option in another response. I will certainly try these suggestions
and see if they can make things easier for me.
Otto
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
