Re: antisocial things you can do in git (but not CVS)

At 2010-07-20 14:34:20 -0400, robertmhaas(at)gmail(dot)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