Re: [gentoo-user] Re: Re[4]: Re: Portage, git and shallow cloning

[Rich Freeman]

On Sun, Jul 8, 2018 at 4:28 AM Martin Vaeth <martin@×××××.de> wrote:
>
> Rich Freeman <rich0@g.o> wrote:
>
> It's the *history* of the metadata which matters here:

You make a reasonable point here.

> > "The council does not require that ChangeLogs be generated or
> >   distributed through the rsync system. It is at the discretion of our
> >   infrastructure team whether or not this service continues."
>
> The formulation already makes it clear that one did not want to
> put pressure on infra, and at that time it was expected that
> every user would switch to git anyway.

The use of git for history, and yes, in general the Council tries not
to forbid projects from providing services.  The intent was to
communicate that it was simply not an expectation that they do so.

> At that time also the gkeys project was very active, and git was
> (besides webrsync) the only expected way to get checksums for the
> full tree. In particular, rsync was inherently insecure.

Honestly, I don't think gkeys really played any part in this, but
there was definitely an intent for signature checking in the tree to
become more robust.  As you point out (in a part I trimmed) it ought
to be possible to do this.  Indeed, git support for signing commits
was considered a requirement for git implementation.

> >> 4. Even if the user made the mistake to edit a file, portage should
> >>    not just die on syncing.
> >
> > emerge --sync won't die in a situation like in general.
>
> It does: git push refuses to start if there are uncommitted changes.
>

I did a test before I made my post.  emerge --sync works just fine if
there are uncommitted changes in your repository, whether they are
indexed or otherwise.  I didn't test merge conflicts but I'd hope it
would fail if these exist.

-- 
Rich