Hey, Ludovic Courtès <l...@gnu.org> writes:
> Hi! > > Maxim Cournoyer <maxim.courno...@gmail.com> skribis: > >>> Maxim Cournoyer <maxim.courno...@gmail.com> skribis: >>> >>>>> +(define (assert-clean-checkout repository) >>>>> + "Error out if the working directory at REPOSITORY contains local >>>>> +modifications." >>>>> + (define description >>>>> + (let ((format-options (make-describe-format-options >>>>> + #:dirty-suffix "-dirty"))) >>>>> + (describe-format (describe-workdir repository) format-options))) >>>>> + >>>>> + (when (string-suffix? "-dirty" description) >>>>> + (leave (G_ "attempt to update 'guix' package from a dirty tree >>>>> (~a)~%") >>>>> + description)) >>>>> + >>>>> + (info (G_ "updating 'guix' package to '~a'~%") description)) >>>> >>>> Unfortunately this doesn't catch the case where git has explicitly been >>>> told to '--skip-worktree' on a path or file (the original cause of this >>>> bug report). See >>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43893#11. >>> >>> Any such issue is caught when one eventually runs ‘guix build guix’ >>> (wrong commit ID, wrong hash, etc.). >>> >>> But you’re right that the above test isn’t fool-proof: it’s just a way >>> to catch this common mistake early and report it nicely. >> >> Right. I still don't like that it wouldn't work from a checkout where >> someone would have modified, e.g., the .dir-locals file locally and >> marked it with 'git --skip-worktree'. Having to revert this kind of >> 'developer setup' is painful. The current approach makes it unnecessary >> (only committed changes are taken into account, not just git tracked >> files). > > “Wouldn’t work” is a strong statement: like I wrote, mistakes would > always be caught when you try to build ‘guix’, as with any other package > (we don’t have special support for other packages, why would this one > have to be different?). True. I meant it in the sense "I wouldn't be able to update the Guix package before manually ensuring that the HEAD of my tree was in a pristine condition, that is, equivalent to the last commit". Since Guix is the focus of Guix developers, it's much more likely to have its sources in flux compared to the other packages we update in Guix. To me it seems useful to automate the 'cleanliness' part of the tree rather than force it on developers, since it can be. We also don't update the package in place from a Git checkout when updating other packages. It's a manual work of 'git clone', 'guix hash -rx' and editing the source manually, which is different from 'make update-guix-package', which strives to automate the process. My 2 cents! Time will tell if this is a viable route. If it breaks every time we use it, we can fallback to the simpler scheme. Maxim
