Eric Raymond <esr@xxxxxxxxxxx> writes:
> Jacob Helwig <jacob.helwig@xxxxxxxxx>:
> > On Thu, Apr 8, 2010 at 21:04, Eric Raymond <esr@xxxxxxxxxxxxxxxxx> 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
--
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