Re: Status of all files (was: Re: How can I tell if a file is ignored by git?

[Jakub Narebski <jnareb@gmail.com>]

Eric Raymond <esr@thyrsus.com> writes:

> Jacob Helwig <jacob.helwig@gmail.com>:
> > On Thu, Apr 8, 2010 at 21:04, Eric Raymond <esr@snark.thyrsus.com> wrote:
> > > I'm planning some work on Emacs VC mode.
> > >
> > > I need a command I can run on a path to tell if it's ignored by git.
> > 
> > What about a variant of:
> >     git ls-files -i -o --exclude-standard
> 
> That will do nicely, thank you.
> 
> There could be something better.  Emacs VC mode, and other similar
> front ends, would be greatly aided by a command that lists all files,
> each with a status code it can understand.

There is also

        git status --short

> Our canonical list (omitting two that apply only to locking systems)
> is:
> 
>   'up-to-date        The working file is unmodified with respect to the
>                      latest version on the current branch, and not locked.

In Git you don't have locking, but you have three versions: in the
working area (the working file), in the index, and latest version on
the current branch (the HEAD version).

So 'up-to-date in Git would probably mean working tree = cached = HEAD
version.

> 
>   'edited            The working file has been edited by the user.

Does this include stat-dirty files, i.e. if file has been modified
(mtime), but the contents is the same in working file and in HEAD
version?  See also 'git update-index --refresh' etc.

> 
>   'needs-update      The file has not been edited by the user, but there is
>                      a more recent version on the current branch stored
>                      in the master file.

Needs *update* looks like it came from centralized VCS like CVS and
Subversion, where you use update-the-commit method.  You can't say
that HEAD version is more recent that working file...

The rought equivalent would be that upstream branch for current branch
(e.g. 'origin/master' can be upstream for 'master' branch) is in
fast-forward state i.e. current branch is direct ancestor of
corresponding upstream branch, and the file was modified upstream.

> 
>   'needs-merge       The file has been edited by the user, and there is also
>                      a more recent version on the current branch stored in
>                      the master file.  This state can only occur if locking
>                      is not used for the file.

This, like 'needs-update, looks like it is relevant only in
update-the-commit workflow centralized VCS.

> 
>   'added             Scheduled to go into the repository on the next commit.
> 
>   'removed           Scheduled to be deleted from the repository on next commit.
> 
>   'conflict          The file contains conflicts as the result of a merge.

Note that with Git you can have other merge conflict than simple
CONFLICT(contents).  With CONFLICT(rename/rename) for example the file
would not contain textual conflict, so e.g. it won't have conflict
markers, etc.

> 
>   'missing           The file is not present in the file system, but the VC
>                      system still tracks it.

Note that file might be missing only in working directory, and can be
missing both in working directory and the index (staging area).

> 
>   'ignored           The file showed up in a dir-status listing with a flag
>                      indicating the version-control system is ignoring it,
> 
>   'unregistered      The file is not under version control.

[...]
> I am unclear on what your "unmerged" (M) status means.

Probably 'conflict.

-- 
Jakub Narebski
Poland
ShadeHawk on #git