On Sat, Jun 2, 2012 at 12:04 AM, Robin H. Johnson robb...@gentoo.org wrote:
please look up git-bundle before suggesting things like tarballs of
repos/checkouts.
Looks useful. Wasn't aware that a bundle was something other than a tarball.
We'll probably need to spell out the preferred process
On Sat, Jun 2, 2012 at 12:59 PM, Rich Freeman ri...@gentoo.org wrote:
Looks useful. Wasn't aware that a bundle was something other than a tarball.
We'll probably need to spell out the preferred process in the docs,
and reference it frequently in communications. Otherwise you'll get
quite a
On Sat, Jun 2, 2012 at 8:03 AM, Dirkjan Ochtman d...@gentoo.org wrote:
On Sat, Jun 2, 2012 at 12:59 PM, Rich Freeman ri...@gentoo.org wrote:
It appears that devs will have to add the remote for the live
repository after they've cloned the bundle - otherwise they'll just
keep pulling from the
On Thu, May 31, 2012 at 6:49 PM, Robin H. Johnson robb...@gentoo.org wrote:
Discussion on merge policy. Originally I thought we would disallow merge
commits, so that we would get a cleaner history. However, it turns out that if
the repo ends up being pushed to different places with slightly
On 1 June 2012 20:16, Dirkjan Ochtman d...@gentoo.org wrote:
Can you elaborate on why the cleaner history a no-merge policy
enforces is a good thing? I actually think that seeing merge commits
might clarify the history; it can be valuable to see that some mistake
was made in a merge instead,
On Fri, Jun 1, 2012 at 12:05 AM, Michał Górny mgo...@gentoo.org wrote:
Yes, it isn't but such kind of work flow was presented in the message I
replied to.
Yup, I wasn't aware that when rebasing you have the option to squash
commits or not. They all get rewritten as if they were applied to the
On Fri, Jun 1, 2012 at 12:55 AM, Kent Fredric kentfred...@gmail.com wrote:
Hmm, thats annoying. Almost makes me wish it was the trees that were
signed, not the commits.
I think it is the tree that is signed, but that changes too.
Rebasing re-applies the same diff to the new head to give you a
On 1 June 2012 22:54, Rich Freeman ri...@gentoo.org wrote:
On Fri, Jun 1, 2012 at 12:55 AM, Kent Fredric kentfred...@gmail.com wrote:
Hmm, thats annoying. Almost makes me wish it was the trees that were
signed, not the commits.
I think it is the tree that is signed, but that changes too.
On Fri, 1 Jun 2012 23:23:34 +1200
Kent Fredric kentfred...@gmail.com wrote:
On 1 June 2012 22:54, Rich Freeman ri...@gentoo.org wrote:
Rebasing re-applies the same diff to the new head to give you a new
set of commits. When you apply the same diff to a different parent
you end up with a
On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric kentfred...@gmail.com wrote:
Nope, at least not as far as I can tell, and I just implemented commit
signature verification _
I've been trying to find an example of a signed commit, but can't find
one anywhere, so it is hard to tell what it is doing
Hi!
Check kde overlay ;) we used signed commits here
Rich Freeman писал 2012-06-01 16:42:
On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric kentfred...@gmail.com
wrote:
Nope, at least not as far as I can tell, and I just implemented
commit
signature verification _
I've been trying to find an
On 2 June 2012 00:42, Rich Freeman ri...@gentoo.org wrote:
On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric kentfred...@gmail.com wrote:
Nope, at least not as far as I can tell, and I just implemented commit
signature verification _
I've been trying to find an example of a signed commit, but
The purpose of overlays is to have ebuilds maintained outside of the
official Gentoo portage. Importing a ebuild from an overlay whether it
uses Git or not means importing the ebuild(s). In the Git context, it
means the Gentoo maintainer has to make an import commit the same way
it would be
git cat-file -p $sha is as close as you can get to commit objects
without needing to write your own decompressing wrapper. But it gives
the same results.
Now, does the signed data also contain the parent sha?
If yes, our discussion about rebasing is moot, because a rebase will in every
case
On 2 June 2012 03:12, Andreas K. Huettel dilfri...@gentoo.org wrote:
git cat-file -p $sha is as close as you can get to commit objects
without needing to write your own decompressing wrapper. But it gives
the same results.
Now, does the signed data also contain the parent sha?
If yes, our
On Fri, Jun 1, 2012 at 11:12 AM, Andreas K. Huettel
dilfri...@gentoo.org wrote:
Now, does the signed data also contain the parent sha?
So, I was working on a lengthy email which now would be fairly
repetitive of what Kent posted.
Suffice it to say I managed to rip out a commit from the kde
On 2 June 2012 03:12, Andreas K. Huettel dilfri...@gentoo.org wrote:
git cat-file -p $sha is as close as you can get to commit objects
without needing to write your own decompressing wrapper. But it gives
the same results.
Now, does the signed data also contain the parent sha?
If
On Sat, 2 Jun 2012 03:25:43 +1200
Kent Fredric kentfred...@gmail.com wrote:
On 2 June 2012 03:12, Andreas K. Huettel dilfri...@gentoo.org wrote:
git cat-file -p $sha is as close as you can get to commit objects
without needing to write your own decompressing wrapper. But it
gives the same
On Fri, Jun 1, 2012 at 9:25 AM, Nicolas Sebrecht nsebre...@piing.fr wrote:
So, like explained before your concern is clearly out of the current
discussion. Importing commit history from Overlays is not supported and
will probably never be. Gentoo doesn't forces (and doesn't want to)
overlays
On Fri, Jun 01, 2012 at 12:57:10PM +, Duncan wrote:
William Hubbs posted on Thu, 31 May 2012 15:57:14 -0500 as excerpted:
Overlays aren't really part of this discussion; those are independent
trees which we have no control over, so commiting changes from overlays
to the main tree is the
On Fri, Jun 1, 2012 at 11:36 AM, Andreas K. Huettel
dilfri...@gentoo.org wrote:
On 2 June 2012 03:12, Andreas K. Huettel dilfri...@gentoo.org wrote:
Yes. Which basically means, you *cannot* have both
a) rebase only merges
and
b) every commit must be signed
as policies.
I would say that
On 2 June 2012 03:39, Rich Freeman ri...@gentoo.org wrote:
On Fri, Jun 1, 2012 at 9:25 AM, Nicolas Sebrecht nsebre...@piing.fr wrote:
So, like explained before your concern is clearly out of the current
discussion. Importing commit history from Overlays is not supported and
will probably never
On Fri, Jun 1, 2012 at 5:53 PM, Rich Freeman ri...@gentoo.org wrote:
If you want the tree to be traceable to Gentoo devs, then rewriting
the signatures is probably a good thing.
I'd say that signing the merge commit is good enough. It says the
Gentoo dev who merged it has reviewed the changes
On 2 June 2012 03:53, Rich Freeman ri...@gentoo.org wrote:
git-rebase is just a shell script, that ultimately just calls
git-commit as far as I can see, which means that implementing
re-signing is just a matter of adding the appropriate parameters, or
use default configuration (assuming it
On Sat, Jun 02, 2012 at 03:56:43AM +1200, Kent Fredric wrote:
You can however merge dissimilar histories with no common parents if
you know what you're doing. It does warn you, but it still lets you do
it.
…
Yeah, selectively pulling in files with histories however is hard,
I've
On Fri, Jun 01, 2012 at 10:45:48AM -0500, William Hubbs wrote:
Overlays are completely separate repositories. There is nothing stopping
an overlay from using git right now even if the main tree isn't using
git. They just work in their git repositories until they are ready to
commit something
On Fri, Jun 01, 2012 at 11:53:52AM -0400, Rich Freeman wrote:
However, Kent did point out the rebase function doesn't actually apply
new signatures to the new old commits anyway, so you'd end up with
unsigned commits in the history.
Only in your local history. The push to the central repo would
On 2 June 2012 04:33, Robin H. Johnson robb...@gentoo.org wrote:
On Fri, Jun 01, 2012 at 10:45:48AM -0500, William Hubbs wrote:
Overlays are completely separate repositories. There is nothing stopping
an overlay from using git right now even if the main tree isn't using
git. They just work in
Only in your local history. The push to the central repo would only send
the commits in the active chain to your branch HEAD.
Any commits that are rebased, and then replicated somewhere after that
rebase, will be stripped of their signatures by the rebase process.
--
Kent
perl -e print
On Sat, Jun 02, 2012 at 04:56:33AM +1200, Kent Fredric wrote:
Only in your local history. The push to the central repo would only send
the commits in the active chain to your branch HEAD.
Any commits that are rebased, and then replicated somewhere after that
rebase, will be stripped of their
On Fri, Jun 1, 2012 at 12:33 PM, Robin H. Johnson robb...@gentoo.org wrote:
What about overlay repositories that elect to be a branch of the main
tree via git?
Do we call that forbidden usage?
I think that branches off of the main tree are mainly going to be
useful for more
On Fri, Jun 01, 2012 at 04:33:35PM +, Robin H. Johnson wrote:
On Fri, Jun 01, 2012 at 10:45:48AM -0500, William Hubbs wrote:
Overlays are completely separate repositories. There is nothing stopping
an overlay from using git right now even if the main tree isn't using
git. They just work
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/31/2012 02:04 PM, Aaron W. Swenson wrote:
The 6 hours it takes to clone the repo.
afaik it's 6 hours to transform the whole cvs history into a git repo.
Cloning the repo [1] takes 200seconds on 8cores (it's 2GB of data and
22 minutes of
WH == William Hubbs willi...@gentoo.org writes:
WH My big complaint about merge commits is if you do a git show hash on
WH a merge commit, you get nothing,
With current git and proper merge logs you get useful info.
The headers contain the hashes, so you can get the list of
commits
On Fri, Jun 1, 2012 at 4:49 PM, Michael Weber x...@gentoo.org wrote:
Cloning the repo [1] takes 200seconds on 8cores (it's 2GB of data and
22 minutes of 3.4GHz cpus).
As others have pointed out, probably the best way to bootstrap this is
to offer tarballs of a shallow repository and a full
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/30/2012 04:31 PM, Dirkjan Ochtman wrote:
On Wed, May 30, 2012 at 8:33 PM, Robin H. Johnson
robb...@gentoo.org wrote:
No, the last mock conversion is still live and updating fairly
often:
Aaron W. Swenson wrote:
what *you* think are hard blockers for the migration?
The 6 hours it takes to clone the repo.
Maybe clone on server and distribute the initial repo as tarball.
//Peter
On Thu, May 31, 2012 at 2:04 PM, Aaron W. Swenson titanof...@gentoo.org wrote:
The 6 hours it takes to clone the repo.
IIRC someone already proposed that the packed repo could be offered
via normal download (or even BitTorrent).
Cheers,
Dirkjan
On Wed, May 30, 2012 at 10:31:06PM +0200, Dirkjan Ochtman wrote:
On Wed, May 30, 2012 at 8:33 PM, Robin H. Johnson robb...@gentoo.org wrote:
No, the last mock conversion is still live and updating fairly often:
http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary
Since
On Thu, May 31, 2012 at 08:04:10AM -0400, Aaron W. Swenson wrote:
On 05/30/2012 04:31 PM, Dirkjan Ochtman wrote:
On Wed, May 30, 2012 at 8:33 PM, Robin H. Johnson
robb...@gentoo.org wrote:
No, the last mock conversion is still live and updating fairly
often:
On Thu, May 31, 2012 at 12:49 PM, Robin H. Johnson robb...@gentoo.org wrote:
1.
Discussion on merge policy. Originally I thought we would disallow merge
commits, so that we would get a cleaner history. However, it turns out that if
the repo ends up being pushed to different places with
On Thu, May 31, 2012 at 01:48:29PM -0400, Rich Freeman wrote:
On Thu, May 31, 2012 at 12:49 PM, Robin H. Johnson robb...@gentoo.org wrote:
1.
Discussion on merge policy. Originally I thought we would disallow merge
commits, so that we would get a cleaner history. However, it turns out that
On Thu, May 31, 2012 at 01:48:29PM -0400, Rich Freeman wrote:
On Thu, May 31, 2012 at 12:49 PM, Robin H. Johnson robb...@gentoo.org wrote:
1.
Discussion on merge policy. Originally I thought we would disallow merge
commits, so that we would get a cleaner history. However, it turns out that
On Thu, 31 May 2012 14:18:04 -0500
William Hubbs willi...@gentoo.org wrote:
Not sure I'm following, but I will be the first to admit that I'm a
git novice. Would this be aided by a convention, like only
committing to master on the gentoo official repository, and any
on-the-side work on
On Thu, May 31, 2012 at 3:13 PM, Robin H. Johnson robb...@gentoo.org wrote:
- You have a commit, that you want to put into the Gentoo tree.
- You have already pushed it to your github, signed
- It needs to be merged/rebased so that it applies on the Gentoo tree.
- If you force it to be a
On Thu, 31 May 2012 14:18:04 -0500
William Hubbs willi...@gentoo.org wrote:
On Thu, May 31, 2012 at 01:48:29PM -0400, Rich Freeman wrote:
On Thu, May 31, 2012 at 12:49 PM, Robin H. Johnson
robb...@gentoo.org wrote:
1.
Discussion on merge policy. Originally I thought we would
Michał Górny писал 2012-05-31 23:33:
On Thu, 31 May 2012 14:18:04 -0500
William Hubbs willi...@gentoo.org wrote:
On Thu, May 31, 2012 at 01:48:29PM -0400, Rich Freeman wrote:
On Thu, May 31, 2012 at 12:49 PM, Robin H. Johnson
robb...@gentoo.org wrote:
1.
Discussion on merge policy.
On Thu, May 31, 2012 at 07:13:42PM +, Robin H. Johnson wrote:
- You have a commit, that you want to put into the Gentoo tree.
- You have already pushed it to your github, signed
If I have a github tree, that would probably be because I didn't have
push access to the official tree, so
On Thu, May 31, 2012 at 3:33 PM, Michał Górny mgo...@gentoo.org wrote:
What would git signing work with rebased commits? Would all of them
have to be signed once again?
The whole point of rebasing is to throw away history (which is either
good or bad based on your perspective).
So, if 14 devs
On Thu, 31 May 2012 15:58:43 -0400
Rich Freeman ri...@gentoo.org wrote:
On Thu, May 31, 2012 at 3:33 PM, Michał Górny mgo...@gentoo.org
wrote:
What would git signing work with rebased commits? Would all of them
have to be signed once again?
The whole point of rebasing is to throw away
On 05/31/12 16:09, Michał Górny wrote:
On Thu, 31 May 2012 15:58:43 -0400
Rich Freeman ri...@gentoo.org wrote:
On Thu, May 31, 2012 at 3:33 PM, Michał Górny mgo...@gentoo.org
wrote:
What would git signing work with rebased commits? Would all of them
have to be signed once again?
The
On Thu, May 31, 2012 at 08:26:58PM +, Duncan wrote:
William Hubbs posted on Thu, 31 May 2012 14:54:50 -0500 as excerpted:
I don't know what's going to happen to all the overlays with the main
tree switch to git, but won't that break various overlay first
policies, say for the kde
On Thu, May 31, 2012 at 03:58:43PM -0400, Rich Freeman wrote:
On Thu, May 31, 2012 at 3:33 PM, Michał Górny mgo...@gentoo.org wrote:
What would git signing work with rebased commits? Would all of them
have to be signed once again?
The whole point of rebasing is to throw away history
On 1 June 2012 07:52, Alexey Shvetsov ale...@gentoo.org wrote:
What would git signing work with rebased commits? Would all of them
have to be signed once again?
Commits itsels still will be signed
Do you know how git does this? Do you have experience/information you
can cite as to that
On 1 June 2012 07:58, Rich Freeman ri...@gentoo.org wrote:
On Thu, May 31, 2012 at 3:33 PM, Michał Górny mgo...@gentoo.org wrote:
What would git signing work with rebased commits? Would all of them
have to be signed once again?
The whole point of rebasing is to throw away history (which is
On Thu, May 31, 2012 at 08:23:31PM +0100, Ciaran McCreesh wrote:
On Thu, 31 May 2012 14:18:04 -0500
William Hubbs willi...@gentoo.org wrote:
Not sure I'm following, but I will be the first to admit that I'm a
git novice. Would this be aided by a convention, like only
committing to
On 1 June 2012 08:26, Duncan 1i5t5.dun...@cox.net wrote:
William Hubbs posted on Thu, 31 May 2012 14:54:50 -0500 as excerpted:
Of course, if all the official overlays are converted to git branches of
the main tree... but won't they still require rebasing as they've already
been pushed? (This
On Thu, May 31, 2012 at 5:52 PM, Kent Fredric kentfred...@gmail.com wrote:
Just I haven't worked out what happens when the SHA1 of the 'parent'
header changes, which *will* change if the rebase is anything other
than a fast-forward.
If that SHA1 changes, the gpg signature will surely fail?
On Thu, 31 May 2012 17:04:30 -0500
William Hubbs willi...@gentoo.org wrote:
On Thu, May 31, 2012 at 08:23:31PM +0100, Ciaran McCreesh wrote:
On Thu, 31 May 2012 14:18:04 -0500
William Hubbs willi...@gentoo.org wrote:
Not sure I'm following, but I will be the first to admit that
I'm a
On Thu, 31 May 2012 16:27:48 -0400
Michael Orlitzky mich...@orlitzky.com wrote:
On 05/31/12 16:09, Michał Górny wrote:
On Thu, 31 May 2012 15:58:43 -0400
Rich Freeman ri...@gentoo.org wrote:
On Thu, May 31, 2012 at 3:33 PM, Michał Górny mgo...@gentoo.org
wrote:
What would git
On 1 June 2012 14:49, Rich Freeman ri...@gentoo.org wrote:
On Thu, May 31, 2012 at 5:52 PM, Kent Fredric kentfred...@gmail.com wrote:
Just I haven't worked out what happens when the SHA1 of the 'parent'
header changes, which *will* change if the rebase is anything other
than a fast-forward.
On Wed, May 30, 2012 at 11:38 AM, Duncan 1i5t5.dun...@cox.net wrote:
Of course, there's a much larger infra component to the git migration, so
either having that someone being an infra person, or at least having
someone from infra have the time and be willing to work closely with
them, is
On Wed, May 30, 2012 at 6:16 AM, Dirkjan Ochtman d...@gentoo.org wrote:
Yeah... this is why I was asking about access to infra to test the
conversion; so far, I haven't had any replies, though.
A mock conversion would probably help with creating
procedures/docs/etc as well. It is nice to say
Hi!
On Wed, 30 May 2012, Rich Freeman wrote:
On Wed, May 30, 2012 at 6:16 AM, Dirkjan Ochtman d...@gentoo.org wrote:
Yeah... this is why I was asking about access to infra to test the
conversion; so far, I haven't had any replies, though.
A mock conversion would probably help with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/30/2012 12:53 PM, Tobias Klausmann wrote:
Hi!
On Wed, 30 May 2012, Rich Freeman wrote:
On Wed, May 30, 2012 at 6:16 AM, Dirkjan Ochtman d...@gentoo.org
wrote:
Yeah... this is why I was asking about access to infra to test
the
On 30.05.2012 18:58, Aaron W. Swenson wrote:
On 05/30/2012 12:53 PM, Tobias Klausmann wrote:
Hi!
On Wed, 30 May 2012, Rich Freeman wrote:
On Wed, May 30, 2012 at 6:16 AM, Dirkjan Ochtman d...@gentoo.org
wrote:
Yeah... this is why I was asking about access to infra to test
the conversion;
On Wed, May 30, 2012 at 01:06:45PM +, Duncan wrote:
Of course, those previous trial runs are probably similarly dated, now,
so a new one's probably in order with the new perspective on those bug
priorities, etc, but at least getting the input of someone that was
involved with them
On Wed, May 30, 2012 at 8:33 PM, Robin H. Johnson robb...@gentoo.org wrote:
No, the last mock conversion is still live and updating fairly often:
http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary
Since you seem to know most about this project, can you give a short
On Thursday, May 24, 2012 06:33:53 AM Duncan wrote:
Dan Douglas posted on Thu, 24 May 2012 01:04:48 -0500 as excerpted:
On Thursday, May 24, 2012 07:56:58 AM Michał Górny wrote:
On Wed, 23 May 2012 16:14:53 -0500
Dan Douglas orm...@gmail.com wrote:
If not I will be leaving Gentoo for
2012/5/24 Dan Douglas orm...@gmail.com
On Thursday, May 24, 2012 06:33:53 AM Duncan wrote:
Dan Douglas posted on Thu, 24 May 2012 01:04:48 -0500 as excerpted:
On Thursday, May 24, 2012 07:56:58 AM Michał Górny wrote:
On Wed, 23 May 2012 16:14:53 -0500
Dan Douglas orm...@gmail.com
On Thu, May 24, 2012 at 1:43 PM, Duncan 1i5t5.dun...@cox.net wrote:
In that regard, git is nothing like for instance svn, where branches come
at a much higher cost, as does merging between them.
That's wrong. SVN branches are just about as cheap as git branches,
although merges used to be much
On Thu, 24 May 2012 14:05:50 +0200
Dirkjan Ochtman d...@gentoo.org wrote:
On Thu, May 24, 2012 at 1:43 PM, Duncan 1i5t5.dun...@cox.net wrote:
In that regard, git is nothing like for instance svn, where
branches come at a much higher cost, as does merging between them.
That's wrong. SVN
On 25 May 2012 00:05, Dirkjan Ochtman d...@gentoo.org wrote:
On Thu, May 24, 2012 at 1:43 PM, Duncan 1i5t5.dun...@cox.net wrote:
In that regard, git is nothing like for instance svn, where branches come
at a much higher cost, as does merging between them.
That's wrong. SVN branches are just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/24/2012 03:37 PM, Kent Fredric wrote:
Kent, this is of topic, stop it.
- --
- --
Gentoo Dev
http://xmw.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
74 matches
Mail list logo
