- 22 Jun, 2015 1 commit
-
-
When a file on the workdir has the same or a newer timestamp than the index, we need to perform a full check of the contents, as the update of the file may have happened just after we wrote the index. The iterator changes are such that we can reach inside the workdir iterator from the diff, though it may be better to have an accessor instead of moving these structs into the header.
Carlos Martín Nieto committed
-
- 20 Jun, 2015 1 commit
-
-
Test to ensure that when status updates an index, it does not alter the original mode for file types that are not supported (eg, symlinks on Windows).
Edward Thomson committed
-
- 16 Jun, 2015 1 commit
-
-
These tests want to test that we don't recalculate entries which match the index already. This is however something we force when truncating racily-clean entries. Tick the index forward as we know that we don't perform the modifications which the racily-clean code is trying to avoid.
Carlos Martín Nieto committed
-
- 02 Jun, 2015 1 commit
-
-
Pierre-Olivier Latour committed
-
- 28 May, 2015 4 commits
-
-
Since a diff entry only concerns a single entry, zero the information for the index side of a conflict. (The index entry would otherwise erroneously include the lowest-stage index entry - generally the ancestor of a conflict.) Test that during status, the index side of the conflict is empty.
Edward Thomson committed -
When diffing against an index, return a new `GIT_DELTA_CONFLICTED` delta type for items that are conflicted. For a single file path, only one delta will be produced (despite the fact that there are multiple entries in the index). Index iterators now have the (optional) ability to return conflicts in the index. Prior to this change, they would be omitted, and callers (like diff) would omit conflicted index entries entirely.
Edward Thomson committed -
Edward Thomson committed
-
When adding a conflict for some path, remove the staged entry. Otherwise, an illegal index (with both stage 0 and high-stage entries) would result.
Edward Thomson committed
-
- 20 May, 2015 1 commit
-
-
When we discover that we want to keep a negative rule, make sure to clear the error variable, as it we otherwise return whatever was left by the previous loop iteration.
Carlos Martín Nieto committed
-
- 04 May, 2015 1 commit
-
-
Edward Thomson committed
-
- 17 Apr, 2015 1 commit
-
-
Patrick Steinhardt committed
-
- 03 Mar, 2015 2 commits
-
-
We want to use the "checkout: moving from ..." message in order to let git know when a change of branch has happened. Make the convenience functions for this goal write this message.
Carlos Martín Nieto committed -
The signature for the reflog is not something which changes dynamically. Almost all uses will be NULL, since we want for the repository's default identity to be used, making it noise. In order to allow for changing the identity, we instead provide git_repository_set_ident() and git_repository_ident() which allow a user to override the choice of signature.
Carlos Martín Nieto committed
-
- 05 Dec, 2014 1 commit
-
-
Given top !top/foo in an ignore file, we should not unignore top/foo. This is an implementation detail of the git code leaking, but that's the behaviour we should show. A negation rule can only negate an exact rule it has seen before.
Carlos Martín Nieto committed
-
- 23 Nov, 2014 1 commit
-
-
Valgrind is now clean except for libssl and libgcrypt.
Carlos Martín Nieto committed
-
- 09 Nov, 2014 1 commit
-
-
Pierre-Olivier Latour committed
-
- 07 Nov, 2014 2 commits
-
-
This function has one output but can match multiple files, which can be unexpected for the user, which would usually path the exact path of the file he wants the status of.
Ungureanu Marius committed -
We consider an entry in .gitmodules to mean that we have a submodule at a particular path, even if HEAD^{tree} and the index do not contain any reference to it. We should ignore that submodule entry and simply consider that path to be a regular directory.
Carlos Martín Nieto committed
-
- 06 Nov, 2014 1 commit
-
-
When we mention "src" in src/.gitignore, we wrongly consider src/ itself to be ignored.
Carlos Martín Nieto committed
-
- 05 Nov, 2014 1 commit
-
-
We currently consider CR to start the end of the line, but that means that we miss cases with CR CR LF which can be used with git to match files whose names have CR at the end of their names. The fix from the patch comes from Russell's comment in the issue. This fixes #2536.
Carlos Martín Nieto committed
-
- 13 Aug, 2014 1 commit
-
-
Edward Thomson committed
-
- 08 Aug, 2014 2 commits
-
-
`git help ignore` has this to say about trailing slashes: > If the pattern ends with a slash, it is removed for the purpose of > the following description, but it would only find a match with a > directory. In other words, foo/ will match a directory foo and > paths underneath it, but will not match a regular file or a > symbolic link foo (this is consistent with the way how pathspec > works in general in Git). Sure enough, having manually performed the same steps as this test, `git status` tells us the following: # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached <file>..." to unstage) # # new file: force.txt # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # ../.gitignore # child1/ # child2/ i.e. neither child1 nor child2 is ignored.
Rob Rix committed -
When writing 'bin/*' in the rules, this means we ignore very file inside bin/ individually, but do not ignore the directory itself. Thus the status listing should list both files under bin/, one untracked and one ignored.
Carlos Martín Nieto committed
-
- 01 Jul, 2014 1 commit
-
-
Edward Thomson committed
-
- 04 Jun, 2014 2 commits
-
-
Alan Rogers committed
-
and a (failing) test for it.
Alan Rogers committed
-
- 30 May, 2014 2 commits
-
-
Alan Rogers committed
-
Alan Rogers committed
-
- 22 May, 2014 2 commits
-
-
Alan Rogers committed
-
Alan Rogers committed
-
- 21 May, 2014 1 commit
-
-
Alan Rogers committed
-
- 15 May, 2014 2 commits
-
-
Alan Rogers committed
-
Alan Rogers committed
-
- 14 May, 2014 1 commit
-
-
When thees is an unreadable folder, we should still be able to enumerate status.
Alan Rogers committed
-
- 06 May, 2014 1 commit
-
-
The diff code was using an "ignored_prefix" directory to track if a parent directory was ignored that contained untracked files alongside tracked files. Unfortunately, when negative ignore rules were used for directories inside ignored parents, the wrong rules were applied to untracked files inside the negatively ignored child directories. This commit moves the logic for ignore containment into the workdir iterator (which is a better place for it), so the ignored-ness of a directory is contained in the frame stack during traversal. This allows a child directory to override with a negative ignore and yet still restore the ignored state of the parent when we traverse out of the child. Along with this, there are some problems with "directory only" ignore rules on container directories. Given "a/*" and "!a/b/c/" (where the second rule is a directory rule but the first rule is just a generic prefix rule), then the directory only constraint was having "a/b/c/d/file" match the first rule and not the second. This was fixed by having ignore directory-only rules test a rule against the prefix of a file with LEADINGDIR enabled. Lastly, spot checks for ignores using `git_ignore_path_is_ignored` were tested from the top directory down to the bottom to deal with the containment problem, but this is wrong. We have to test bottom to top so that negative subdirectory rules will be checked before parent ignore rules. This does change the behavior of some existing tests, but it seems only to bring us more in line with core Git, so I think those changes are acceptable.
Russell Belfer committed
-
- 02 May, 2014 5 commits
-
-
There are a few tests that set up a fake home directory and a fake GLOBAL search path so that we can test things in global ignore or attribute or config files. This cleans up that code to work more robustly even if there is a test failure. This also fixes some valgrind warnings where scanning search paths for separators could end up doing a little bit of sketchy data access when coming to the end of search list.
Russell Belfer committed -
Russell Belfer committed
-
This is a proposed adjustment to the trace APIs. This makes the trace levels into a bitmask so that they can be selectively enabled and adds a callback-level payload, plus a message-level payload. This makes it easier for me to a GIT_TRACE_PERF callbacks that are simply bypassed if the PERF level is not set.
Russell Belfer committed -
Russell Belfer committed
-
This adds an option to refresh the stat cache while generating status. It also rips out the GIT_PERF stuff I had an makes use of the trace API to keep statistics about what happens during diff.
Russell Belfer committed
-