C. Bergström posted on Mon, 15 Sep 2014 02:49:48 +0700 as excerpted:
> Pretty please do NOT allow "merge" commits.. they are the bane of evil
> for the long term ability to have any sane work-flow. Trying browsing a
> commit history after a big merge commit.. or following the parent..
You just ca
hasufell posted on Sun, 14 Sep 2014 13:50:32 + as excerpted:
> Jauhien Piatlicki:
>>
>> Again, how will user check the integrity and authenticity if Manifests
>> are unsigned?
> There is no regression if this isn't solved.
> People who really care use emerge-webrsync.
> If we use the propos
On 2014-09-14 21:57, Kent Fredric wrote:
> I generate metadata for the perl-experimental overlay periodically as a
> snapshotted variation of the same, and the performance isn't so bad.
Overlays with few eclasses are much different than the main tree.
Anyway, egencache isn't bad it's just signific
On 15 September 2014 13:30, Tim Harder wrote:
> I haven't run portage metadata regen on a beefy machine lately, but I
> don't think it could keep up in all cases. Perhaps someone can prove me
> wrong.
>
> Anyway, things could definitely be sped up if portage merges a few speed
> tweaks used in pk
On 2014-09-14 10:46, Michał Górny wrote:
> Dnia 2014-09-14, o godz. 15:40:06
> Davide Pesavento napisał(a):
> > How long does the md5-cache regeneration process take? Are you sure it
> > will be able to keep up with the rate of pushes to the repo during
> > "peak hours"? If not, maybe we could use
On 15 September 2014 13:06, Peter Stuge wrote:
> even after
> the commits.
>
I've even made branches in "detached head" state ( that is, without a
branch ) and given them branches after the fact.
After all, branches aren't really "things", they're just pointers to SHA1s,
that get repointed to n
Rich Freeman wrote:
> If you just want to do 15 standalone commits before you push you can
> do those sequentially easily enough. A branch would be more
> appropriate for some kind of mini-project.
..
> That is the beauty of git - branches are really cheap.
> So are repositories
And commits.
Not
Patrick Lauer wrote:
> > > That'd mean I need half a dozen checkouts just to emulate cvs, which
> > > somehow doesn't make much sense to me ...
> >
> > Unlike CVS, git doesn't force you to work in "Keep millions of files in
> > uncommitted states" mode just to work on a codebase, due to the commit
On Sun, Sep 14, 2014 at 7:21 PM, Patrick Lauer wrote:
>
> iow, git doesn't allow people to work on more than one item at a time?
>
> That'd mean I need half a dozen checkouts just to emulate cvs, which somehow
> doesn't make much sense to me ...
>
Well, you can work on as many things as you like
Patrick Lauer:
> On Monday 15 September 2014 11:27:34 Kent Fredric wrote:
>> On 15 September 2014 11:21, Patrick Lauer wrote:
>>> iow, git doesn't allow people to work on more than one item at a time?
>>>
>>> That'd mean I need half a dozen checkouts just to emulate cvs, which
>>> somehow
>>> does
On 15 September 2014 11:25, hasufell wrote:
> Robin said
> > The Git commit-signing design explicitly signs the entire commit,
> including blob contents, to avoid this security problem.
>
> Is this correct or not?
>
I can verify a commit by hand with only the commit object and gpg, but
without a
Patrick Lauer:
> On Sunday 14 September 2014 15:42:15 hasufell wrote:
>> Patrick Lauer:
Are we going to disallow merge commits and ask devs to rebase local
changes in order to keep the history "clean"?
>>>
>>> Is that going to be sane with our commit frequency?
>>
>> You have to merge or
On Monday 15 September 2014 11:27:34 Kent Fredric wrote:
> On 15 September 2014 11:21, Patrick Lauer wrote:
> > iow, git doesn't allow people to work on more than one item at a time?
> >
> > That'd mean I need half a dozen checkouts just to emulate cvs, which
> > somehow
> > doesn't make much sen
On Sun, Sep 14, 2014 at 11:25:33PM +, hasufell wrote:
> So can we get this clear now.
>
> Robin said
>
> > The Git commit-signing design explicitly signs the entire commit,
> > including blob contents, to avoid this security problem.
>
> Is this correct or not?
That is false. The commit sig
On 15 September 2014 11:21, Patrick Lauer wrote:
> iow, git doesn't allow people to work on more than one item at a time?
>
> That'd mean I need half a dozen checkouts just to emulate cvs, which
> somehow
> doesn't make much sense to me ...
>
Use the Stash. Or just commit items, then swap branch
Rich Freeman:
> On Sun, Sep 14, 2014 at 6:56 PM, hasufell wrote:
>> According to Robin, it's not about rebasing, it's about signing all
>> commits so that messing with the blob (even if it has the same sha-1)
>> will cause signature verification failure.
>>
>
> The only thing that gets signed is
On Sun, Sep 14, 2014 at 07:13:21PM -0400, Rich Freeman wrote:
> The only thing that gets signed is the commit message, and the only
> thing that ties the commit message to the code is the sha1 of the
> top-level tree. If you can attack sha1 either at any tree level or at
> the blob level you can d
On 15 September 2014 11:15, W. Trevor King wrote:
> All cherry-pick and am do is apply one commit's diff to a different
> parent. Changing the parent hash (which is stored in the commit body
> [1]), so old signatures won't apply to the new commit. If there have
> been other tree changes between
Masked for removal in 30 days. See bug #515028
Ancient and unmaintained.
--
Dion Moult
On Sunday 14 September 2014 15:42:15 hasufell wrote:
> Patrick Lauer:
> >> Are we going to disallow merge commits and ask devs to rebase local
> >> changes in order to keep the history "clean"?
> >
> > Is that going to be sane with our commit frequency?
>
> You have to merge or rebase anyway in c
On 15 September 2014 10:56, hasufell wrote:
> According to Robin, it's not about rebasing, it's about signing all
> commits so that messing with the blob (even if it has the same sha-1)
> will cause signature verification failure.
>
Correct me if I'm wrong, but wouldn't a SHA1 attack on the tree
On Sun, Sep 14, 2014 at 10:56:33PM +, hasufell wrote:
> W. Trevor King:
> > On Sun, Sep 14, 2014 at 10:38:41PM +, hasufell wrote:
> >> So we'd basically end up using either "git cherry-pick" or "git
> >> am" for "pulling" user stuff, so that we also sign the blobs.
> >
> > Rebasing the ori
On Sun, Sep 14, 2014 at 6:56 PM, hasufell wrote:
> According to Robin, it's not about rebasing, it's about signing all
> commits so that messing with the blob (even if it has the same sha-1)
> will cause signature verification failure.
>
The only thing that gets signed is the commit message, and
Masked for removal in 30 days. Please see bug #434366
It has no support for new API since 2012. A good replacement of this package,
app-text/pastebinit, is already stabilized.
--
Dion Moult
W. Trevor King:
> On Sun, Sep 14, 2014 at 10:38:41PM +, hasufell wrote:
>> Yes, there is a possible attack vector mentioned in this comment
>> https://bugs.gentoo.org/show_bug.cgi?id=502060#c16
>
> From that comment, the point 1.2 is highly unlikely [1]:
>
> 1. Attacker constructs a init.d
On Sun, Sep 14, 2014 at 10:38:41PM +, hasufell wrote:
> Yes, there is a possible attack vector mentioned in this comment
> https://bugs.gentoo.org/show_bug.cgi?id=502060#c16
From that comment, the point 1.2 is highly unlikely [1]:
1. Attacker constructs a init.d script, regular part at the
W. Trevor King:
> On Sun, Sep 14, 2014 at 05:40:30PM +0200, Michał Górny wrote:
>> Dnia 2014-09-15, o godz. 03:15:14 Kent Fredric napisał(a):
>>> Only downside there is the way github pull reqs work is if the
>>> final SHA1's that hit tree don't match, the pull req doesn't
>>> close.
>>>
>>> Soluti
On Sun, Sep 14, 2014 at 05:40:30PM +0200, Michał Górny wrote:
> Dnia 2014-09-15, o godz. 03:15:14 Kent Fredric napisał(a):
> > Only downside there is the way github pull reqs work is if the
> > final SHA1's that hit tree don't match, the pull req doesn't
> > close.
> >
> > Solutions:
> >
> > - A)
Michał Górny wrote:
> What I need others to do is provide the hosting for git repos.
I'm happy to set up repos on my git server with custom hooks and
accounts as needed.
It's probably not what we want long-term, but it might be useful as
proof of concept, so that infra only needs to do setup one
I think the better option Is to block rsync and force emerge-webrsync
.sended from a phone
Il 14/09/2014 14:03, Michał Górny ha scritto:
> The rsync tree
> --
>
> We'd also propagate things to rsync. We'd have to populate it with old
> ChangeLogs, new ChangeLog entries (autogenerated fr
Il 14/09/2014 14:03, Michał Górny ha scritto:
> The rsync tree
> --
>
> We'd also propagate things to rsync. We'd have to populate it with old
> ChangeLogs, new ChangeLog entries (autogenerated from git) and thick
> Manifests. So users won't notice much of a change.
>
If this will chang
>
> However, rebasing changes *on* master, before they are pushed, is a good
> thing, because that kills non-fast-forward merges.
>
Nontrivial rebases *on* master can be problematic because you're changing
history.
Imagine you pull some nice commits from a user. Then at some point you will
h
"C. Bergström":
> Pretty please do NOT allow "merge" commits.. they are the bane of evil
> for the long term ability to have any sane work-flow.
It works pretty well for the linux kernel.
Ofc it's a matter of actually handling it. If people are unable to
properly handle tools/methods, everything
On 09/15/14 02:34 AM, hasufell wrote:
William Hubbs:
On Sun, Sep 14, 2014 at 08:04:12PM +0200, Andreas K. Huettel wrote:
Deciding on a _commit policy_ should be fairly straightforward and we
already have one point
* gpg sign every commit (unless it's a merged branch, then we only care
about the
William Hubbs:
> On Sun, Sep 14, 2014 at 08:04:12PM +0200, Andreas K. Huettel wrote:
>>
>>> Deciding on a _commit policy_ should be fairly straightforward and we
>>> already have one point
>>> * gpg sign every commit (unless it's a merged branch, then we only care
>>> about the merge commit)
>>
>>
On Sun, Sep 14, 2014 at 08:04:12PM +0200, Andreas K. Huettel wrote:
>
> > Deciding on a _commit policy_ should be fairly straightforward and we
> > already have one point
> > * gpg sign every commit (unless it's a merged branch, then we only care
> > about the merge commit)
>
> +1
Merge commits
> Deciding on a _commit policy_ should be fairly straightforward and we
> already have one point
> * gpg sign every commit (unless it's a merged branch, then we only care
> about the merge commit)
+1
> More things to consider for commit policy are:
> * commit message format (line length, maybe p
> "MG" == Michał Górny writes:
MG> This means we don't have to wait till someone figures out the perfect
MG> way of converting the old CVS repository. You don't need that history
MG> most of the time, and you can play with CVS to get it if you really do.
MG> In any case, we would likely strip
On Sun, Sep 14, 2014 at 6:10 PM, hasufell wrote:
> Let's try it with push access for every developer.
+1.
I'm pretty strongly opposed to leaving the history behind. I'd tend to
agree with Rich when he says that history conversion is pretty much a
solved problem, anyway.
Cheers,
Dirkjan
Rich Freeman:
> On Sun, Sep 14, 2014 at 10:56 AM, Michał Górny wrote:
>> Dnia 2014-09-14, o godz. 10:33:03
>>
>> With git, we can finally do stuff like preparing everything and pushing
>> in one go. Rebasing or merging will be much easier then, since
>> the effective push rate will be smaller than
On Sun, Sep 14, 2014 at 11:11 AM, hasufell wrote:
>
> The only hard part is that people have to know the differences between
> merging/rebasing, fast-forward merges, non-fast-forward merges etc. and
> when and when not to do them.
>
> 'git rebase' is a powerful thing, but also pretty good to mess
On Sun, Sep 14, 2014 at 11:42 AM, hasufell wrote:
> Patrick Lauer:
>>> Are we going to disallow merge commits and ask devs to rebase local
>>> changes in order to keep the history "clean"?
>>
>> Is that going to be sane with our commit frequency?
>>
>
> You have to merge or rebase anyway in case o
On Sun, Sep 14, 2014 at 10:56 AM, Michał Górny wrote:
> Dnia 2014-09-14, o godz. 10:33:03
>
> With git, we can finally do stuff like preparing everything and pushing
> in one go. Rebasing or merging will be much easier then, since
> the effective push rate will be smaller than current commit rate.
Dnia 2014-09-15, o godz. 03:15:14
Kent Fredric napisał(a):
> On 15 September 2014 02:40, Michał Górny wrote:
>
> > However, I'm wondering if it would be possible to restrict people from
> > accidentally committing straight into github (e.g. merging pull
> > requests there instead of to our main
Patrick Lauer:
>> Are we going to disallow merge commits and ask devs to rebase local
>> changes in order to keep the history "clean"?
>
> Is that going to be sane with our commit frequency?
>
You have to merge or rebase anyway in case of a push conflict, so the
only difference is the method and
On Sunday 14 September 2014 15:40:06 Davide Pesavento wrote:
> On Sun, Sep 14, 2014 at 2:03 PM, Michał Górny wrote:
> > We have main developer repo where developers work & commit and are
> > relatively happy. For every push into developer repo, automated magic
> > thingie merges stuff into user sy
On 15 September 2014 02:40, Michał Górny wrote:
> However, I'm wondering if it would be possible to restrict people from
> accidentally committing straight into github (e.g. merging pull
> requests there instead of to our main server).
>
Easy.
Put the Gentoo repo in its own group.
Don't give a
Rich Freeman:
>
> This is one of the blockers. We haven't actually decided how we want
> to use git.
>
There are IMO 3 main things to consider for a git workflow:
* commit policy
* branching model
* remote model
(and history format somewhere implicitly)
Deciding on a _commit policy_ should be
Dnia 2014-09-14, o godz. 10:33:03
Rich Freeman napisał(a):
> > Of course, that assumes infra is
> > going to cooperate quickly or someone else is willing to provide the
> > infra for it.
>
> The infra components to a git infrastructure are one of the main
> blockers at this point. I don't reall
Dnia 2014-09-14, o godz. 15:23:24
Jauhien Piatlicki napisał(a):
> Another question: will it be possible to maintain a copy of tree on github to
> make contributions for users simpler (similarly to e.g. science overlay)?
> (Can it somehow be combined with proposed signing mechanism?)
Yes. I'm p
Dnia 2014-09-14, o godz. 15:40:06
Davide Pesavento napisał(a):
> On Sun, Sep 14, 2014 at 2:03 PM, Michał Górny wrote:
> > We have main developer repo where developers work & commit and are
> > relatively happy. For every push into developer repo, automated magic
> > thingie merges stuff into use
Dnia 2014-09-14, o godz. 15:17:41
Ulrich Mueller napisał(a):
> > On Sun, 14 Sep 2014, Michał Górny wrote:
>
> > I think we should also merge gentoo-news & glsa & herds.xml into the
> > repository. They all reference Gentoo packages at a particular state
> > in time, and it would be much nice
Dnia 2014-09-14, o godz. 15:09:25
Jauhien Piatlicki napisał(a):
> 14.09.14 14:03, Michał Górny написав(ла):
> > Hi,
> >
> > I'm quite tired of promises and all that perfectionist non-sense which
> > locks us up with CVS for next 10 years of bikeshed. Therefore, I have
> > prepared a plan how to
On Sun, Sep 14, 2014 at 8:03 AM, Michał Górny wrote:
>
> I'm quite tired of promises and all that perfectionist non-sense which
> locks us up with CVS for next 10 years of bikeshed.
While I tend to agree with the sentiment, I don't think you're
actually targeting the problems that aren't already
On 15 September 2014 00:03, Michał Górny wrote:
> This means we don't have to wait till someone figures out the perfect
> way of converting the old CVS repository. You don't need that history
> most of the time, and you can play with CVS to get it if you really do.
>
Once somebody works this out
On Sun, Sep 14, 2014 at 3:55 PM, hasufell wrote:
> Davide Pesavento:
>>> In any case, we would likely strip the history anyway to get a small
>>> repo to work with.
>>>
>>> I have prepared a basic git update hook that keeps master clean
>>> and attached it to the bug [1]. It enforces basic policie
Jauhien Piatlicki:
>
> Or well, have our own pull requests review tool.
>
>
Also only a secondary problem. Mirroring on github/bitbucket whatever
should be fairly straightforward to allow user contributions.
In addition the usual git workflow via e-mail/ML would become more
popular (either via
Davide Pesavento:
>> Main developer repo
>> ---
>>
>> I was able to create a start git repository that takes around 66M
>> as a git pack (this is how much you will have to fetch to start working
>> with it). The repository is stripped clean of history and ChangeLogs,
>> and has thin
Jauhien Piatlicki:
>
> Again, how will user check the integrity and authenticity if Manifests are
> unsigned?
>
While this is an issue to be solved, it shouldn't be a blocker for the
git migration.
There is no regression if this isn't solved. There is no sane automated
method for verifying sig
On Sun, Sep 14, 2014 at 2:03 PM, Michał Górny wrote:
> We have main developer repo where developers work & commit and are
> relatively happy. For every push into developer repo, automated magic
> thingie merges stuff into user sync repo and updates the metadata cache
> there.
How long does the md
> On Sun, 14 Sep 2014, Johannes Huber wrote:
> Am Sonntag 14 September 2014, 15:17:41 schrieb Ulrich Mueller:
>> > On Sun, 14 Sep 2014, Michał Górny wrote:
>> > I think we should also merge gentoo-news & glsa & herds.xml into the
>> > repository. They all reference Gentoo packages at a par
14.09.14 15:25, "C. Bergström" написав(ла):
> On 09/14/14 08:24 PM, Jauhien Piatlicki wrote:
>> 14.09.14 15:23, Jauhien Piatlicki написав(ла):
>>> Another question: will it be possible to maintain a copy of tree on github
>>> to make contributions for users simpler (similarly to e.g. science
>>>
On 09/14/14 08:24 PM, Jauhien Piatlicki wrote:
14.09.14 15:23, Jauhien Piatlicki написав(ла):
Another question: will it be possible to maintain a copy of tree on github to
make contributions for users simpler (similarly to e.g. science overlay)? (Can
it somehow be combined with proposed signin
14.09.14 15:23, Jauhien Piatlicki написав(ла):
> Another question: will it be possible to maintain a copy of tree on github to
> make contributions for users simpler (similarly to e.g. science overlay)?
> (Can it somehow be combined with proposed signing mechanism?)
>
>
Or well, have our own p
Another question: will it be possible to maintain a copy of tree on github to
make contributions for users simpler (similarly to e.g. science overlay)? (Can
it somehow be combined with proposed signing mechanism?)
signature.asc
Description: OpenPGP digital signature
Am Sonntag 14 September 2014, 15:17:41 schrieb Ulrich Mueller:
> > On Sun, 14 Sep 2014, Michał Górny wrote:
> > I think we should also merge gentoo-news & glsa & herds.xml into the
> > repository. They all reference Gentoo packages at a particular state
> > in time, and it would be much nicer t
> On Sun, 14 Sep 2014, Michał Górny wrote:
> I think we should also merge gentoo-news & glsa & herds.xml into the
> repository. They all reference Gentoo packages at a particular state
> in time, and it would be much nicer to have them synced properly.
Not a good idea, because we may want to
Hi,
14.09.14 14:03, Michał Górny написав(ла):
> Hi,
>
> I'm quite tired of promises and all that perfectionist non-sense which
> locks us up with CVS for next 10 years of bikeshed. Therefore, I have
> prepared a plan how to do git migration, and I believe it's doable in
> less than 2 weeks (plus
Hi,
I'm quite tired of promises and all that perfectionist non-sense which
locks us up with CVS for next 10 years of bikeshed. Therefore, I have
prepared a plan how to do git migration, and I believe it's doable in
less than 2 weeks (plus the testing). Of course, that assumes infra is
going to coo
69 matches
Mail list logo
