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,
# Samuli Suominen ssuomi...@gentoo.org (01 Jun 2012)
# Fails to run with font issues wrt bug 418259
# Last release was back in 2003
# Removal in 30 days
x11-terms/cxterm
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.
It looks to me (from looking at eshowkw for python packages quite a
bit) that a great many packages aren't being keyworded on m68k. Would
it perhaps make sense to drop it from the set of stable arches (for
example, in the bugzilla selection thing, or in eshowkw)?
Cheers,
Dirkjan
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
William Hubbs posted on Thu, 31 May 2012 15:57:14 -0500 as excerpted:
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
The 01/06/12, Duncan wrote:
But it seems to me that overlays are the primary use case for commits to
public trees other than gentoo first. Otherwise, the whole rebase-vs-
merge problem goes away, because the first public commit is to the gentoo
tree. But especially with overlays (like
Hi,
I'm going to drop maintainership of app-misc/gcal due to lack of
interest. Does someone want to take it? Otherwise, it will fall back
to the shell-tools herd. Apart from one open stable request, there are
no open bugs.
Upstream situation for this package is a bit unclear: There's version
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
regenerating autotools in packages that have a lot of AC_CONFIG_SUBDIRS is
really slow due to the serialization of all the dirs (which really isn't
required). so i took some code that i merged into portage semi-recently
(which is based on work by Brian, although i'm not sure he wants to admit it)
On Friday 01 June 2012 07:37:52 Dirkjan Ochtman wrote:
It looks to me (from looking at eshowkw for python packages quite a
bit) that a great many packages aren't being keyworded on m68k. Would
it perhaps make sense to drop it from the set of stable arches (for
example, in the bugzilla
On Wednesday 23 May 2012 21:04:42 hasufell wrote:
# @FUNCTION: _iconins
# @DESCRIPTION:
# function for use in doicon and newicon
mark it @INTERNAL
if [[ -z $size ]] ; then
${size}
if [[ $function == doicon ]] ; then
${function}
if [[
example conversion of eatureconf
-mike
--- autotools.eclass
+++ autotools.eclass
@@ -16,7 +16,7 @@
if [[ ${___ECLASS_ONCE_AUTOTOOLS} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_AUTOTOOLS=recur -_+^+_- spank
-inherit libtool
+inherit libtool multiprocessing
# @ECLASS-VARIABLE:
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
On Tuesday 29 May 2012 15:00:15 Sergei Trofimovich wrote:
Nice to drop '|| die' and have REQUIRED_USE in games ebuilds
we've already got:
https://bugs.gentoo.org/336626
please collaborate there
-mike
signature.asc
Description: This is a digitally signed message part.
On 06/02/2012 12:49 AM, Mike Frysinger wrote:
On Wednesday 23 May 2012 21:04:42 hasufell wrote:
# @FUNCTION: _iconins
# @DESCRIPTION:
# function for use in doicon and newicon
mark it @INTERNAL
if [[ -z $size ]] ; then
${size}
if [[
The small typo in the comment section (fuqbar.svg - fuqbar.png) has
been fixed :P
On Fri, Jun 01, 2012 at 06:41:22PM -0400, Mike Frysinger wrote:
regenerating autotools in packages that have a lot of AC_CONFIG_SUBDIRS is
really slow due to the serialization of all the dirs (which really isn't
required). so i took some code that i merged into portage semi-recently
(which is
On Friday 01 June 2012 22:50:10 hasufell wrote:
On 06/02/2012 12:49 AM, Mike Frysinger wrote:
On Wednesday 23 May 2012 21:04:42 hasufell wrote:
# @FUNCTION: _iconins
# @DESCRIPTION:
# function for use in doicon and newicon
mark it @INTERNAL
what i meant here was:
# @FUNCTION:
On Saturday 02 June 2012 00:11:19 Brian Harring wrote:
On Fri, Jun 01, 2012 at 06:41:22PM -0400, Mike Frysinger wrote:
and put it into a new multiprocessing.eclass. this way people can
generically utilize this in their own eclasses/ebuilds.
it doesn't currently support nesting. not
47 matches
Mail list logo
