On Mon, 2009-09-14 at 17:46 -0700, Junio C Hamano wrote: > Owen Taylor <otaylor@xxxxxxxxxx> writes: > > > If I can figure out the rest of it, I'll look at adding a hook on top as > > a sweetener :-) > > Please don't. > > I seriously suggest you start from, and stick to, nothing but a hook. > > The pre-push codepath is conceptually very simple --- something needs to > inspect a list of <ref, old, new> and say yes or no. But what the users > want needs great customizability (e.g. Daniel's sign-off validation > example). It's the prime example of codepath that should have a hook and > no built-in policy logic. Let me back up on this a little bit. Is confirmation a general need? In the context of the kernel or git personal repository workflows, probably not. If you push something wrong, and discover it quickly, you can just push over it and nobody is wiser. But a large fraction of the projects listed on the front page of git-scm.com are using shared repositories. And with a shared repository, a messed up push is more of an issue: there may be notifications sent out over email or IRC, the repository may be configured with denyFastForward true, people may quickly pull your accidental push, etc. It's also a sticky point for first using git. The push syntax and behavior is a bit cryptic until you are used to it. Is it going to push all branches or just the one I'm on? Is 'git push --tags' a superset of 'git push'? etc. If the first repository you are pushing to is public and shared, heavy use of --dry-run at first is certainly advisable. But repeating with --dry-run and without is pretty awkward. How would the quality of use be as a hook? Probably good enough. The broad outlines are achievable anyways. There are some aspects of my patches that wouldn't be there. A few that come to mind: - The --show-subjects option applied to all displays of push references, not just for --confirm. - In the case of a successful push when the updates are exactly what was confirmed, outputting them again after the push is suppressed. How would ease of configuration be for a hook? > E.g. perhaps in $HOME/.gitconfig, you may want to allow > > [hook] > prePush = $HOME/.githooks/my-pre-push-hook > preCommit = $HOME/.githooks/my-pre-commit-hook This is certainly better than having to set it up per-repo, but if I wanted to tell GNOME contributors how to turn it on, I'd have to provide a gnome-contributor-git-setup.sh. Even if the hooks were shipped with git, there's not going to be a cross-distro path to the where they are installed. Maybe if a there was a "hook path" that included ~/.githooks and a system directory? Though: git-config --global hook.prePush git-pre-push-confirm could still overwrite something that they already have configured; it wouldn't be an "orthogonal tip" that you could find on a web page and apply blindly. Providing a gnome-contributor-git-setup.sh is generally an approach of last resort. I don't think there is anything unique or special about how we do we do git on gnome.org that makes it different from other shared-repository workflows. I'd like the knowledge that people get using Git with GNOME to carry over to other work they do with Git and vice-versa. - Owen -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html