Triangular workflows and some anecdotes from the trenches

Hi,

We ran into something at $dayjob the other day. The actual problem was a developer ended up amending a commit that had already been pushed. It happens occasionally and is usually recoverable with a simple rebase and is generally a learning experience. In this particular case however things were a bit more complicated.

We had (attempted to) setup a triangular workflow. The developers would fetch from a server that was closer to them but push to the central server that was at the other end of a WAN link. Our build system would update the local server after a successful build for all configurations. The problem was instead of setting branch.<name>.pushdefault we were setting remote.origin.pushurl. So now the warning in git-remote(1) comes back to bite us and a lot of head scratching ensues.

It appears that the triangular workflow support is under-documented (mentioned in a couple of release notes and gitrevisions). I'm not suggesting we would have done the right thing if the documentation existed but we would have had a chance. Once we get our setup sorted I'll try and send an update for gitworkflows.txt (unless someone else beats me to it). There are a few blog post around the Internet that I might be able to draw upon.

The subject of preventing modifying published history has come up on this list before. And in-fact it's relatively simple to implement as an alias

  git config alias.amend '!git merge-base --is-ancestor HEAD
@{upstream} || git commit --amend'

I'm just wondering if something more official can be added to git commit --amend (and probably git rebase).

Finally I was wondering if there is any way of detecting if remote.*.pushurl and remote.*.url point to the same repo, although I'm not sure when you'd do such verification.

Thanks, Chris