From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Jonathan Corbet <corbet(at)lwn(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: antisocial things you can do in git (but not CVS) |
Date: | 2010-07-21 19:34:06 |
Message-ID: | 1279740746-sup-1225@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2010-07-21 19:37:32 | Re: documentation for committing with git |
Previous Message | Alvaro Herrera | 2010-07-21 19:31:11 | Re: documentation for committing with git |