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

From: Jakub Narebski <jnareb@gmail.com>
Date: Apr 9, 2010, 12:56 UTC
Message-ID: <m3sk74hjkg.fsf@localhost.localdomain>
In-Reply-To: <20100409113248.GB27353@thyrsus.com>

Eric Raymond <esr@thyrsus.com> writes:

Show 14 quoted lines

> 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

Show 5 quoted lines

> 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.

Show 5 quoted lines

> 
>   '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.

Show 6 quoted lines

> 
>   '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).

Show 5 quoted lines

> 
>   '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