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

[Martin Vaeth]

Rich Freeman <rich0@g.o> wrote:
> On Sat, Jul 7, 2018 at 1:34 AM Martin Vaeth <martin@×××××.de> wrote:
>>
>> Biggest issue is that git signature happens by the developer who
>> last commited which means that in practice you need dozens/hundreds
>> of keys.
>
> This is untrue. [...]
> It will, of course, not work on the regular git repo [...]
> You need to use a repo that is signed by infra
> (which typically includes metadata/etc as well).

I was speaking about gentoo's git repository, of course
(the one which was attacked on github), not about a Frankensteined one
with metadata history filling megabytes of disk space unnecessarily.
Who has that much disk space to waste?

For the official git repository your assertions are simply false,
as you apprently admit: It is currently not possible to use the
official git repo (or the github clone of it which was attacked)
in a secure manner.

>> > unless you stick --force in your pull
>>
>> Unfortunately, it is not that simple: git pull --force only works if
> [...]
> You completely trimmed the context around my quote. [...]
> they simply would not be pulled without --force.

I was saying that they would not be pulled *with* --force either,
because pull --force is not as strong as you think it is (it would
have shown you conflicts to resolve manually).
You would have to use the commands that I have posted.

> You seem to be providing advice for how to do a pull with a shallow
> repository

No, what I said is not related to a shallow repository. It has to do
with pulling a forced push, in general.

>> At least since the ChangeLogs have been removed.
>> IMHO it was the wrong decision to not keep them in the rsync tree
>> (The tool to regenerate them from git was/is available).
>
> Changelogs are redundant with git, and they take a ton of space (which
> of late everybody seems to be super-concerned about)

Compared to the git history, they take very little space.
If you squash the portage tree, it is hardly measurable.
And with the ChangeLogs, rsync would still be a sane option for
most users. Without ChangeLogs many users are unnecessarily forced
to change and to sacrifice the space for git history.

> and as a bonus they want them prepended to
> instead of appended so that rsync resends the whole thing instead of
> just the tail...

Your implicit claim is untrue. rsync - as used by portage - always
transfers whole files, only.

> But, this was endlessly debated before the decision was made.

The decision was about removing the ChangeLogs from the git
repository. This was certainly the correct decision, because -
as you said - the ChangeLogs *can* be regenerated from the
git history and thus it makes no sense to modify/store them
redundantly.

But I was speaking about the distribution of ChangeLogs in rsync:
Whenever the infrastructure uses egencache to generate the metadata,
it could simply pass --update-changelogs so that rsync users
still would have ChangeLogs: They cannot get them from git history.

> My
> point is that the sorts of people who like Gentoo would probably tend
> to like git.

"Liking" git does not mean that one has to use it also for things
for which it brings nothing. And for most users none of its features
is useful for the portage tree. With one exception: ChangeLogs.
That's why I am adverising to bring them back to the rsync tree.

> The "keys problem" has nothing to do with the security of git
> verification, because those keys are not used by git verification on
> the end-user side.

Whoever is that git/developer affine that he prefers git despite
it costs more disk space will certainly want to use the actual
source repository and not a worse rsync-clone repository.

> It probably should be a configurable option in repos.conf, but
> honestly, forced pushes are not something that should be considered a
> good practice.

1. portage shouldn't decide about practices of overlays.
2. also in the official gentoo repository force pushes happen
   occassionally. Last occurrence was e.g. when undoing the
   malevolent forced push ;)
3. git pull fails not only for forced pushes but also in several
   other occassions; for instance, if your filesystem changed inodes
   numbers (e.g. squash + overlayfs after a resquash+remount).
4. Even if the user made the mistake to edit a file, portage should
   not just die on syncing.