Prev: Add column if not exists (CINE)
Next: [HACKERS] need more ALTER TABLE guards for typed tables
From: Andrew Dunstan on 21 Jul 2010 15:59


Magnus Hagander wrote:
>> Personally, I have a strong opinion that for everything but totally trivial
>> patches, the committer should create a short-lived work branch where all the
>> work is done, and then do a squash merge back to the main branch, which is
>> then pushed. This pattern is not mentioned at all. In my experience, it is
>> essential, especially if you're working on more than one thing at a time, as
>> many people often are.
>>
>
> Uh, that's going to create an actual merge commit, no? Or you mean
> squash-merge-but-only-fast-forward?
>

Yes, exactly that. Something like:

git checkout -b myworkbranch
... work, test, commit, rinse, lather repeat ...
git checkout RELn_m_STABLE
git pull
git merge --squash myworkbranch
git push

> I *think* the docs is based off the pattern of the committer having
> two repositories - one for his own work, one for comitting, much like
> I assume all of us have today in cvs.
>
>

So then what? After you've done your work you'll still need to pull the
stuff somehow into your commit tree. I don't think this will buy you a
lot. I usually clone the whole CVS tree for non-trivial work, but I'm
not sure that's an ideal work pattern.

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: Robert Haas on 21 Jul 2010 16:47
On Wed, Jul 21, 2010 at 3:31 PM, Alvaro Herrera
<alvherre(a)commandprompt.com> wrote:
> Excerpts from Robert Haas's message of mi� jul 21 15:26:47 -0400 2010:
>
>> > So you're working on some back branch, and make a WIP commit so you can switch to master to make a quick commit. �Create a push on master. �Bare git push. �WIP commit gets pushed upstream. �Oops.
>>
>> Sure, oops, but I would never do that. �I'd stash it or put it on a
>> topic branch.
>
> Somebody else will. �Please remember you're writing docs that are not
> for yourself.

I don't have any problem suggesting it for those who may want it.

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

From: Robert Haas on 21 Jul 2010 17:03
On Wed, Jul 21, 2010 at 3:37 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote:
> Well, either we have a terminology problem or a statement of policy that I'm
> not sure I agree with, in point 2. �IMNSHO, what we need to forbid is
> commits that are not fast-forward commits, i.e. that do not have the current
> branch head as an ancestor, ideally as the immediate ancestor.

There are two separate questions here. One is whether an update to a
ref is fast-forward or history rewriting, and the other is whether it
is a merge commit or not. I don't believe that we want either
history-rewriting commits or merge commits to get pushed, but this
paragraph is about merge commits.

> Personally, I have a strong opinion that for everything but totally trivial
> patches, the committer should create a short-lived work branch where all the
> work is done, and then do a squash merge back to the main branch, which is
> then pushed. This pattern is not mentioned at all. In my experience, it is
> essential, especially if you're working on more than one thing at a time, as
> many people often are.

git merge --squash doesn't create a merge commit. Indeed, the whole
point is to create a commit which essentially encapsulates the same
diff as a merge commit but actually isn't one. From the man page:

Produce the working tree and index state as if a real merge
happened (except for the merge information), but do not actually
make a commit or move the HEAD, nor record $GIT_DIR/MERGE_HEAD to
cause the next git commit command to create a merge commit.

As for whether to discuss the use of git merge --squash, I could go
either way on that. Personally, my preferred workflow is to do 'git
rebase -i master' on a topic branch, squash all the commits, and then
switch to the master branch and do 'git merge otherbranch', resulting
in a fast-forward merge with no merge commit. But there are many
other ways to do it, including 'git merge --squash' and the
already-mentioned 'git commit -a'. I think there's a risk of this
turning into a complete tutorial on git, which might detract from its
primary purpose of explaining to committers how to get a basic,
working setup in place. But we can certainly add whatever you think
is important, or maybe some language indicating that 'git commit -a'
is just an EXAMPLE of how to create a commit...

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

From: Robert Haas on 21 Jul 2010 17:30
On Wed, Jul 21, 2010 at 5:03 PM, Robert Haas <robertmhaas(a)gmail.com> wrote:
> working setup in place. �But we can certainly add whatever you think
> is important, or maybe some language indicating that 'git commit -a'
> is just an EXAMPLE of how to create a commit...

I took a crack at this, as well as incorporating some of the other
suggestions that have been made. I'm sure it's not perfect, but maybe
it's an improvement...

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

From: Daniel Farina on 28 Jul 2010 19:22
On Wed, Jul 21, 2010 at 9:22 AM, Robert Haas <robertmhaas(a)gmail.com> wrote:
> On the other hand, if you have technical corrections, or if
> you have suggestions on how to do the same things better (rather than
> suggestions on what to do differently), that would be greatly
> appreciated.

Somewhere in that wiki page there is some musing about the size of
..git directories being somewhat dissatisfying when one feels compelled
to have multiple check-outs materialized.

There's a facility in git known as "alternates" that let you fetch
objects from some other pool. This is highly useful if you have the
same project checked out many times, either for personal use or on a
hosting server of some sort.

Because the object pool being referenced has no knowledge of other
repositories referencing it, garbage collection (should you be doing
things that generate garbage, such deleting branches and tags) of the
underlying pool can cause corruption in referencing repositories in
the case where they reference objects that have since been deleted.

This will never happen if the repository monotonically grows, as is
often the case for a 'authoritative' repository, such as the one at
git.postgresql.org that only has major branches and release tags that
will never go away. (save the rare case when fixing up after a cvs
race condition that has occurred a few times in the past).

In practice, one can just make a clean clone of a project for the
purposes of such an object pool and then let it sit for months or even
years, as the size of each subsequent .git, even for considerable
amounts of history, is marginal. Once in a while one can perform the
clean-up task of catching up the object pool, if they feel their .git
directories have gotten unacceptably large.

Here's a brief section about it on a git wiki:

https://git.wiki.kernel.org/index.php/GitFaq#How_to_share_objects_between_existing_repositories.3F

fdr

--
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: Add column if not exists (CINE)
Next: [HACKERS] need more ALTER TABLE guards for typed tables