A pkt-line's length are described in its first four bytes in ASCII
hex. Copy this substring to another string before feeding it to
git__strtol32. Otherwise, it will read the whole hash.
Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>
This are the types I intend to use for pkt-line parsing and (later)
creation. git_pkt serves as a base pointer type and once you know what
type it is you can use the real one (command, tip list, etc.)
Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>
If the strings match, git__fnmatch returns GIT_SUCCESS and
GIT_ENOMATCH on failure to match.
MSVC fixes: Added a test for _MSC_VER and (in that case) defined
HAVE_STRING_H to 1 so it doesn't try to include <strings.h> which
doesn't exist in the MSVC world. Moved the function declarations to
use the modern inline ones so MSVC doesn't have a fit. Added casts
everywhere so MSVC doesn't crap its pants.
Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>
Move them to their own functions to avoid duplication and to make it
easier to ignore missing configuration.
Not finding 'fetch' is considered fatal, though this might not be
correct behaviour (push-only remotes?)
Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>
Call gitfo_lstat with the full pathname instead of the relative one,
which fails in case the current working directory is different from
the workdir.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Also allow space for the null-terminator when allocating the buffer in
packfile_unpack_compressed. Up to now, the last newline had served as
a terminator, but 858ef372 searches for a double-newline and exposes
the problem.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
If a config has several files, we need to check all of them before we
can say that a variable doesn't exist.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
This function puts the global and repository configurations in one
git_config object and gives it to the user.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
There is no need to store the format outselves, as the library
provides git_filebuf_printf which takes care of the formatting itself.
Also get rid of an use of strcat + strcpy which is always a nice
thing.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
The better solution would probably be to turn the gitfo_lstat /
gitfo_readlink macros into real functions that wrap either lstat or
gitfo_lstat__w32 (and readlink or gitfo_readlink__w32). However, that
would introduce an indirection unless inlined. For now, this is the less
intrusive change.
Handle Symlinks if they can be handled in Win32. This is not even
compiled. Needs review.
The lstat implementation is modified from core Git.
The readlink implementation is modified from PHP.
In git, the short message of a commit is the part of the commit message before 2 consecutive line breaks. In the short message, line breaks are replaced by space characters.
After each variable gets set, we store it in our list (not completely
in the right position, but the close enough). Then we write out the
new config file in the same way that git.git does it (keep the rest of
the file intact and insert or replace the variable in its line).
Overwriting variables and adding new ones is supported (even on new
sections), though deleting isn't yet.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
The section name should be stored in its case-sensitive variant when
we are adding a new variable. Use the internalize_section function to
do just that.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
The (rather late) early-exit code, which provides a negligible
optimisation causes cvar_match_section to return false negatives when
it's called with a section name instead of a full variable name.
Remove this optimisation.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Add a check for the file descriptor in git_filebuf_cleanup. Without
it, an existing lockfile would be deleted if we tried to acquire it
(but failed, as the lockfile already existed).
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
When calling gitfo_exists() on a symbolic link, sometimes we need to
simply check whether the link exists and sometimes we need to check
whether the file pointed to by the symlink exists.
Introduce a new function gitfo_shallow_exists that only checks if the
link exists and revert gitfo_exists to the original functionality of
checking whether the file pointed to by the link exists.
This reverts commit df1c98ab6d6171ed63729195bd190b54b67fe530.
As 8a27b6b reverts the exposition of struct stat to the external API, we
do not need - indeed, do not want - struct stat to be in the outer
include layer.
00582bc introduced a change that required the caller of
git_blob_create_fromfile() to pass a struct stat with the stat
information for the file. Several developers pointed out that this would
make life hard for the bindings developers as struct stat isn't widely
supported by other languages.
Make git_blob_create_fromfile() stat the path itself, eliminating the
need for the file to be stat'ed by the caller. This makes
index_init_entry() more costly as the file will be stat'ed twice but
makes life easier for everyone else.
00582bcb introduced a change to git_blob_create_fromfile() that required
the caller to pass a stat struct. This means that we need to include
stat.h higher in the hierarchy of includes.
The entry mode flags for an entry created from a path name were not
correctly written if the entry was a symlink. The st_mode of a statted
symlink is 0120777, however git requires the mode to read 0120000,
because it does not care about permissions of symlinks.
Introduce index_create_mode() that correctly writes the mode flags in
the form expected by git.
gitfo_exists() used to error out if the given file was a symbolic link,
due to access() returning an error code. This is not expected behaviour,
as gitfo_exists() should only check whether the file itself exists, not
its link target if it is a symbolic link.
Fix this by calling gitfo_lstat() instead, which is just a wrapper for
lstat().
Also fix the same error in index_init_entry().
In order to be able to write symlinks with git_blob_create_fromfile(),
we need to check whether the file to be written is a symbolic link or
not. Since the calling function of git_blob_create_fromfile() is likely to have
stated the file before calling, we make it pass the stat.
The reason for this is that writing symbolic link blobs is significantly
different from writing ordinary files - we do not want to open the link
destination but instead want to write the link itself, regardless of
whether it exists or not.
Previously, index_init_entry() used to error out if the file to be added
was a symlink that pointed to a nonexistent file. Fix this behaviour to
add the file regardless of whether it exists. This mimics git.git's
behaviour.
As suggested by carlosmn, git_oid_ncmp would probably
be a better name than git_oid_match, for it does the same
as git_oid_cmp but only up to a certain amount of hex digits.
Feature Added: Search an unmerged entry by path (git_index_get_unmerged
renamed to git_index_get_unmerged_bypath) or by index (git_index_get_unmerged_byindex).
Now the ceiling_dirs are compared with their symbolic free version (like base_path).
The ceiling dirs check is now performed after getting the parent directory.
retrieve_device returns the file device for a given path (so that we can detect device change while walking through parent directories).
abspath returns a canonicalized path, symbolic link free.
retrieive_ceiling_directories_offset returns the biggest path offset that path match in the ceiling directory list (so that we can stop at ceiling directories).
Implemented find_unique_short_oid for pack backend, based on git sha1 lookup method;
finding an object given its full oid is just a particular case of searching
the unique object matching an oid prefix (short oid).
Added git_odb_read_unique_short_oid, which iterates over all the backends to
find and read the unique object matching the given oid prefix.
Added a git_object_lookup_short_oid method to find the unique object in
the repository matching a given oid prefix : it generalizes git_object_lookup
which now does nothing but calls git_object_lookup_short_oid.
A TREE extension with an entry count of -1 means that it was
invalidated and we should ignore it. Do so instead of returning an
error.
This fixes issue #202
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
There are two reasons why read_tree_internal might return a NULL
tree. The first one is a corrupt index, but the second one is an
invalidated TREE extension. Up to now, its only way to communicate
with its caller was through the return value being NULL or not.
Allow read_tree_internal to report its exit status independently from
the tree pointer.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Before this commit, malformed tag and signature were considered as
valid by the parser. See the test t3800-mktag.sh of git to see example
of malformed tag and signature.
If parse_section_header{,_ext} return an error, current_section
doesn't get allocated. Set it to NULL after freeing so we don't try to
free it again.
This fixes part 2-2 of Issue #210.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Simplify cfg_readline and at the same time fix it so that it does
really ignore empty lines.
This fixes point 2-1 of Issue #210
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
On error, it would free the configuration object even though it didn't
own that memory, which would cause a double-free.
This fixes the first part of Issue #210
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
"git_config_backend" have been renamed to "git_config_file", which
implements a generic interface to access a configuration file -- be it
either on disk, from a DB or whatever mumbojumbo.
I think this makes more sense.
Regarding "initialize" vs. "initialise", www.dict.cc says the first is American
English whereas the latter in British English. For consistency, we should
stick to American English.
