Date: Sun, 18 Nov 2012 19:53:50 -0600 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident] Message-ID: <50A9912E.3090608@freebsd.org> In-Reply-To: <20121118073128.GG73505@kib.kiev.ua> References: <CAD2Ti29UoFcHendR8CcdQ4FPNW1HH0O47B1i3JW00Lke2m2POg@mail.gmail.com> <20121117221143.41c29ba2@nonamehost> <op.wnxq9eo0g7njmm@michael-think> <CADLo838oG26KmfHJ%2BtLh82GoJzzRtfqy69%2BNny1_DC8F8X4POQ@mail.gmail.com> <50a8eb34.5pMwq6kSsi47QgKI%perryh@pluto.rain.com> <20121118073128.GG73505@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/18/12 01:31, Konstantin Belousov wrote:
> On Sat, Nov 17, 2012 at 11:05:40PM -0800, Perry Hutchison wrote:
>> [trimmed some of the lists]
>>
>> Chris Rees <utisoft@gmail.com> wrote:
>>> ... git doesn't work with our workflow.
>> I'm sure the workflow itself is documented somewhere, but is
>> there a good writeup of _how_ git doesn't work with it, e.g. what
>> capabilit{y,ies} is/are missing? Seems this might be of interest
>> to the git developers, not because they necessarily want to support
>> FreeBSD as such, but as an example of a real-world workflow that git
>> currently does not handle well.
> Git would work well with our workflow. It supports the centralized
> repository model, which the project employs right now.
>
> The biggest issues, assuming the project indeed decides to move to Git
> right now, are the migration costs, both in the term of the technical
> efforts needed, and the learning curve for the most population of the
> committers.
>
> Relatively minor problem, at least with the current rate of the commits,
> would be a commit race, when the shared repo head forwarded due to the
> parallel commit. The issue should be somewhat mitigated by the Git
> allowance to push a set of changes in one push.
git would be a huge step backward from svn for the central repo in lots
of ways. Besides being (in my experience) extremely fragile and
error-prone and the issues of workflow that have been brought up, the
loss of monotonic revision numbers is a really major problem. Switching
SCMs as a result of a security problem is also an action totally
disproportionate with the issue that should not be made in a panic.
Having more [cryptographic] verifiability in the release process is a
good thing; it is not strictly related to the choice of version control
system.
-Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50A9912E.3090608>