Jonathan Wakely kirjoitti 29.1.2021 klo 18.22:
On 29/01/21 17:04 +0100, Miro Hrončok wrote:
On 29. 01. 21 16:03, Jonathan Wakely wrote:
So if fedpkg clone just added things to .git/info/exclude there would
be no need to modify every .gitignore file in every repo on every
active branch.
That is already the case \o/
https://docs.pagure.org/fedpkg/releases/1.37.html#ignore-files-in-a-cloned-repository
Nice! But making 'fedpkg local' unpack into ./build and then build in
there still seems sensible, so the excluded patterns would change for
that (I don't care about that as I don't use 'fedpkg local', but it
seems like a good suggestion).
Since I got bitten by this, I could try to improve it. Suggestion here
seems workable to me. So 1) using ./build in 'fedpkg local' and 2)
adding that directory 'fedpkg clone' excludes. Clearly defined task with
limited scope.
One question that remains is this: 'fedpkg clone' already does what it
does and from this discussion we know that many people are using it. If
the file locations change, changing fedpkg will lead to confusion,
annoyance and perhaps worse. And while I have not seen any scripts using
'fedpkg local', there may be such. Those would break. So perhaps it
should actually be a new command, maybe 'fedpkg localbuild' (to match
'fedpkg mockbuild'), together with documentation update and runtime
deprecation notice when using 'fedpkg local'.
How does that sound? Particularly to all of you who actually use 'fedpkg
local'. I got the understanding that while generally users are happy
with the current behavior, there is no reason why the file generation
paths could not or should not be made more git friendly.
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