Anonymous Coward wrote:
> [ jfruh wrote:
> > "Larry Page revealed that he'd been suffering from a vocal cord
> > ailment that impaired his ability to speak for more than a year.
> > ...]
>
> Easy for him to say ...

Wait, wha?

Whoever does the merging into your "master" repository has the ability to make it look however they want. If your devs really dislike SHA1s, then request that the master repo start employing tags. It's not hard; after the repo admin merges in new code, he can tag it according to whatever convention you like.

This is way better than arcane auto-generated version numbers. Will this small workflow change, you can have "meaningful" version numbers.

My favorite thing about Git is this: it is possible to make an extremely consumer friendly code repository. As "master" repo admin, you have the power to reorder, tag, squash, fast-forward, not fast-forward, whatever, until everything is just right. Then you can push to the master repo and listen to the oohs and ahhs as your devs (and later, your maintenance programmers) easily grok the gitk graph.

We use git here in a corporate environment, and this problem absolutely does not happen, because:

1. Only special people have commit rights to the official repo
2. Those people always force a merge commit

Forcing a merge commit means using the --no-ff flag, which disallows any fast-forward merges. In this way, the person who is doing the merge into the official repository has a special merge commit with his name all over it.

This is not likely to be accidentally subverted; these official repo caretakers only use Git GUI (they're not really command-line types), and they use a git gui command I wrote for them that forces this behavior. Here it is, taken from .gitconfig:

[guitool "origin/pull merge request into local branch (Args = merge request number, Revision = local branch) "]
; fetch the latest from origin
; get off of the current local branch (in case it is the target)
; force the target local branch to match the origin branch it tracks
; checkout local target branch
; pull merge request into target local branch (and force merge commit)
cmd = git fetch origin && git checkout HEAD^ && git branch -f $REVISION origin/${REVISION} && git checkout $REVISION && git pull --no-ff origin refs/merge-requests/${ARGS}
argprompt = yes
revprompt = yes

If you're really paranoid about this, git offers pre-commit hooks, which could be used to reject any fast-forward merge into the master branch of the official repository.

At any rate, one would assume someone is ultimately responsible for checking official commits for their adherence to the no-fast-forward standard. If a bogus commit slips in it could always be redone, barring some ridiculous deployment system that rolls out production code instantly upon commit.

Tom Kyte makes an excellent case for this in chapter 1 of his book Expert Oracle Database Architecture. He says that treating the database like a black box (i.e. taking a database-agnostic approach) is the wrong way to go; that a lack of fundamental understanding about your db of choice will hurt your project. He goes on to give some great details starting here.

If the OP had mentioned Oracle, then I would have recommend the whole book. Nonetheless, the first chapter might prove a beneficial read.

Phil Lawrence