[rcthompson]

I can appreciate the sentiment that Git's internal model is straightforward enough that the UI is justified in exposing it. However, you also have to consider the perspective of someone who sees a cool project, decides to contribute code, sees that that the project code is in a git repo, and says, "Ok, I'll learn the basics of git so I can contribute to this cool project." It's not fair to expect such a person to learn the whole data model of git and how all the commands map to it just so they can contribute a 5-line patch in the project's native VCS. So I think there's definitely a strong argument in favor of providing a porcelain for Git that is independent of its plumbing, even if that porcelain is only capable of some basic operations.

[alinajaf]

In that particular case, I'd be inclined to send over the patch as a diff file, though I can see the point your making.

[rcthompson]

Even if you just want to send a patch, in order to get the patch you need to run diff on the original file and the changed one. If you've already edited your copy, then in order to get a copy of the original you're back to either figuring out basic git usage or hoping that the source repo provides a web interface from which you can download it. Either way, without knowing how to use git the prospective contributor could easily get discouraged and give up.