On Thu, 18 Sep 2014 17:04:55 +1200
Kent Fredric kentfred...@gmail.com 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:
On Thu, Sep 18, 2014 at 3:33 PM, Diamond diam...@hi-net.ru 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):
On Thu, 18 Sep 2014 16:00:59 -0400
Rich Freeman ri...@gentoo.org 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
Diamond wrote:
I stumbled over this problem when started to use git for packages.
Use git show -M to unstumble yourself.
//Peter
On 19 September 2014 07:33, Diamond diam...@hi-net.ru 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):
On Mon, 15 Sep 2014 14:51:56 -0400
Rich Freeman ri...@gentoo.org 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
On 18 September 2014 08:02, Diamond diam...@hi-net.ru 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
On Wed, Sep 17, 2014 at 4:02 PM, Diamond diam...@hi-net.ru wrote:
On Mon, 15 Sep 2014 14:51:56 -0400
Rich Freeman ri...@gentoo.org 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
On 18 September 2014 13:01, Rich Freeman ri...@gentoo.org 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
On 14/09/14 17:15, Kent Fredric wrote:
On 15 September 2014 02:40, Michał Górny mgo...@gentoo.org 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).
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 same
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 them in
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?
You have to merge
On Tue, Sep 16, 2014 at 1:07 PM, Luca Barbato lu_z...@gentoo.org 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
Dnia 2014-09-16, o godz. 19:05:18
Luca Barbato lu_z...@gentoo.org 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
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 clean?
Is that going to
Dnia 2014-09-14, o godz. 21:30:36
Tim Harder radher...@gentoo.org napisał(a):
On 2014-09-14 10:46, Michał Górny wrote:
Dnia 2014-09-14, o godz. 15:40:06
Davide Pesavento p...@gentoo.org napisał(a):
How long does the md5-cache regeneration process take? Are you sure it
will be able to
Dnia 2014-09-15, o godz. 07:21:35
Patrick Lauer patr...@gentoo.org 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
Hi,
On 09/15/2014 01:37 AM, Kent Fredric wrote:
On 15 September 2014 11:25, hasufell hasuf...@gentoo.org 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
On 15 September 2014 22:10, Jauhien Piatlicki jauh...@gentoo.org 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
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
-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?
Is that going to be
-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 patr...@gentoo.org
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
-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.
..
That
On Mon, Sep 15, 2014 at 1:42 PM, Ian Stakenvicius a...@gentoo.org 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
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
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 the
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
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 pull
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
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
overlay)?
On Sun, Sep 14, 2014 at 2:03 PM, Michał Górny mgo...@gentoo.org 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
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 signed
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 Manifests
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
On Sun, Sep 14, 2014 at 3:55 PM, hasufell hasuf...@gentoo.org 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
On 15 September 2014 00:03, Michał Górny mgo...@gentoo.org 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
Dnia 2014-09-14, o godz. 15:09:25
Jauhien Piatlicki jauh...@gentoo.org 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
Dnia 2014-09-14, o godz. 15:40:06
Davide Pesavento p...@gentoo.org napisał(a):
On Sun, Sep 14, 2014 at 2:03 PM, Michał Górny mgo...@gentoo.org wrote:
We have main developer repo where developers work commit and are
relatively happy. For every push into developer repo, automated magic
Dnia 2014-09-14, o godz. 15:23:24
Jauhien Piatlicki jauh...@gentoo.org 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
On 15 September 2014 02:40, Michał Górny mgo...@gentoo.org 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
On Sunday 14 September 2014 15:40:06 Davide Pesavento wrote:
On Sun, Sep 14, 2014 at 2:03 PM, Michał Górny mgo...@gentoo.org 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
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 the
Dnia 2014-09-15, o godz. 03:15:14
Kent Fredric kentfred...@gmail.com napisał(a):
On 15 September 2014 02:40, Michał Górny mgo...@gentoo.org wrote:
However, I'm wondering if it would be possible to restrict people from
accidentally committing straight into github (e.g. merging pull
On Sun, Sep 14, 2014 at 11:42 AM, hasufell hasuf...@gentoo.org 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
MG == Michał Górny mgo...@gentoo.org 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
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 change all
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 from
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
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) Have somebody
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.
Solutions:
- A) Have
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 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,
On Sun, Sep 14, 2014 at 6:56 PM, hasufell hasuf...@gentoo.org 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
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 original commits
On 15 September 2014 10:56, hasufell hasuf...@gentoo.org 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
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 case of a push
On 15 September 2014 11:15, W. Trevor King wk...@tremily.us 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
Rich Freeman:
On Sun, Sep 14, 2014 at 6:56 PM, hasufell hasuf...@gentoo.org 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
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
On 15 September 2014 11:21, Patrick Lauer patr...@gentoo.org 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,
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 signature
On Monday 15 September 2014 11:27:34 Kent Fredric wrote:
On 15 September 2014 11:21, Patrick Lauer patr...@gentoo.org 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
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 rebase anyway in case
On 15 September 2014 11:25, hasufell hasuf...@gentoo.org 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,
Patrick Lauer:
On Monday 15 September 2014 11:27:34 Kent Fredric wrote:
On 15 September 2014 11:21, Patrick Lauer patr...@gentoo.org 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
On Sun, Sep 14, 2014 at 7:21 PM, Patrick Lauer patr...@gentoo.org 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
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 -
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
On 15 September 2014 13:06, Peter Stuge pe...@stuge.se 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
On 2014-09-14 10:46, Michał Górny wrote:
Dnia 2014-09-14, o godz. 15:40:06
Davide Pesavento p...@gentoo.org 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
On 15 September 2014 13:30, Tim Harder radher...@gentoo.org 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
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
73 matches
Mail list logo
