also sprach Eric Wong <normalperson@xxxxxxxx> [2008.05.11.0945 +0100]: > I'm mainly uncomfortable with how it'll interact with dcommit > usage, but since your use case seems to be fetch-only; you may > just disable dcommit if keyword expansion is enabled if it's too > painful to figure out the unexpansion... Unfortunately, it's not fetch-only, I have commit rights upstream and I use them quite often. I understand your reasoning and am not too keen on implementing this hack either. However, the other ways of dealing with it are horrific. Right now, for each release, I have to do: git checkout -b build-$VERSION # undo all changes, basically get pristine upstream zcat ../mypkg_1.0-1.diff.gz | git apply -R # reapply all my Debian changes git diff upstream debian | git apply git commit ... this gets unmanageable when I am using more than just the debian branch, but also feature branches, e.g. debian/fhs-compatibility etc... You wouldn't happen to have a better idea of how to deal with this? :) -- martin | http://madduck.net/ | http://two.sentenc.es/ don't hate yourself in the morning -- sleep till noon. spamtraps: madduck.bogus@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
