On 2018-12-06, Florian Weimer <fweimer@xxxxxxxxxx> wrote: > In a sense, it's the old discussion between explicit rename recording > and rename detection. I think it's clear by now that rename detection > has won. > Can you give us some example of a rename detection that works? If a packager cherry-picks patches, he looses upstream's commit IDs. If an upstream uses non-descriptive commit messages (e.g. five commits with the same "A bug fix" subject), commit messages are not uniq. If the packager needs to ammend patches (the commit bodies) to resolve conflicts (i.e. porting back the fixes by rebasing the patches), the code changes are not uniq. If an upstream releases a new version after a year, the packager won't probably remember all the cherry-picked fixes. How can a packager identify which commits originates from the upstream and which are uniq to Fedora and must be carried across rebases to a new release? A tempting answer could be use merge-commits extensively. However, would that really help? I must admit I'm not fond of merge-commits and I don't have much experience with them. If I imagine a dist-git tree full of intermingled upstream and Fedora commits, I don't know how I as a packager would package a new upstream release. Should I just blindy believe in "git merge"? I have a few bad experiences with git losing diff chunks on the way. How could I keep the packaging accountable and verifiable? -- Petr _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
