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


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
>> locally, or because of a conflict between their local git repo's
>> master branch and origin/master. Can we forbid this?
>>
>
> 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 regression-causing patch, you'll wish you
> had that information there.
>
>

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 latter. The level of granularity of our current CVS
commits seems to us to be about right.

So when a committer pushes a patch it should add one fast-forward commit
to the tree. We want to be able to bisect between these commit objects,
but not between all the work product commits that led up to them. Of
course, developers, committers and testers can keep what they like
privately - we're only talking about what should go in the authoritative
repo.

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: Alvaro Herrera on 21 Jul 2010 15:34
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 regression-causing patch, you'll wish you
> > had that information there.
>

> So when a committer pushes a patch it should add one fast-forward commit
> to the tree. We want to be able to bisect between these commit objects,
> but not between all the work product commits that led up to them. Of
> course, developers, committers and testers can keep what they like
> privately - we're only talking about what should go in the authoritative
> repo.

I don't disagree that we're going to squash commits, but I don't believe
that developers will be able to keep "what they like privately". The
commit objects for the final patch are going to differ, if only because
they have different parents than the ones on the main branch.

Of course, they will be able to have a local branch with their local
patch, but to Git there will be no relationship between this branch and
the final, squashed patch in the authoritative repo.

--
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: Jonathan Corbet on 21 Jul 2010 16:18
On Wed, 21 Jul 2010 15:11:41 -0400
Andrew Dunstan <andrew(a)dunslane.net> 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 latter.

The thought makes me shudder...you lose the history, the reasons for
specific changes, the authorship of changes, and the ability of your
testers to pinpoint problematic changes. But...your project, your
decision...we'll keep using PostgreSQL regardless...:)

Thanks,

jon

--
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: Florian Weimer on 23 Jul 2010 05:28
* 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 difficult than that. Git does not record at all who
updated a particular branch to include a specific commit. This
operation does not leave any metadata behind. It is possible to write
a log file for audit purposes, but it's an out-of-band solution.

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

It would be possible to enforce that on the server side, but it would
interfere with merges.

> 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
> locally, or because of a conflict between their local git repo's
> master branch and origin/master. Can we forbid this?

It's possible to do this with some scripting on the server side.

--
Florian Weimer <fweimer(a)bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstra�e 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

--
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: Guillaume Lelarge on 24 Jul 2010 06:21
Le 21/07/2010 09:53, Dave Page a �crit :
> 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
>

It's one of the nice things with git. So, I'm eager to use it with the
pgAdmin repo.


--
Guillaume
http://www.postgresql.fr
http://dalibo.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

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