On Fri, Dec 02, 2011 at 09:32:50AM +1000, Peter Williams wrote: > Yes, I think your right. For most of my purposes, I think that it's > irrelevant whether a change is staged or not and the choices that I > offer allow the user to do what he thinks is right for a file with > changes that are staged but uncommitted. For me to automatically do > something based on whether the file was staged for a commit would be > a mistake as I would be reducing the user's options. > > However, the distinction might be worth making in the file tree > display to remind the user what's staged and what's not? I'd personally start with ignoring the distinction, and then wait for some enterprising user to suggest how it would be marked. That takes the burden off of you for guessing what representation would be best. > As an aside, I found it easier to delve into git's innards to find > out how to implement git binary patches than I did finding out how to > do things from the CLI :-). Heh. I think that is because the CLI is written by people (myself included) who want it to give them access to git's innards. ;) > >In your case, I think "status" is the most convenient level of > >abstraction for you, because you are interesting in looking at > >differences to both the index and HEAD (i.e., the prior commit). But if > >you find as you implement that want more flexibility, you can switch to > >using the lower-level commands yourself. > > I'll investigate this approach. How easy is it to distinguish low > level commands from high level commands? git(1) has a list of "porcelain" and "plumbing" commands. If you are scripting, you generally want to stick with plumbing commands, lower-level whose output and behavior remains stable across releases. However, some porcelain commands offer a "plumbing" mode (despite the name, the "--porcelain" flag to some commands is what you want; it is about offering parseable output that a custom porcelain could use. In git lingo, your interface is one such porcelain). -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