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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
