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 requests
hanging over there for months and even years. Stab
On Sun, Jul 5, 2015 at 11:31 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> C Bergström posted on Sun, 05 Jul 2015 01:17:41 +0700 as excerpted:
>
>> I super don't like "merge" workflows.
>> 1) "merge commits" are confusing at best and normal tools don't display
>> and work with them as you'd always exp
C Bergström posted on Sun, 05 Jul 2015 01:17:41 +0700 as excerpted:
> I super don't like "merge" workflows.
> 1) "merge commits" are confusing at best and normal tools don't display
> and work with them as you'd always expect
git log --graph, as others have mentioned.
Works fine, at the console,
On Sun, Jul 5, 2015 at 6:54 AM, Peter Stuge wrote:
> C Bergström wrote:
>> 3) Ever tried to make a patch of the *actual* merge commit? Can one of
>> the advocates of merge show me the git command to do that? (Sure you
>> can diff between 2 commits, but the "merge" commit likes to avoid
>> being s
On Sat, Jul 4, 2015 at 2:36 PM, Peter Stuge wrote:
> C Bergström wrote:
>
>> 2) merge commits lead to multiple parents, which breaks a clean and
>> simple to follow linear history
>
> This is either a bug or a feature depending on whether development
> was actually linear. Sometimes it is, but som
C Bergström wrote:
> 1) Rebase doesn't obscure history,
That's plain wrong. Rebasing changes the parent of your commit. That
means that others can no longer see the history of your commit,
specifically its original parent. Sometimes the parent is irrelevant,
sometimes it is critical.
> (Unless y
On 07/04/2015 09:23 PM, C Bergström wrote:
> On Sun, Jul 5, 2015 at 1:56 AM, hasufell wrote:
>>
>> Forcing a rebase-only workflow on developers will increase the amount of
>> bad commits. Because non-trivial conflicts in rebases are difficult to
>> resolve, since you fix conflicts for _every_ comm
On 07/04/2015 01:33 PM, Zac Medico wrote:
> On 07/04/2015 01:24 PM, William Hubbs wrote:
>> What am I missing?
>
> You need to recognize that "build-time for package A" is not the same as
> "build-time for package B". When you build go-tools, you can't rely on
> the build-time dependencies of go-n
On Sun, Jul 5, 2015 at 3:33 AM, Alon Bar-Lev wrote:
> On 4 July 2015 at 23:28, Alexandre Rostovtsev wrote:
>>
>> On Sun, 2015-07-05 at 02:16 +0700, C Bergström wrote:
>> > 2) I don't understand your comment about signatures.
>>
>> Gpg commit signatures [1] which are a requirement for any gentoo g
On 07/04/2015 01:24 PM, William Hubbs wrote:
> On Sat, Jul 04, 2015 at 12:43:37PM -0700, Zac Medico wrote:
>> On 07/04/2015 12:32 PM, William Hubbs wrote:
>>> On Sat, Jul 04, 2015 at 12:19:28PM -0700, Zac Medico wrote:
On 06/30/2015 03:08 PM, William Hubbs wrote:
> The source code is wher
On 4 July 2015 at 23:28, Alexandre Rostovtsev wrote:
>
> On Sun, 2015-07-05 at 02:16 +0700, C Bergström wrote:
> > 2) I don't understand your comment about signatures.
>
> Gpg commit signatures [1] which are a requirement for any gentoo git
> workflow. Rebasing breaks the author's signature afaict
On Sun, 2015-07-05 at 02:16 +0700, C Bergström wrote:
> 2) I don't understand your comment about signatures.
Gpg commit signatures [1] which are a requirement for any gentoo git
workflow. Rebasing breaks the author's signature afaict, so the user
who is doing rebasing needs to re-sign the commit u
On Sat, Jul 04, 2015 at 12:43:37PM -0700, Zac Medico wrote:
> On 07/04/2015 12:32 PM, William Hubbs wrote:
> > On Sat, Jul 04, 2015 at 12:19:28PM -0700, Zac Medico wrote:
> >> On 06/30/2015 03:08 PM, William Hubbs wrote:
> >>> The source code is where the compatibility between versions of Go is,
>
On 07/04/2015 12:32 PM, William Hubbs wrote:
> On Sat, Jul 04, 2015 at 12:19:28PM -0700, Zac Medico wrote:
>> On 06/30/2015 03:08 PM, William Hubbs wrote:
>>> The source code is where the compatibility between versions of Go is,
>>> not the static objects, so what if, for third-party go packages,
On Sat, Jul 04, 2015 at 12:19:28PM -0700, Zac Medico wrote:
> On 06/30/2015 03:08 PM, William Hubbs wrote:
> > The source code is where the compatibility between versions of Go is,
> > not the static objects, so what if, for third-party go packages, we
> > skip installing the static objects?
> >
On Sun, Jul 5, 2015 at 1:56 AM, hasufell wrote:
> On 07/04/2015 08:17 PM, C Bergström wrote:
>> I realize that this is subject to lots of different opinions and that
>> my input doesn't carry much weight - At least I thought it's a topic
>> that should be brought up (again?)
>> -
>> To sta
On Sat, Jul 04, 2015 at 02:33:04PM -0400, NP-Hardass wrote:
>
>
> On July 4, 2015 2:17:41 PM EDT, "C Bergström"
> wrote:
> >I realize that this is subject to lots of different opinions and that
> >my input doesn't carry much weight - At least I thought it's a topic
> >that should be brought up
On 06/30/2015 03:08 PM, William Hubbs wrote:
> The source code is where the compatibility between versions of Go is,
> not the static objects, so what if, for third-party go packages, we
> skip installing the static objects?
>
> The only down side of this would be that there might be longer rebu
On Sun, Jul 5, 2015 at 1:42 AM, Rich Freeman wrote:
> On Sat, Jul 4, 2015 at 2:17 PM, C Bergström wrote:
>>
>> What I personally prefer is a rebase workflow.
>
> The recommendation is to rebase when practical.
>
> Rebasing makes the history look clean, but it sometimes does this by
> obscuring th
On 07/04/2015 08:17 PM, C Bergström wrote:
> I realize that this is subject to lots of different opinions and that
> my input doesn't carry much weight - At least I thought it's a topic
> that should be brought up (again?)
> -
> To start I hate git.. I have used it for years now and the
On Sat, Jul 4, 2015 at 2:17 PM, C Bergström wrote:
>
> What I personally prefer is a rebase workflow.
The recommendation is to rebase when practical.
Rebasing makes the history look clean, but it sometimes does this by
obscuring the real history. It also discards original author commits
with th
C Bergström wrote:
> To start I hate git.. I have used it for years now and the
> multitude of ways that are possible to accomplish nearly the same
> thing are *annoying* at best..
I'd be interested to hear a couple of examples of what you mean,
perhaps in a private mail. Tack på förhand. :)
On July 4, 2015 2:17:41 PM EDT, "C Bergström" wrote:
>I realize that this is subject to lots of different opinions and that
>my input doesn't carry much weight - At least I thought it's a topic
>that should be brought up (again?)
>-
>To start I hate git.. I have used it for years now
NP-Hardass wrote:
> >> or do they typically restrict review to a certain class of users?
> >
> >Hm, why would that end up happening? I'm not saying it can't, just
> >that I don't understand why it would. What do you have in mind?
>
> Well, it was just proposed earlier in the thread that it could b
I realize that this is subject to lots of different opinions and that
my input doesn't carry much weight - At least I thought it's a topic
that should be brought up (again?)
-
To start I hate git.. I have used it for years now and the
multitude of ways that are possible to accomplish ne
On July 4, 2015 1:49:20 PM EDT, Peter Stuge wrote:
>
>NP-Hardass wrote:
>> I am unfamiliar with how other big projects that use code review
>> systems. Do they generally make (almost) everyone participate,
>
>In coreboot, which admittedly isn't such a big project, my impression
>is that the int
William Hubbs wrote:
> If we do add a code review system, it should be fully accessible from
> the command line. Pybugz is almost there for bugzilla; the only thing it
> lacks is the ability to reply to specific comments.
Gerrit is also almost there, it has an ssh interface which is very
usable fo
I am unfamiliar with how other big projects that use code review systems. Do
they generally make (almost) everyone participate, or do they typically
restrict review to a certain class of users?
--
NP-Hardass
On July 4, 2015 4:14:14 AM EDT, "Manuel Rüger" wrote:
>On 03.07.2015 22:22, Robin H. J
On Sat, Jul 04, 2015 at 10:14:14AM +0200, Manuel Rüger wrote:
> On 03.07.2015 22:22, Robin H. Johnson wrote:
> > (Breaking the thread, because I believe this topic needs further
> > discussion).
> >
> > On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote:
> >> Are there still any plans to
On 03.07.2015 22:22, Robin H. Johnson wrote:
> (Breaking the thread, because I believe this topic needs further
> discussion).
>
> On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote:
>> Are there still any plans to use a code review system like gerrit that
>> will avoid merges, rebases e
30 matches
Mail list logo
