Re: git-ls-files --added?

Junio C Hamano [off-list ref] writes:

Jon Seymour [off-list ref] writes:
...

quoted

I am still interested in the rationale for git-ls-files not supporting
such an option directly, since git-diff still seems a little indirect.

Partly historical, but more fundamental reason is because ls-files
plumbing is about the index.
...
Added is _not_ about comparision between the index and the work tree.  It
is between the HEAD commit and the index, and it does not belong to
ls-files plumbing.

Having said all that, I think you might be interested in pursuing

  http://thread.gmane.org/gmane.comp.version-control.git/97830/focus=99134

Also, the following thread may serve as a food for thought; it shows that
there is real need for some concise, easy to parse output for people who
want their own Porcelain.

  http://thread.gmane.org/gmane.comp.version-control.git/106122/focus=108110

In short, ls-files and diff-index _can_ give you what you want, but often
people would want information from both, consolidated.

On Mon, May 25, 2009 at 10:33 AM, Junio C Hamano [off-list ref] wrote:

Junio C Hamano [off-list ref] writes:

quoted

Jon Seymour [off-list ref] writes:
...

quoted

I am still interested in the rationale for git-ls-files not supporting
such an option directly, since git-diff still seems a little indirect.

Partly historical, but more fundamental reason is because ls-files
plumbing is about the index.
...
Added is _not_ about comparision between the index and the work tree.  It
is between the HEAD commit and the index, and it does not belong to
ls-files plumbing.

Having said all that, I think you might be interested in pursuing

 http://thread.gmane.org/gmane.comp.version-control.git/97830/focus=99134

Also, the following thread may serve as a food for thought; it shows that
there is real need for some concise, easy to parse output for people who
want their own Porcelain.

 http://thread.gmane.org/gmane.comp.version-control.git/106122/focus=108110

In short, ls-files and diff-index _can_ give you what you want, but often
people would want information from both, consolidated.

I'm one of those people :) Writing git support for IDEs is quite
tricky at times, and status check was one of quite unpleasant
experiences.

BTW git-diff won't work in situation when the directory was just
initialized and there were no commit. In that case added file = staged
file and it is possible to use git-ls-files.

Constantine

On 2009.05.25 11:31:42 +0400, Constantine Plotnikov wrote:

BTW git-diff won't work in situation when the directory was just
initialized and there were no commit. In that case added file = staged
file and it is possible to use git-ls-files.

You can use the object name of the empty tree with diff-* in that case,
that's what the pre-commit.sample hook does.

Björn

Thanks for your answer's Junio.

I am indeed writing some porcelain. I currently have some bash tooling
that wraps bash which does useful things for primarily linear
development in the subversion world [ trunk + well-controlled branches
] and in order to ease the transition of the organization to
full-blown adoption of git, I'd like to provide some equivalents that
operate in git land.

scm unknown  [ equivalent to not added to index yet ]
scm broken [ equivalent to deleted from working tree but not index ]
scm uncommittable [ union of unknown and broken ]
scm added
scm modified
scm deleted
scm other  [ cases I didn't think of yet ]

I am happy to munge these together with bash, but I thought I'd just
+1 the general requirement.

jon.

On Mon, May 25, 2009 at 4:33 PM, Junio C Hamano [off-list ref] wrote:

Junio C Hamano [off-list ref] writes:

quoted

Jon Seymour [off-list ref] writes:
...

quoted

I am still interested in the rationale for git-ls-files not supporting
such an option directly, since git-diff still seems a little indirect.

Partly historical, but more fundamental reason is because ls-files
plumbing is about the index.
...
Added is _not_ about comparision between the index and the work tree.  It
is between the HEAD commit and the index, and it does not belong to
ls-files plumbing.

Having said all that, I think you might be interested in pursuing

 http://thread.gmane.org/gmane.comp.version-control.git/97830/focus=99134

Also, the following thread may serve as a food for thought; it shows that
there is real need for some concise, easy to parse output for people who
want their own Porcelain.

 http://thread.gmane.org/gmane.comp.version-control.git/106122/focus=108110

In short, ls-files and diff-index _can_ give you what you want, but often
people would want information from both, consolidated.

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

Quoting David Aguilar [off-list ref] writes:

On Tue, May 26, 2009 at 10:56:52AM +1000, Jon Seymour wrote:

quoted

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.

Perhaps you weren't following the thread closely, but I think the patch in the thread quoted by Junio (http://thread.gmane.org/gmane.comp.version-control.git/97830/focus=99134) does exactly that.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/