* Petr Pisar: > 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? I meant file system rename detection. Nothing works perfectly. But any system only needs to beet the accuracy of the information that developers record manually, and that is a more tractable problem. > 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? Without tooling? The same way as today. Look at the commit and see if it is upstream, using commit subject, author email and date for fuzzy matching if necessary, and commit IDs if listed in the commit message. Even that's an improvement over what people record in patch files today. Without -x, git cherry-pick will not immediately mangle the subject, email and date. With -x, you have the commit ID (but which may not be reliable if it comes from the wrong branch). Tooling can do better and look at the actual changes to match them with seemingly unrelated upstream changes. > 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. You could merge in the upstream history with the remaining downstream-specific patches on top, yes. But it's not necessary to do it this way. > 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? At the minimum: git merge plus diff against the upstream, to see what downstream changes remain. And then perhaps add new commits to revert spurious differences from upstream. Or use the “merge the rebased tree” approach I mentioned. The interesting question is whether we'd preserve that history downstream, when rebasing. Historically, it's a full rebase to Fedora for almost all packages, and it's up to package maintainers to re-instantiate all the downstream customization. Thanks, Florian _______________________________________________ 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
