On Wed, Nov 30, 2011 at 12:17:22PM +1000, Peter Williams wrote:
> 1. presenting the file tree of the sources being patched in a way
> that makes sense to the user including the current status of files
> from the point of view of the underlying SCM (in this case, git), and
I'm not exactly sure what this means.
> 2. detecting files with uncommitted changes (from the SCM's point of
> view) when the user adds them to a patch (or pushes a patch that
> contains them) so that they may be alerted to the fact and offered
> the choice of absorbing the uncommitted changes into the patch (or
> not).
For this, you probably want "git diff-files --name-only", which will
show files with differences in the working tree. Keep in mind that git
has an "index" or "staging area", which means that you have three states
of content for a given path:
1. the state of the prior commit (i.e., HEAD)
2. the state that is marked to be committed when "git commit" is run
(i.e., the index)
3. the state in the working tree
You can compare the first two with "git diff-index", and the latter two
with "git diff-files". You can also use "git status --porcelain" to get
a machine-readable output that shows how the three states match up, with
one line per file.
> I've already implemented this interface for Mercurial (with which I
> am familiar) and looked at doing the same with git but had difficulty
> discovering the definitive mechanisms for obtaining the necessary
> data. So I'm soliciting your help in overcoming these problems.
I hope the above helps you some. If not, just ask. It might be easier to
understand what you are looking for if you can give concrete examples.
-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