Prev: [HACKERS] antisocial things you can do in git (but not CVS)
Next: [HACKERS] Finding slave WAL application time delay
From: Magnus Hagander on 21 Jul 2010 06:55
On Wed, Jul 21, 2010 at 12:46, Abhijit Menon-Sen <ams(a)toroid.org> wrote:
> At 2010-07-20 14:34:20 -0400, robertmhaas(a)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 branches
> that are tracking remote branches, but new local branches have to be
> pushed explicitly to create them on the remote.

Yeha, i agree this is probably not a big problem. Plus, if we
accidentally push a branch that shouldn't have been pushed, it can
easily be removed (as long as it's noticed before anybody relies on
it). To the suitable embarrassment of the committer who made the
incorrect push, which has a tendency to teach them not to do it next
time :-)


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

We are not changing the workflow, just the tool.

We may consider changing the workflow sometime in the future (but
don't bet on it), but we're definitely not changing both at the same
time.

This has been discussed many times before, both here on list and in
person on at least two instances of the pgcon developer meeting. This
is not the time to re-open that discussion.

--
�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 07:05
At 2010-07-21 12:55:55 +0200, magnus(a)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, create, view, or push
changes.

> This is not the time to re-open that discussion.

Sure. I apologise for bringing it up.

-- 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: Magnus Hagander on 21 Jul 2010 07:09
On Wed, Jul 21, 2010 at 13:05, Abhijit Menon-Sen <ams(a)toroid.org> wrote:
> At 2010-07-21 12:55:55 +0200, magnus(a)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, create, view, or push
> changes.

They makes it harder to track how the project has moved along for
people who don't really know about the concept.

I'm not sure, but I bet they may cause issues for those tracking the
project through git-cvs, or any other tool that doesn't deal with
nonlinear history.

--
�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: Jonathan Corbet on 21 Jul 2010 10:49
On Tue, 20 Jul 2010 14:34:20 -0400
Robert Haas <robertmhaas(a)gmail.com> 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 with git in the kernel community for some years now. Hopefully
it's helpful...

> 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
can get out just about anything you need, in any format.

IMHO, vandalizing the author field would be a mistake; it's your best way
of tracking where the patch came from and for ensuring credit in your
changelogs. Why throw away information?

> 2. Branch and tag management. In CVS, there are branches and tags in
> only one place: on the server. In git, you can have local branches
> and tags and remote branches and tags, and you can pull and push tags
> between servers. If I'm working on a git repository that has branches
> master, REL9_0_STABLE .. REL7_4_STABLE, inner_join_removal,
> numeric_2b, and temprelnames, I want to make sure that I don't
> accidentally push the last three of those to the authoritative
> server... but I do want to push all the others. Similarly I want to
> push only the corrects subset of tags (though that should be less of
> an issue, at least for me, as I don't usually create local tags). I'm
> not sure how to set this up, though.

Branch push policy can be tweaked in your local config. I'm less sure
about tags. It's worth noting that the kernel community does very little
with push in general - things are much more often pulled. That may not be
a workflow that's suitable for postgresql, though.

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

> 4. History rewriting. Under what circumstances, if any, are we OK
> with rebasing the master? For example, if we decide not to have merge
> commits, and somebody does a merge commit anyway, are we going to
> rebase to get rid of it?

A good general rule of thumb is to treat publicly-exposed history as
immutable. As soon as you start rebasing trees you create misery for
anybody working with those trees.

If you're really set on avoiding things like merges, there are ways to set
up scripts on the server to enforce policies.

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: Robert Haas on 21 Jul 2010 12:11
On Wed, Jul 21, 2010 at 10:49 AM, Jonathan Corbet <corbet(a)lwn.net> 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
> can get out just about anything you need, in any format.
>
> IMHO, vandalizing the author field would be a mistake; it's your best way
> of tracking where the patch came from and for ensuring credit in your
> changelogs. �Why throw away information?

If git had a place to store all the information we care about, that
would be fine, but it doesn't. Here's a recent attribution line I
used:

David Christensen. Reviewed by Steve Singer. Some further changes by me.

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 reviewers and then frobnicated
some more by the committer. I'm not sure it's possible to create a
system that can effectively store all the ways we give credit and
attribution, but a single author line is definitely not it. How much
do I have to change a patch before I would use my own name on the
author line rather than the patch author's? A single byte? A
non-whitespace change? More than 15% of the patch? And, oh by the
way, it's the committer who writes the commit message, not the patch
author, so at an *absolute minimum* that part of the commit object
isn't coming from the original author.

>> 2. Branch and tag management. �In CVS, there are branches and tags in
>> only one place: on the server. �In git, you can have local branches
>> and tags and remote branches and tags, and you can pull and push tags
>> between servers. �If I'm working on a git repository that has branches
>> master, REL9_0_STABLE .. REL7_4_STABLE, inner_join_removal,
>> numeric_2b, and temprelnames, I want to make sure that I don't
>> accidentally push the last three of those to the authoritative
>> server... but I do want to push all the others. �Similarly I want to
>> push only the corrects subset of tags (though that should be less of
>> an issue, at least for me, as I don't usually create local tags). �I'm
>> not sure how to set this up, though.
>
> Branch push policy can be tweaked in your local config. �I'm less sure
> about tags. �It's worth noting that the kernel community does very little
> with push in general - things are much more often pulled. �That may not be
> a workflow that's suitable for postgresql, though.

Seems like we've got this one worked out, per discussion upthread.

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

In any commit pattern, if I use bisect to pinpoint a regression
causing patch, I will find the commit that broke it. Whoever made
that particular commit is to blame. Full stop. I don't really care
where in the development of the patch that was eventually committed
the breakage happened, and I do not want to wade through 50 revs of
somebody's private development to find the particular place where they
made a thinko. I only care that their patch *as committed* is broken.
I don't think that non-linear history is an advantage in any
situation. It may be an unavoidable necessity if you have lots of
cross-merging between different repositories, but we don't, so for us
it's just clutter.

>> 4. History rewriting. �Under what circumstances, if any, are we OK
>> with rebasing the master? �For example, if we decide not to have merge
>> commits, and somebody does a merge commit anyway, are we going to
>> rebase to get rid of it?
>
> A good general rule of thumb is to treat publicly-exposed history as
> immutable. �As soon as you start rebasing trees you create misery for
> anybody working with those trees.
>
> If you're really set on avoiding things like merges, there are ways to set
> up scripts on the server to enforce policies.

Yep, Magnus coded it up today. It works great.

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