Re: Patch queue management systems

[David Kastrup]

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