On Mon, 2009-09-14 at 22:50 -0700, Junio C Hamano wrote: > You might not see a "policy" in your approach, but it makes some troubling > hardcoded policy decisions. Here are a few examples of what your patch > decides, and makes it harder for other people to build on (rather, "around): > > - We support only interactive validation (confirmation). If you want to > have an unattended validation scheme, there is no way to enhance the > mechanism this patch adds to do so. You instead need to add yet > another command line option and hook into the same place as this patch > touches. It seems like the bulk of any patch is going to be creating a clean position in the code to do confirmation. > - We assume "git push" is run from terminal, and the only kind of > interactive validation we support is via typed confirmation from a line > terminal "[Y/n]?" If you want to run "git push" from a GUI frontend > and have the user interact with a dialog window popped up separately, > you are also out of luck. That's an interesting situation to consider. How do you see a pre-push hook being used for that? > - We assume it is good enough to have various built-in presentations of > supporting information while asking for confirmations; there is no way > for casual end users to customize and enhance it. A shell script that duplicates the display logic from transport.c while interleaving nicely abbreviated bits of log will be on the complex side. Is forking and modifying such a script going to be approachable for casual end users? - 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