On Sat, 2010-07-24 at 13:48 -0400, Andrew Dunstan wrote:
>
> Yeah. Also, please bear in mind that our explicit aim here is to make
> this change with a minimal disruption to existing work flows. So to all
> those people who want to say "Look, you can now do all these cool
> things" my answer i
Peter Eisentraut wrote:
On lör, 2010-07-24 at 07:02 -0700, Ron Mayer wrote:
Instead of squashing every patch into a single commit, what if it got
squashed into a perhaps 3 separate commits -- one as submitted, one
as reviewed, and one as re-written by the committer. History stays
linear; a
On lör, 2010-07-24 at 07:02 -0700, Ron Mayer wrote:
> Instead of squashing every patch into a single commit, what if it got
> squashed into a perhaps 3 separate commits -- one as submitted, one
> as reviewed, and one as re-written by the committer. History stays
> linear; and you keep the most rel
Robert Haas wrote:
>
> If git had a place to store all the information we care about, that
> would be fine...
>
> There's no "reviewer" header, and there's no concept that a patch
> might have come from the author (or perhaps multiple authors), but
> then have been adjusted by one or more reviewe
Le 21/07/2010 09:53, Dave Page a écrit :
> On Tue, Jul 20, 2010 at 8:12 PM, Peter Eisentraut wrote:
>>> My preference would be to stick to a style where we identify the
>>> committer using the author tag and note the patch author, reviewers,
>>> whether the committer made changes, etc. in the comm
* Robert Haas:
> 1. Inability to cleanly and easily (and programatically) identify who
> committed what. With CVS, the author of a revision is the person who
> committed it, period. With git, the author string can be set to
> anything the person typing 'git commit' feels like.
It's even more di
On Wed, 21 Jul 2010 15:11:41 -0400
Andrew Dunstan wrote:
> We have a clear idea of what should be part of the public history
> contained in the authoritative repo and what should be history that is
> private to the developer/tester/committer. We don't want to pollute the
> former with the latt
Excerpts from Andrew Dunstan's message of mié jul 21 15:11:41 -0400 2010:
>
> Jonathan Corbet wrote:
> > That seems like a terrible idea to me - why would you destroy history?
> > Obviously I've missed a discussion here. But, the first time somebody
> > wants to use bisect to pinpoint a regressi
Jonathan Corbet wrote:
3. Merge commits. I believe that we have consensus that commits
should always be done as a "squash", so that the history of all of our
branches is linear. But it seems to me that someone could
accidentally push a merge commit, either because they forgot to squash
locall
On Wed, Jul 21, 2010 at 10:49 AM, Jonathan Corbet wrote:
>> 1. Inability to cleanly and easily (and programatically) identify who
>> committed what.
>
> No, git tracks committer information separately, and it's easily
> accessible. Dig into the grungy details of git-log and you'll see that you
>
On Tue, 20 Jul 2010 14:34:20 -0400
Robert Haas wrote:
> I have some concerns related to the upcoming conversion to git and how
> we're going to avoid having things get messy as people start using the
> new repository.
Here's a few responses from the point of view of somebody who has been
working
On Wed, Jul 21, 2010 at 13:05, Abhijit Menon-Sen wrote:
> At 2010-07-21 12:55:55 +0200, mag...@hagander.net wrote:
>>
>> We are not changing the workflow, just the tool.
>
> OK, but I don't see why accidental merge commits need to be considered
> antisocial, and banned or rebased away. Who cares i
At 2010-07-21 12:55:55 +0200, mag...@hagander.net wrote:
>
> We are not changing the workflow, just the tool.
OK, but I don't see why accidental merge commits need to be considered
antisocial, and banned or rebased away. Who cares if they exist? They
don't change anything you need to do to pull, c
On Wed, Jul 21, 2010 at 12:46, Abhijit Menon-Sen wrote:
> At 2010-07-20 14:34:20 -0400, robertmh...@gmail.com wrote:
>> I want to make sure that I don't accidentally push the last three of
>> those to the authoritative server...
>
> By default (at least with a recent git), "git push" will push bra
On Wed, Jul 21, 2010 at 6:46 AM, Abhijit Menon-Sen wrote:
>> My preference would be to stick to a style where we identify the
>> committer using the author tag and note the patch author, reviewers,
>> whether the committer made changes, etc. in the commit message.
>
> An aside: as a patch author (
At 2010-07-20 14:34:20 -0400, robertmh...@gmail.com wrote:
>
> I think there is also a committer field, but that doesn't always
> appear and I'm not clear on how it works.
There is always a committer field, and it is set sensibly as long as the
committer has user.name and user.email set correctly
On Wed, Jul 21, 2010 at 02:28, Andrew Dunstan wrote:
>
>
> Robert Haas wrote:
>>
>> On Tue, Jul 20, 2010 at 3:12 PM, Peter Eisentraut wrote:
>>
>>>
>>> Well, I had looked forward to actually putting the real author into the
>>> author field.
>>>
>>
>> What if there's more than one? What if you m
On Tue, Jul 20, 2010 at 8:12 PM, Peter Eisentraut wrote:
>> My preference would be to stick to a style where we identify the
>> committer using the author tag and note the patch author, reviewers,
>> whether the committer made changes, etc. in the commit message. A
>> single author field doesn't
Robert Haas wrote:
On Tue, Jul 20, 2010 at 3:12 PM, Peter Eisentraut wrote:
Well, I had looked forward to actually putting the real author into the
author field.
What if there's more than one? What if you make changes yourself?
How will you credit the reviewer?
I think our cu
Robert Haas wrote:
I have some concerns related to the upcoming conversion to git and how
we're going to avoid having things get messy as people start using the
new repository. git has a lot more flexibility and power than CVS,
and I'm worried that it would be easy, even accidentally, to screw
On Tue, Jul 20, 2010 at 3:12 PM, Peter Eisentraut wrote:
> Well, I had looked forward to actually putting the real author into the
> author field.
What if there's more than one? What if you make changes yourself?
How will you credit the reviewer?
--
Robert Haas
EnterpriseDB: http://www.enterpr
On Tue, Jul 20, 2010 at 2:42 PM, Magnus Hagander wrote:
> On Tue, Jul 20, 2010 at 20:34, Robert Haas wrote:
>> I have some concerns related to the upcoming conversion to git and how
>> we're going to avoid having things get messy as people start using the
>> new repository. git has a lot more fl
On tis, 2010-07-20 at 14:34 -0400, Robert Haas wrote:
> Right now, it's easy to find all the commits by a particular
> committer, and it's easy to see who committed a particular patch, and
> the number of distinct committers is pretty small. I'd hate to give
> that up.
>
> git log | grep '^Author
On Tue, Jul 20, 2010 at 20:34, Robert Haas wrote:
> I have some concerns related to the upcoming conversion to git and how
> we're going to avoid having things get messy as people start using the
> new repository. git has a lot more flexibility and power than CVS,
> and I'm worried that it would
I have some concerns related to the upcoming conversion to git and how
we're going to avoid having things get messy as people start using the
new repository. git has a lot more flexibility and power than CVS,
and I'm worried that it would be easy, even accidentally, to screw up
our history.
1. In
25 matches
Mail list logo
