| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Move to the `git_error` name in the internal API for error-related
functions.
|
| |
|
|
|
|
|
| |
We use the term "invalid" to refer to bad or malformed data, eg
`GIT_REF_INVALID` and `GIT_EINVALIDSPEC`. Since we're changing the
names of the `git_object_t`s in this release, update it to be
`GIT_OBJECT_INVALID` instead of `BAD`.
|
| |
|
|
| |
Use the new object_type enumeration names within the codebase.
|
| |
|
|
|
|
|
| |
Replace remaining uses of the `git__strtol32` function. While these uses
are all safe as the strings were either sanitized or from a trusted
source, we want to remove `git__strtol32` altogether to avoid future
misuse.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A lot of compilers nowadays generate warnings when there are cases in a
switch statement which implicitly fall through to the next case. To
avoid this warning, the last line in the case that is falling through
can have a comment matching a regular expression, where one possible
comment body would be `/* fall through */`.
An alternative to the comment would be an explicit attribute like e.g.
`[[clang::fallthrough]` or `__attribute__ ((fallthrough))`. But GCC only
introduced support for such an attribute recently with GCC 7. Thus, and
also because the fallthrough comment is supported by most compilers, we
settle for using comments instead.
One shortcoming of that method is that compilers are very strict about
that. Most interestingly, that comment _really_ has to be the last line.
In case a closing brace follows the comment, the heuristic will fail.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Next to including several files, our "common.h" header also declares
various macros which are then used throughout the project. As such, we
have to make sure to always include this file first in all
implementation files. Otherwise, we might encounter problems or even
silent behavioural differences due to macros or defines not being
defined as they should be. So in fact, our header and implementation
files should make sure to always include "common.h" first.
This commit does so by establishing a common include pattern. Header
files inside of "src" will now always include "common.h" as its first
other file, separated by a newline from all the other includes to make
it stand out as special. There are two cases for the implementation
files. If they do have a matching header file, they will always include
this one first, leading to "common.h" being transitively included as
first file. If they do not have a matching header file, they instead
include "common.h" as first file themselves.
This fixes the outlined problems and will become our standard practice
for header and source files inside of the "src/" from now on.
|
| |
|
|
|
|
|
| |
Support '..' and '...' ranges where one side is not specified.
The unspecified side defaults to HEAD.
Closes #4223
|
| |
|
|
|
|
|
|
| |
Error messages should be sentence fragments, and therefore:
1. Should not begin with a capital letter,
2. Should not conclude with punctuation, and
3. Should not end a sentence and begin a new one
|
| | |
|
| | |
|
| |
|
|
|
| |
Now that we no longer fail to push non-commits on a glob, let's search
on all refs when we rev-parse syntax asks us to match text.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
References and their logs are logically coupled, let's make it so in
the code by moving the fs-based reflog implementation to live next to
the fs-based refs one.
As part of the change, make the function take names rather than
references, as only the names are relevant when looking up and
handling reflogs.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This fixes a small memory leak in git_revparse where early returns on
errors from git_revparse_single cause a free() on the (reallocated) left
side of the revspec to be skipped.
|
| |
|
|
| |
Fix #1722
|
| |
|
|
|
| |
This fixes problems with missing function prototypes and 64-bit
data issues on Windows.
|
| | |
|
| |
|
|
|
|
| |
Expose a way to retrieve, along with the target git_object, the reference
pointed at by some revparse expression (`@{<-n>}` or
`<branchname>@{upstream}` syntax).
|
| | |
|
| | |
|
| |
|
|
|
| |
Extract this function out of the rev-parse code to be able to DWIM a
reference instead of its target.
|
| |
|
|
|
|
|
| |
There are many paths through revparse that may return an error
code without reporting an error, I believe. This fixes one of
them. Because of the backtracking in revparse, it is pretty
complicated to fix the others.
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| | |
This will probably prevent many lookup/free
operations in calling code.
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | | |
Branch upstream configuration
|
| | | |
| | |
| | |
| | |
| | | |
The term 'tracking' is overloaded. Help distinguish what we mean by
using 'upstream' for this part of the library.
|
| | |/
|/| |
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| | |
Signed-off-by: Greg Price <price@mit.edu>
|
| | |
| |
| |
| |
| |
| |
| | |
Implicit type conversion argument of function to size_t type
Suspicious sequence of types castings: size_t -> int -> size_t
Consider reviewing the expression of the 'A = B == C' kind. The expression is calculated as following: 'A = (B == C)'
Unsigned type is never < 0
|
| |/ |
|
| | |
|
| |
|
|
| |
Fix #1306
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
