One more addition I've made to the hooks: rejecting new commits with a
line in the commit message starting 'From-SVN: ', since such commits would
confuse the scripts people have to find the git commit corresponding to a
given SVN commit, and without such a rejection it would be easy for
someone
One further change I've made for the GCC hooks: rejecting commits whose
commit message's first line looks like a ChangeLog header (matches the
regular expression '[0-9]{4}-[0-9]{2}-[0-9]{2} .*<.*@.*>'). That should
help avoid people's habits writing such commit messages carrying over into
comm
> We could, it just feels like "branch names [in refs/heads/] must match one
> of these naming conventions" is something fairly generic rather than
> extremely GCC-specific.
I understand.
My fear is that we're discussing a lot of new configurations knobs.
And from experience, they can start int
On Fri, 10 Jan 2020, Joel Brobecker wrote:
> > No. What we want to ensure is that people don't accidentally create a
> > branch called refs/heads/foo when they should (by our naming conventions)
> > have created one called refs/heads/devel/foo or
> > refs/users/someone/heads/foo. Our naming c
> > > Plus one further change now: if a newly created branch is in refs/heads/,
> > > require it to be in refs/heads/devel/ or refs/heads/releases/ (i.e.
> > > enforce a particular branch naming convention, in particular to prevent
> > > mistakes where people accidentally push a branch into refs
On Fri, 10 Jan 2020, Joel Brobecker wrote:
> > Plus one further change now: if a newly created branch is in refs/heads/,
> > require it to be in refs/heads/devel/ or refs/heads/releases/ (i.e.
> > enforce a particular branch naming convention, in particular to prevent
> > mistakes where people
> > Concretely, these are the changes I'm currently using to configure the
> > hooks in a way I think appropriate for GCC, and it would be useful if the
> > hooks could support such configuration in a more generic way in future so
> > that we can stop using a GCC-specific patched installation of
> * Additional branch namespaces refs/users//heads and
> refs/vendors//heads, and similar tag namespaces
> refs/users//tags and refs/vendors//tags.
Hmmm. Note to self: I missed the fact that this namespace was
also used for tags.
> * Only allowing branch deletion for certain ref patterns (refs/
Hi Joseph,
Apologies for the slow replies. The end of this week has been
pretty packed, and next week will be as well. But I will make
sure we answer every questions and suggestions you have!
On Thu, Jan 09, 2020 at 02:25:59PM +, Joseph Myers wrote:
> On Mon, 16 Sep 2019, Joel Brobecker wrote
On Thu, 9 Jan 2020, Joseph Myers wrote:
> Concretely, these are the changes I'm currently using to configure the
> hooks in a way I think appropriate for GCC, and it would be useful if the
> hooks could support such configuration in a more generic way in future so
> that we can stop using a GCC
On Fri, 10 Jan 2020 at 13:06, Joseph Myers wrote:
>
> On Fri, 10 Jan 2020, Jonathan Wakely wrote:
>
> > Could you avoid the double negative here? And the error message could
> > be more specific to the actual error by testing the two cases
> > separately, e.g.
>
> I'm sort of hoping we don't end u
On Fri, 10 Jan 2020, Jonathan Wakely wrote:
> Could you avoid the double negative here? And the error message could
> be more specific to the actual error by testing the two cases
> separately, e.g.
I'm sort of hoping we don't end up using the hooks in this form for very
long - the patch was pos
On Thu, 9 Jan 2020 at 22:07, Joseph Myers wrote:
>
> @@ -63,6 +63,8 @@ class BranchUpdate(AbstractUpdate):
> # the update unless we have had a chance to verify that these hooks
> # work well with those branches.
> assert (self.ref_name.startswith('refs/heads/')
> +
On Thu, 9 Jan 2020, Joseph Myers wrote:
> On Mon, 16 Sep 2019, Joel Brobecker wrote:
>
> > Looking at the configuration file, I believe the git-hooks
> > should have most, if not all, of the features that would be needed for
> > the GCC repository. In particular, there is already a way to relay
>
On Mon, 16 Sep 2019, Joel Brobecker wrote:
> Looking at the configuration file, I believe the git-hooks
> should have most, if not all, of the features that would be needed for
> the GCC repository. In particular, there is already a way to relay
> commits to third-party tools via calling of a scri
> But before I say more I should point to the documentation which,
> for historical reasons, is available on the GDB wiki rather than
> the git-hooks GitHub repository. I will fix that, but in the meantime:
>
> https://sourceware.org/gdb/wiki/GitHooksUsersGuide
Just a quick note to confirm th
On Tue, 17 Sep 2019, Gerald Pfeifer wrote:
> When, roughly, do you expect the switch can be ready?
That's a matter of how much time we want to allow for people to try out
and comment on the conversion.
> I assume we'll have some sort of flag day?
Yes, at some point we'd do a final conversion a
> > You mean the email notification sent by the hooks when a commit
> > gets pushed? If yes, here is an example:
> >
> > https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00041.html
>
> Thank you, Joel! I got a little worried how to best parse that ;-),
> but then Joseph recommended against it an
On Mon, 16 Sep 2019, Joel Brobecker wrote:
> You mean the email notification sent by the hooks when a commit
> gets pushed? If yes, here is an example:
>
> https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00041.html
Thank you, Joel! I got a little worried how to best parse that ;-),
but then Jos
On Mon, 16 Sep 2019, Gerald Pfeifer wrote:
> On the latter, let's just flip the switch whenever you're ready, and I'll
> see to adjust my script within a day or two and manually perform checks
> until that's done. (If you can create a sample e-mail notification for
> me, I'll use that to start
Hi Gerald,
On Mon, Sep 16, 2019 at 12:15:57AM +0800, Gerald Pfeifer wrote:
> On Sun, 15 Sep 2019, Joseph Myers wrote:
> > Apart from general review of the test conversion / conversion and hook
> > scripts, which everyone can do, I think the main thing would be to advise
> > on what needs to happ
Hello everyone,
On Sat, Sep 14, 2019 at 04:53:17PM -0400, Jason Merrill wrote:
> At Cauldron this weekend Joel offered to adjust his git hooks
> (https://github.com/brobecke/git-hooks), which are already used by gdb
> and glibc, to meet GCC's needs. Separately, Joseph volunteered to
> deal with c
On Sun, 15 Sep 2019, Joseph Myers wrote:
> Apart from general review of the test conversion / conversion and hook
> scripts, which everyone can do, I think the main thing would be to advise
> on what needs to happen to avoid breaking the www.gnu.org copy of the site
> and your HTML validation sy
On Sun, 15 Sep 2019, Gerald Pfeifer wrote:
> Let me know how I can help, and I will do my best. (Even if I'll be
> offline most of the next three weeks, I can get online most days and
> spend some time.)
Apart from general review of the test conversion / conversion and hook
scripts, which every
On Sat, 14 Sep 2019, Jason Merrill wrote:
> Separately, Joseph volunteered to deal with converting the gcc-www
> repository to git and dealing with those hooks.
This is great, thank you!
I was absolutely going to join Cauldron this week, but something personal
is consuming me all of this month
On Sat, 14 Sep 2019, Jason Merrill wrote:
> At Cauldron this weekend Joel offered to adjust his git hooks
> (https://github.com/brobecke/git-hooks), which are already used by gdb
> and glibc, to meet GCC's needs. Separately, Joseph volunteered to
> deal with converting the gcc-www repository to g
26 matches
Mail list logo
