[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: serial lines -- a proposal

From: Dustin J. Mitchell
Subject: Re: serial lines -- a proposal
Date: Mon, 25 Jan 2010 15:45:28 -0600

On Mon, Jan 25, 2010 at 3:39 PM, Filippo Giunchedi <address@hidden> wrote:
> looks easy to do with a post-receive hook and loop-free, although a bit
> unpleasant to have to git push then git pull again if something has been
> updated, I can look into that if needed.

This is a good point - a git hook that adds commits is probably the
*wrong* way to do this.  A few other means have been suggested:

- reserialize before commit (committer runs
- reserialize at release time
- reserialize by crontab

I think that the first option is probably the ideal, but as has been
discussed we'll forget, a lot.  The latter two options could form a
"backstop" against forgotten set-serial runs, though.  Alternately, a
post-hook that *checks* but does not *change* serials, and rejects
commits that do not adequately update the serial, would also keep us
forgetful kids in line.  But it's more work.

So my vote is to first document and encourage committers to run manually, and then put whatever measures are required in
place to make sure this rule is reasonably adhered to - probably
starting with the crontab.


P.S. Interesting thought: the crontab could send a nag email to the
most recent committer of any macros found to have invalid serials.
That's easier than a post-hook, but still provides some "punishment"
for lazy committers.

Open Source Storage Engineer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]