Pre-commit script to reject commits
I was thinking that we should have a pre-commit script reject commits if a portfile does not increment a revision or version if it changes any of its depends_*. I find this pretty annoying to see commits that add a dependency that don't bump a version or revision. Any other things we should reject commits on? Blair
Blair Zajac wrote:
I was thinking that we should have a pre-commit script reject commits if a portfile does not increment a revision or version if it changes any of its depends_*. I find this pretty annoying to see commits that add a dependency that don't bump a version or revision.
I don't see why changing depends_* should change the revision. Either it prevented the installation at all or users installed the dependency by hand before. It doesn't change the files which are going to be installed. Incrementing the revision would force them to do an unnecessary recompile. The only thing I can think of is that the output of `port dependents' could be 'wrong'. But that's reflecting the state of the port as it was installed, so it is kind of correct. Rainer
Rainer Müller wrote:
Blair Zajac wrote:
I was thinking that we should have a pre-commit script reject commits if a portfile does not increment a revision or version if it changes any of its depends_*. I find this pretty annoying to see commits that add a dependency that don't bump a version or revision.
I don't see why changing depends_* should change the revision. Either it prevented the installation at all or users installed the dependency by hand before. It doesn't change the files which are going to be installed. Incrementing the revision would force them to do an unnecessary recompile.
The only thing I can think of is that the output of `port dependents' could be 'wrong'. But that's reflecting the state of the port as it was installed, so it is kind of correct.
If you have the base port installed, say libfoo, but it's not listed as a dependency, then if you remove it, then you'll unintentionally break any ports that picked up a dependency upon it at configure time. Blair
Blair Zajac wrote:
If you have the base port installed, say libfoo, but it's not listed as a dependency, then if you remove it, then you'll unintentionally break any ports that picked up a dependency upon it at configure time.
Thanks for the clarification, I think you are kind of right. But it will always hit someone not affected by the update. For example, changing depends_* inside some variants and incrementing the revsion forces all users to recompile - even if they don't use this variant... As an additional comment, I don't think port lint is yet stable enough to be used as a commit filter (rejecting commits not passing port lint). Rainer
On Mar 7, 2008, at 12:24, Rainer Müller wrote:
Blair Zajac wrote:
If you have the base port installed, say libfoo, but it's not listed as a dependency, then if you remove it, then you'll unintentionally break any ports that picked up a dependency upon it at configure time.
Thanks for the clarification, I think you are kind of right. But it will always hit someone not affected by the update. For example, changing depends_* inside some variants and incrementing the revsion forces all users to recompile - even if they don't use this variant...
And yet, incrementing the revision is the correct thing to do, if doing so will fix the install for even just a few users, even at the risk of unnecessarily rebuilding the port for others. For example, perl5.8 was updated from revision 1 to 2 in r34508. As I understand it, the change was irrelevant for those using gcc 4.0 (i.e. at least all Mac users), but was necessary for those using gcc 4.2 (perhaps Linux or FreeBSD users). Oh well. I'm not sure such a pre-commit hook is practical to write. How would one write it?
As an additional comment, I don't think port lint is yet stable enough to be used as a commit filter (rejecting commits not passing port lint).
I agree, but my plan wasn't ever to reject commits based on port lint. It should be as it is now: an informational post-commit task.
participants (3)
-
Blair Zajac
-
Rainer Müller
-
Ryan Schmidt