On Mon, May 07, 2012 at 03:10:07AM +0530, jaseem abid wrote: > On Mon, May 7, 2012 at 2:41 AM, Marcus Karlsson <mk@xxxxxxxxxx> wrote: > > There are many different reasons to use hooks. If everything that a hook > > could potentially need was passed to it as an argument then a lot of > > data would often end up unused. Better to supply as little as possible > > and only do more work when it's actually needed. > > That seems like a good reason not to pass all of the data, but isn't > the file names the most primary thing somebody can ask for? Yes, although keep in mind that the list of files does not necessarily fit onto the command line. We would have to feed it over stdin, and then you would have parsing/quoting issues. But you can get the exact same list from "git diff-index --cached --name-only", and it is exactly as hard to parse as stdin would be (and you can even decide to use "-z" to eliminate the quoting issues). So asking the user to call the plumbing command is more efficient and more flexible, but not actually any harder to use. > > I wouldn't go as deep as the plumbing, I think git status --porcelain > > should work just fine, the output is fairly easy to parse. > > I have always wondered why 'git status --porcelain' is giving a > 'plumbing' style output. Any docs on this somewhere? It is plumbing. The porcelain is meant to be "output suitable for reading by porcelains". Although I was the person who named "git status --porcelain", it is not a convention I think is particularly good; I named it to be consistent with other git commands which have a "--porcelain" mode. -Peff -- 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