William Hubbs wrote:
I think I understand what he's asking for...
I think he is asking the question, What changed in commit hash.
If you use the hash of a merge commit with git show, you get nothing,
so the merge commit is useless in terms of following changes.
I have explained why merge
On 07/05/2015 08:05 AM, Andrew Savchenko wrote:
On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote:
It's important that the review flow is well-understood and efficient.
This is impossible in our case due to the lack of manpower.
We already have a lot of bugs, patches, stabilization
On Mon, 06 Jul 2015 07:25:03 +0800
Patrick Lauer patr...@gentoo.org wrote:
On Sunday 05 July 2015 13:46:10 William Hubbs wrote:
On Sun, Jul 05, 2015 at 09:05:59AM +0300, Andrew Savchenko wrote:
On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote:
It's important that the review flow is
On Mon, 06 Jul 2015 19:34:05 +0200
hasufell hasuf...@gentoo.org wrote:
On 07/06/2015 07:27 PM, Ciaran McCreesh wrote:
On Mon, 06 Jul 2015 13:04:35 -0400
Michael Orlitzky m...@gentoo.org wrote:
I would love my commits to be reviewed, but I usually don't feel
like reviewing anyone else's.
On 07/06/2015 07:27 PM, Ciaran McCreesh wrote:
On Mon, 06 Jul 2015 13:04:35 -0400
Michael Orlitzky m...@gentoo.org wrote:
I would love my commits to be reviewed, but I usually don't feel like
reviewing anyone else's. That's... not uncommon.
Well, you could at least get your commits reviewed
On Sat, Jul 4, 2015 at 11:05 PM, Andrew Savchenko birc...@gentoo.org
wrote:
On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote:
It's important that the review flow is well-understood and efficient.
This is impossible in our case due to the lack of manpower.
We already have a lot of bugs,
Alec Warner wrote:
Its difficult to make a large change like all commits require review,
particularly for long-time contributors who are expecting to move quickly.
I think it's a character flaw (maybe hubris due to lack of experience
and/or ignorance?) to lack the humility to say that I would
On 07/06/2015 12:42 PM, Peter Stuge wrote:
Alec Warner wrote:
Its difficult to make a large change like all commits require review,
particularly for long-time contributors who are expecting to move quickly.
I think it's a character flaw (maybe hubris due to lack of experience
and/or
hasufell wrote:
that said... I don't think it currently makes sense to enforce
a strict global review workflow.
For the record, neither do I, and I never proposed that it should
hold up starting to use Git.
//Peter
On Mon, 06 Jul 2015 13:04:35 -0400
Michael Orlitzky m...@gentoo.org wrote:
I would love my commits to be reviewed, but I usually don't feel like
reviewing anyone else's. That's... not uncommon.
Well, you could at least get your commits reviewed by an automated build
system that starts from a
On Mon, Jul 6, 2015 at 9:42 AM, Peter Stuge pe...@stuge.se wrote:
Alec Warner wrote:
Its difficult to make a large change like all commits require review,
particularly for long-time contributors who are expecting to move
quickly.
I think it's a character flaw (maybe hubris due to lack of
On Thu, 18 Jun 2015 23:32:27 +0200
Étienne Buira etienne.bu...@gmail.com wrote:
Hi, thank you for reviewing
On Wed, Jun 17, 2015 at 01:32:17PM -0700, Brian Dolbec wrote:
Be aware that I have not read over the diff very much yet.
On Wed, 17 Jun 2015 20:40:30 +0200
Étienne Buira
On 07/07/15 01:27, Ciaran McCreesh wrote:
On Mon, 06 Jul 2015 13:04:35 -0400
Michael Orlitzky m...@gentoo.org wrote:
I would love my commits to be reviewed, but I usually don't feel like
reviewing anyone else's. That's... not uncommon.
Well, you could at least get your commits reviewed by
hasufell posted on Mon, 06 Jul 2015 19:20:14 +0200 as excerpted:
However, we should encourage gentoo-internal projects to become more
strict (and e.g. only have one or two pushers).
Just noting there's also the review required, but after getting it, go
ahead and push model. Same number of
On 7 July 2015 at 12:04, Patrick Lauer patr...@gentoo.org wrote:
So thanks for your intentional comedy, but let's be serious here.
It would be really nice if we could define some sort of variable in
the ebuild itself with a relative cost metric for the ebuilds install
time. It wouldn't need to
On 7 July 2015 at 01:48, Peter Stuge pe...@stuge.se wrote:
fact that a merge commit ideally does *not* contain any
modifications.
That's not /entirely/ true. The merge commit will have a new TREE
object which is a composite TREE object of both of its PARENT TREE
objects ( But all BLOBs in the
# Patrice Clement monsie...@gentoo.org (5 Jul 2015)
# SRC_URI unreachable. Upstream looks dead.
# Removal in 30 days. See bug #502994.
app-arch/dczip
# Patrice Clement monsie...@gentoo.org (5 Jul 2015)
# Package does not compile with recent JDKs (= jdk-1.8). More recent versions
# use Gradle
17 matches
Mail list logo
