Re: git-ls-files --added?

[David Aguilar <davvid@gmail.com>]

On Tue, May 26, 2009 at 10:56:52AM +1000, Jon Seymour wrote:
> Thanks for your answer's Junio.
> 
> I am indeed writing some porcelain. I currently have some bash tooling


I know that for the purposes of writing scripts it would be
really great if we had a plumbing command that gave us exactly
what git-status tells us, but in a machine-parseable
and stable output format.

Particularly tricky to get both correct and fast is
partially-staged files, but git-status gets it right.
By partially staged I mean it has new uncommitted content
in the index as well as even newer content in the worktree.

Files fall roughly into these categories:

1. Staged:
	1.1 Existing file
	1.2 New file
	1.3 Deleted file
	1.4 File was renamed, this is the old path
	1.5 File was renamed, this is the new path


2. Unmerged

3. Modified
	3.1 File was modified
	3.2 File was deleted

4. Untracked
	4.1 This is a file
	4.2 This is a directory


Here's some semantics I would expect from such a command:

- A file can be both staged and modified.

- A file that is unmerged is only unmerged.
  It is neither modified nor staged.

- Untracked path behavior is nicer with git-status then with
  git-ls-files, the reason being that status special-cases
  directories.


Getting all of this information quickly (without having to run
multiple commands) would be ideal.  This command is a
combination of diff-against-worktree, diff-against-index,
show-untracked-files, etc. so it's not a paradigm that's
easily constructed with the existing plumbing.


-- 
		David