On Thursday, December 6, 2018 3:48:32 PM CET Petr Pisar wrote: > 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 It is not covered by any policy or supported tooling but, just to help myself with future maintenance, I always append "Upstream-commit: <SHA1>" to the commit message whenever I take a patch (commit) from the upstream git repository. Kamil _______________________________________________ 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
