Prev: [HACKERS] antisocial things you can do in git (but not CVS)
Next: [HACKERS] Finding slave WAL application time delay
From: Andrew Dunstan on 20 Jul 2010 20:28


Robert Haas wrote:
> On Tue, Jul 20, 2010 at 3:12 PM, Peter Eisentraut <peter_e(a)gmx.net> 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 current practice is fine. Put it in the commit log.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Dave Page on 21 Jul 2010 03:53
On Tue, Jul 20, 2010 at 8:12 PM, Peter Eisentraut <peter_e(a)gmx.net> 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 feel like enough for our workflow, and
>> having a mix of authors and committers in the author field seems like
>> a mess.
>
> Well, I had looked forward to actually putting the real author into the
> author field.

I hadn't realised that was possible until Guillaume did so on his
first commit to the new pgAdmin GIT repo. It seems to work nicely:

http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commit;h=08e2826d90129bd4e4b3b7462bab682dd6a703e4

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Magnus Hagander on 21 Jul 2010 05:03
On Wed, Jul 21, 2010 at 02:28, Andrew Dunstan <andrew(a)dunslane.net> wrote:
>
>
> Robert Haas wrote:
>>
>> On Tue, Jul 20, 2010 at 3:12 PM, Peter Eisentraut <peter_e(a)gmx.net> 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 current practice is fine. Put it in the commit log.

If nothing else, I think this definitely falls under the "minimum
changes first" policy. Let's start by doing things exactly as we're
doing now. We can then consider changing this in the future, but let's
not change everything at once.


--
�Magnus Hagander
�Me: http://www.hagander.net/
�Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Abhijit Menon-Sen on 21 Jul 2010 06:46
At 2010-07-20 14:34:20 -0400, robertmhaas(a)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 with git-config. It
is not displayed by git-log by default, unless it is different from the
"author". (As PeterE showed, it's easy to get the list of committers.)

> 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 (and elsewhere, as a committer), it's nice
when the log shows the author rather than the committer. Will we really
have so many patches with multiple authors or other complications that
we can't set the author by default and fall back to explanations in the
commit message (e.g. "applied with changes") for more complicated cases?

> 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 branches
that are tracking remote branches, but new local branches have to be
pushed explicitly to create them on the remote.

So don't worry about that.

> 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.

I admit I haven't been paying as much attention as I should, but I did
not know there was such a consensus. If anyone could explain the
rationale, I would be grateful.

> But it seems to me that someone could
> accidentally push a merge commit […]
> Can we forbid this?

Yes, I suppose it's possible, but personally I think it would be a waste
of time to try to ban merge commits.

> 4. History rewriting. Under what circumstances, if any, are we OK
> with rebasing the master?

Please, let's never do that. The cure for pulling a rebased branch into
an existing clone may seem simple, but it's a huge pain in practice, and
it's never really worth it.

-- ams

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 21 Jul 2010 06:49
On Wed, Jul 21, 2010 at 6:46 AM, Abhijit Menon-Sen <ams(a)toroid.org> 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 (and elsewhere, as a committer), it's nice
> when the log shows the author rather than the committer. Will we really
> have so many patches with multiple authors or other complications that
> we can't set the author by default and fall back to explanations in the
> commit message (e.g. "applied with changes") for more complicated cases?

Tom Lane rewrites part of nearly every commit, and even I change maybe
30% of them.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: [HACKERS] antisocial things you can do in git (but not CVS)
Next: [HACKERS] Finding slave WAL application time delay