- 22 May, 2014 1 commit
-
-
Edward Thomson committed
-
- 01 May, 2014 1 commit
-
-
Linquize committed
-
- 01 Apr, 2014 1 commit
-
-
This allows you to use a --repeat option to run status over and over and see how the output changes as you make local directory changes without reopening the git_repository object each time. Also, adds a flag to explicitly list the submodules before status.
Russell Belfer committed
-
- 25 Mar, 2014 1 commit
-
-
`git_submodule` objects were already refcounted internally in case the submodule name was different from the path at which it was stored. This makes that refcounting externally used as well, so `git_submodule_lookup` and `git_submodule_add_setup` return an object that requires a `git_submodule_free` when done.
Russell Belfer committed
-
- 03 Nov, 2013 1 commit
-
-
Update the explanation to reflect our use of git_status_list_new() and make the breaks in rocco more meaningful. Clarify why GIT_STATUS_CURRENT and index_to_workdir don't always imply each other. Fixes #1740.
Carlos Martín Nieto committed
-
- 02 Nov, 2013 1 commit
-
-
Ben Straub committed
-
- 31 Oct, 2013 1 commit
-
-
Ben Straub committed
-
- 30 Oct, 2013 1 commit
-
-
This reorganizes a few of the examples so that the main function comes first with the argument parsing extracted into a helper that can come at the end of the file (so the example focuses more on the use of libgit2 instead of command line support). This also creates a shared examples/common.[ch] so that useful helper funcs can be shared across examples instead of repeated.
Russell Belfer committed
-
- 17 Sep, 2013 1 commit
-
-
Unfortunately git-core uses the term "unborn branch" and "orphan branch" interchangeably. However, "orphan" is only really there for the checkout command, which has the `--orphan` option so it doesn't actually create the branch. Branches never have parents, so the distinction of a branch with no parents is odd to begin with. Crucially, the error messages deal with unborn branches, so let's use that.
Carlos Martín Nieto committed
-
- 20 Jun, 2013 4 commits
-
-
Russell Belfer committed
-
Russell Belfer committed
-
Files in status will, be default, be sorted according to the case insensitivity of the filesystem that we're running on. However, in some cases, this is not desirable. Even on case insensitive file systems, 'git status' at the command line will generally use a case sensitive sort (like 'ls'). Some GUIs prefer to display a list of file case insensitively even on case-sensitive platforms. This adds two new flags: GIT_STATUS_OPT_SORT_CASE_SENSITIVELY and GIT_STATUS_OPT_SORT_CASE_INSENSITIVELY that will override the default sort order of the status output and give the user control. This includes tests for exercising these new options and makes the examples/status.c program emulate core Git and always use a case sensitive sort.
Russell Belfer committed -
Russell Belfer committed
-