On Thursday, December 6, 2018 3:48:32 PM CET Petr Pisar wrote:
On 2018-12-06, Florian Weimer <fweimer(a)redhat.com> 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