Description of problem: unlike "make new-sources" "fedpkg new-sources" does not remove the entries having been contained in "sources" before a "fedpkg new-sources" from .gitignore This leads to ancient cruft gradually piling up in .gitignore and is a regression over "make new-sources" Version-Release number of selected component (if applicable): fedora-packager-0.5.1.4-1.fc13.noarch How reproducible: Always Steps to Reproduce: Check .gitignore before and after a fedpkg new-sources
This is by design. I had people complaining about the old behaviour as it would lead to more files showing up in git status or commit screens, or clean actions would clean out the old tarballs when the user didn't want them to go away yet. Also the .gitignore file I feel is a bit more complex and useful than cvsignore and it's not something I feel comfortable with at this time doing /removals/ automatically from. That said, if more people find this to be an issue, I'll look into it.
(In reply to comment #1) > This is by design. Bummer ... > I had people complaining about the old behaviour as it > would lead to more files showing up in git status or commit screens, or clean > actions would clean out the old tarballs when the user didn't want them to go > away yet. Also the .gitignore file I feel is a bit more complex and useful > than cvsignore and it's not something I feel comfortable with at this time > doing /removals/ automatically from. OK you want packagers to manually fumble around inside of .gitignore and corrupt it. To me this qualifies as serious design flaw and one detail where fedpkg misses it's objectives. Reopening.
Yes, the packagers that complained were also the ones that have additional custom rules in their ignore files. rremoving a single line or a few single lines is not a hard task for a human, but a dangerous task for a program, particularly when the file could be modified outside of the program. Just re-opening the bug isn't really going to change my mind here, but if it makes you feel better, I'll just leave it open and ignore it, unless I see a lot of other people complaining about this.
(In reply to comment #3) > Yes, the packagers that complained were also the ones that have additional > custom rules in their ignore files. rremoving a single line or a few single > lines is not a hard task for a human, but a dangerous task for a program, Nonsense. > particularly when the file could be modified outside of the program. > Just re-opening the bug isn't really going to change my mind here, Thank you for once more demonstrating your understanding of servicing the community. To make that clear: I am far from being excited about fedpkg, I am far from being impressed of its (immature, semi-functional) shape and am far from being impressed how it was deployed (hastily rushed out). > but if it > makes you feel better, I'll just leave it open and ignore it, unless I see a > lot of other people complaining about this. This kind of attitude make me really sad - Rest assured I will try to avoid any further contact with you in future.
Closing as WONTFIX ... Mr Keating prefers to deliberately ignore this bug.
*sigh* always so much fun talking with you Ralf. (In reply to comment #4) > (In reply to comment #3) > > Yes, the packagers that complained were also the ones that have additional > > custom rules in their ignore files. rremoving a single line or a few single > > lines is not a hard task for a human, but a dangerous task for a program, > Nonsense. I'm glad you think so. Years of seeing various programs screw things up when trying to delete content from files that are edited outside the program have taught me otherwise. > > > particularly when the file could be modified outside of the program. > > > Just re-opening the bug isn't really going to change my mind here, > Thank you for once more demonstrating your understanding of servicing the > community. One person does not make a community. At this point I've had more people complain about having fedpkg remove entries than I've had people complain about it not removing entries. I'm servicing the majority of my complainers. I'm sorry if you're currently in the minority. > > To make that clear: I am far from being excited about fedpkg, I am far from > being impressed of its (immature, semi-functional) shape and am far from being > impressed how it was deployed (hastily rushed out). I never expected anything more from you. > > > but if it > > makes you feel better, I'll just leave it open and ignore it, unless I see a > > lot of other people complaining about this. > > This kind of attitude make me really sad - Rest assured I will try to avoid any > further contact with you in future. If only.
(In reply to comment #6) > *sigh* always so much fun talking with you Ralf. You're in error when think I am considering this to be funny - I am considering this to be very sad ... sad for you! > > To make that clear: I am far from being excited about fedpkg, I am far from > > being impressed of its (immature, semi-functional) shape and am far from being > > impressed how it was deployed (hastily rushed out). > > I never expected anything more from you. Ditto. As many examples before, fedpkg is this another example of how RH SW enhances the "great Fedora experience" ... since fedpkg was released maintaining packages in Fedora has evolved into a permanent fight with its bugs and its imaturity.
Created attachment 985210 [details] example .gitignore (changed the name to make it non-hidden) (In reply to Jesse Keating from comment #1) > That said, if more people find this to be an issue, I'll look into it. I don’t agree with Ralf’s tone, but I hate to admit he is right here. The results of this design decision are numerous .gitignore files with nonsensical content like the attached one. Generally I wouldn't care, but this mess break otherwise quite useful fedpkg clean command, where especially with fast changing package like youtube-dl one gets plenty of tarballs pretty fast. Would you reconsider this, please?
*** Bug 628412 has been marked as a duplicate of this bug. ***
(In reply to Matěj Cepl from comment #8) > Created attachment 985210 [details] > example .gitignore (changed the name to make it non-hidden) > > (In reply to Jesse Keating from comment #1) > > That said, if more people find this to be an issue, I'll look into it. > > I don’t agree with Ralf’s tone, What do you expect in people to response to deliberate ignorance? Fatalistic ranting and grumbling is all what's left, in such kind of situations. > but I hate to admit he is right here. The > results of this design decision are numerous .gitignore files with > nonsensical content like the attached one. Meanwhile we're observing other stiles of .gitignore, apparently applied by people who do not use fedpkg clean: /foobar-0[0-9].tar.gz > Generally I wouldn't care, but > this mess break otherwise quite useful fedpkg clean command, Exactly - I recently dropped maintainership of package in protest, to somebody having changed one of my .gitignore to using wildcard rules similar to the above. > Would you reconsider this, please? Yes, please.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Different branch may track different versions of a package. It makes sense to let git ignore all of them. It's not a good idea to assume all packagers are always working on the latest version.