On 19 September 2014 07:33, Diamond wrote:
> Lets assume, that I don't want to scrap old ebuild yet. There's no git
> cp command. git mv is just git rm + git add. That's what does it look
> like (usual revbump with git add in reality):
>
> https://github.com/cerebrum/dr/commit/311df9b04d876f58474
Diamond wrote:
> I stumbled over this problem when started to use git for packages.
Use git show -M to unstumble yourself.
//Peter
On Thu, 18 Sep 2014 16:00:59 -0400
Rich Freeman wrote:
> What would you propose? The problem you raise is just as much an
> issue with cvs. I don't get a continuous history across revbumps in
> cvs today, so I don't really see a problem with moving to git.
I don't know what to propose. I stumbl
On Thu, Sep 18, 2014 at 3:33 PM, Diamond wrote:
> Lets assume, that I don't want to scrap old ebuild yet. There's no git
> cp command. git mv is just git rm + git add. That's what does it look
> like (usual revbump with git add in reality):
> https://github.com/cerebrum/dr/commit/311df9b04d876f584
On Thu, 18 Sep 2014 17:04:55 +1200
Kent Fredric wrote:
> What's more, you can in fact do:
>
> git mv foo-1.ebuild foo-2.ebuild
> git commit
>
> and you can still easily tell git to show that as a difference in a
> log.
>
> Example script to emulate this and example output:
> https://gist.githu
On 18 September 2014 13:01, Rich Freeman wrote:
> With git a revbump is:
> cp foo-1.ebuild foo-2.ebuild
> git add foo-2.ebuild
> git commit
>
> (I left out changelogs, repoman, etc, since there is no change with
> any of these, and I left out syncing the git repo.)
>
> There really is nothing new
On Wed, Sep 17, 2014 at 4:02 PM, Diamond wrote:
> On Mon, 15 Sep 2014 14:51:56 -0400
> Rich Freeman wrote:
>>
>> In general you want each commit to represent a single "change." That
>> might be a revbump in a single package, or it might be a package move
>> that involves touching 300 packages in
On 18 September 2014 08:02, Diamond wrote:
> Git doesn't do this by default and it
> will might be a nightmare to compare such revbumps by hand.
>
git diff -M1 -C1
^ is usually sufficient to show new files as differences between similar
files that were already there, including revbumps.
--
On Mon, 15 Sep 2014 14:51:56 -0400
Rich Freeman wrote:
>
> In general you want each commit to represent a single "change." That
> might be a revbump in a single package, or it might be a package move
> that involves touching 300 packages in a single commit.
Is it right that you are going to mo
On 09/16/2014 01:56 PM, hasufell wrote:
> Luca Barbato:
>> On 15/09/14 01:21, Patrick Lauer wrote:
>>> 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 "cle
Dnia 2014-09-16, o godz. 19:05:18
Luca Barbato napisał(a):
> On 14/09/14 16:46, Michał Górny wrote:
> > Of course, if we can't spare the resources to do intermediate updates,
> > we may as well switch to cron-based update method.
>
> The mirror have a sync time, so basically regenerating the cac
Luca Barbato:
> On 15/09/14 01:21, Patrick Lauer wrote:
>> 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 ou
On Tue, Sep 16, 2014 at 1:07 PM, Luca Barbato wrote:
> On 14/09/14 17:30, Patrick Lauer wrote:
>>> 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?
>>
>
> Which is our com
On 15/09/14 01:21, Patrick Lauer wrote:
> 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?
>>
On 14/09/14 17:30, Patrick Lauer wrote:
>> 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?
>
Which is our commit frequency? Worst case we can aggregate changes and
push th
On 14/09/14 16:46, Michał Górny wrote:
> Of course, if we can't spare the resources to do intermediate updates,
> we may as well switch to cron-based update method.
The mirror have a sync time, so basically regenerating the cache and
pushing the tree with further toward the user can happen the sam
On 14/09/14 17:15, Kent Fredric wrote:
> 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
On Mon, Sep 15, 2014 at 1:42 PM, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 14/09/14 09:06 PM, Peter Stuge wrote:
>> Rich Freeman wrote:
>>> If you just want to do 15 standalone commits before you push you
>>> can do those sequentially easily enough. A bran
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 14/09/14 09:06 PM, Peter Stuge wrote:
> 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.
> ..
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 14/09/14 08:57 PM, Rich Freeman wrote:
> 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 14/09/14 07:21 PM, Patrick Lauer wrote:
> 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"?
>>>
>>> I
On Mon, Sep 15, 2014 at 11:26:47PM +1200, Kent Fredric wrote:
> None of these are impossible things, but they're much more complex than
> "just make a dodgy commit and get somebody to pull it".
Much more simple would be to make a dodgy commit by one of the devs. Why
use users for that, if "the bad
On 15 September 2014 22:10, Jauhien Piatlicki wrote:
> So signing of git commits does not guarantee enough security (taking
> that SHA1 is weak and can be broken), right? Could we than just use
> usual (not thin) manifests?
>
However, the attackability of SHA1 may be entirely immaterial, because
Hi,
On 09/15/2014 01:37 AM, Kent Fredric wrote:
> 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 com
Dnia 2014-09-15, o godz. 07:21:35
Patrick Lauer napisał(a):
> 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 sa
Dnia 2014-09-14, o godz. 21:30:36
Tim Harder napisał(a):
> 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 p
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
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
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
> "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 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
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
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: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 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
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
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
74 matches
Mail list logo
