[Top][All Lists]

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

Re: Patch queue management systems

From: David Kastrup
Subject: Re: Patch queue management systems
Date: Thu, 11 Dec 2014 15:39:51 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Ted Zlatanov <address@hidden> writes:

> On Thu, 11 Dec 2014 13:38:15 +0100 Steinar Bang <address@hidden> wrote: 
>>>>>>> Ted Zlatanov <address@hidden>:
> SB> If that repository resides on the same server and is created with
> SB> hardlinks to the real repo, it should also be cheap disk-usage-wise,
> SB> at least initially....)
>>> Eh.
> SB>  cd /wherever/the/emacs/repo/lives
> SB>  git clone --mirror ./emacs.git ./emacs-feature-branches.git
> SB> If the git used is reasonably new, then all of the known-by-hash objects
> SB> in the new repository will be hardlinks to the original repo (which is
> SB> safe since these will never change).
> I know all that (and the ways to override it) :)
> I was saying that saving disk space is really low on the list of
> benefits. Allowing non-fast-forward pushes for certain branches is much
> more valuable to the Emacs project.
> Stefan, Glenn: any chance we can get a contributor repo set up that's
> just like the Emacs repo but allows non-fast-forward pushes, and whose
> commits go to emacs-diffs?  Even better would be if user X could only
> push to branches "X/.*"

Doesn't need a separate repo: a server side commit hook refusing
non-fast-forward pushes (more exactly: updating the reference after the
commit object is already there) on any path not starting, say, with
dev/, should be easily possible.

David Kastrup

reply via email to

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