▼Libgit2:   Bindings for the libgit2 Git Library
On this page:
git_  status_  byindex
git_  status_  file
git_  status_  foreach
git_  status_  foreach_  ext
git_  status_  init_  options
git_  status_  list_  entrycount
git_  status_  list_  free
git_  status_  list_  new
git_  status_  should_  ignore
8.12
  top  contents    up   

44 Status🔗ℹ

 (require libgit2/include/status) package: libgit2

procedure

(git_status_byindex statuslist idx) → git_status_entry?

  statuslist : status_list?
  idx : integer?
Get a pointer to one of the entries in the status list.

The entry is not modifiable and should not be freed.

procedure

(git_status_file repo path) → git_status_t

  repo : repository?
  path : string?
Get file status for a single file.

This tries to get status for the filename that you give. If no files match that name (in either the HEAD, index, or working directory), this returns GIT_ENOTFOUND.

If the name matches multiple files (for example, if the path names a directory or if running on a case- insensitive filesystem and yet the HEAD has two entries that both match the path), then this returns GIT_EAMBIGUOUS because it cannot give correct results.

This does not do any sort of rename detection. Renames require a set of targets and because of the path filtering, there is not enough information to check renames correctly. To check file status with rename detection, there is no choice but to do a full git_status_list_new and scan through looking for the path that you are interested in.

procedure

(git_status_foreach repo callback payload) → integer?

  repo : repository?
  callback : git_status_cb
  payload : bytes?
Gather file statuses and run a callback for each one.

The callback is passed the path of the file, the status (a combination of the git_status_t values above) and the payload data pointer passed into this function.

If the callback returns a non-zero value, this function will stop looping and return that value to caller.

procedure

(git_status_foreach_ext repo    
  opts    
  callback    
  payload) → integer?
  repo : repository?
  opts : git_status_opts?
  callback : git_status_cb
  payload : bytes?
Gather file status information and run callbacks as requested.

This is an extended version of the git_status_foreach() API that allows for more granular control over which paths will be processed and in what order. See the git_status_options structure for details about the additional controls that this makes available.

Note that if a pathspec is given in the git_status_options to filter the status, then the results from rename detection (if you enable it) may not be accurate. To do rename detection properly, this must be called with no pathspec so that all files can be considered.

procedure

(git_status_init_options opts version) → integer?

  opts : git_status_opts?
  version : integer?
Initializes a git_status_options with default values. Equivalent to creating an instance with GIT_STATUS_OPTIONS_INIT.

procedure

(git_status_list_entrycount statuslist) → integer?

  statuslist : status_list?
Gets the count of status entries in this list.

If there are no changes in status (at least according the options given when the status list was created), this can return 0.

procedure

(git_status_list_free statuslist) → void?

  statuslist : status_list?
Free an existing status list

procedure

(git_status_list_new repo opts) → status_list?

  repo : repository?
  opts : git_status_opts?
Gather file status information and populate the git_status_list.

Note that if a pathspec is given in the git_status_options to filter the status, then the results from rename detection (if you enable it) may not be accurate. To do rename detection properly, this must be called with no pathspec so that all files can be considered.

procedure

(git_status_should_ignore repo path) → boolean?

  repo : repository?
  path : string?
Test if the ignore rules apply to a given file.

This function checks the ignore rules to see if they would apply to the given file. This indicates if the file would be ignored regardless of whether the file is already in the index or committed to the repository.

One way to think of this is if you were to do "git add ." on the directory containing the file, would it be added or not?

  top  contents    up