Current implementation of git_reference_rename() removes 'ref' from
loose cache, but not frees it. In result 'ref' is not reachable any more
and we have got memory leak.
Let's re-add 'ref' with corrected name to loose cache instead of
'new_ref' and free 'new_ref' properly.
'rollback' path seems leak too. git_reference_rename() need to be rewritten
for proper resource management.
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Solaris needs programs to link to socket and nsl in order to use BSD
sockets. Tell CMake to do so, this time for real.
Thanks to boyski for bearing with me through the various iterations of
this patch.
Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>
This a very packed minor release. The usual guilty parties have been
working harder than usual during the holidays -- thanks to everyone
involved!
As always, the updated API docs can be found at:
http://libgit2.github.com/libgit2/
NEW FEATURES:
- New OS abstraction layer. This should make all POSIX calls much
more reliable under Windows.
- Much faster writes of simple objects (commits, tags, trees) to the
ODB via in-memory buffering and direct writes, instead of streaming.
- Unified & simplified API for object creation. All the `create`
methods now take Objects instead of OIDs to ensure that corrupted
(dangling) objects cannot be created on the repository.
- Fully Git-compilant reference renaming (finally!), with
the already existing `git_reference_rename`.
- Deletion of config keys with `git_config_delete`
- Greatly improved index performance when adding new entries
- Reflog support with the `git_reflog` API
- Remotes support with the `git_remote` API
- First parts of the Networking API, including refspecs and
the transport abstraction layer. (Note that there are no actual
transports implemented yet)
- Status support with the `git_status_foreach` and `git_status_file`
functions.
- Tons of bugfixes, including the outstanding bug #127 (wrong sort
ordering when querying tree entries).
KNOWN ISSUES:
- The reference renaming code leaks memory. This is being worked on
as part of a reference handling overhaul.
- The tree-from-index builder has abysmal performance because it
doesn't handle the Treecache extension yet. This is also being
worked on.
FULL API CHANGELOG:
- removed, * modified, + added
- git_commit_create_o
- git_commit_create_ov
- git_reference_create_oid_f
- git_reference_create_symbolic_f
- git_reference_rename_f
- git_tag_create_f
- git_tag_create_fo
- git_tag_create_o
* git_commit_create
* git_commit_create_v
* git_config_foreach
* git_reference_create_oid
* git_reference_create_symbolic
* git_reference_rename
* git_tag_create
* git_tag_create_frombuffer
+ git_clearerror
+ git_config_delete
+ git_index_uniq
+ git_odb_hashfile
+ git_oid_fromstrn
+ git_reflog_entry_byindex
+ git_reflog_entry_committer
+ git_reflog_entry_msg
+ git_reflog_entry_oidnew
+ git_reflog_entry_oidold
+ git_reflog_entrycount
+ git_reflog_free
+ git_reflog_read
+ git_reflog_write
+ git_refspec_src_match
+ git_refspec_transform
+ git_remote_connect
+ git_remote_fetchspec
+ git_remote_free
+ git_remote_get
+ git_remote_ls
+ git_remote_name
+ git_remote_url
+ git_repository_head_detached
+ git_repository_head_orphan
+ git_status_file
+ git_status_foreach
+ git_tag_create_lightweight
+ git_tag_list_match
+ git_transport_new
It's not obvious that recurse_tree_entries or recurse_tree_entry
should free a resource that wasn't allocated by them. Do this
explicitely and plug a leak while we're at it.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
The old matcher was returning fake matches when given stupid entry
names. E.g.
`git2` could be matched by `git2 /`, `git2/foobar`, git2/////`
and other stupid stuff
Fixes#127 (that was quite an outstanding issue).
Rationale:
The tree objects on Git are stored and read following a very specific
sorting algorithm that places folders before files. That original sort
was the sort we were storing on memory, but this sort was being queried
with a binary search that used a simple `strcmp` for comparison, so
there were many instances where the search was failing.
Obviously, the most straightforward way to fix this is changing the
binary search CB to use the same comparison method as the sorting CB.
The problem with this is that the binary search callback compares a path
and an entry, so there is no way to know if the given path is a folder
or a standard file.
How do we work around this? Instead of splitting the `entry_byname`
method in two (one for searching directories and one for searching
normal files), we just assume that the path we are searching for is of
the same kind as the path it's being compared at the moment.
return git_futils_cmp_path(
ksearch->filename, ksearch->filename_len, entry->attr & 040000,
entry->filename, entry->filename_len, entry->attr & 040000);
Since there cannot be a folder and a regular file with the same name on
the same tree, the most basic equality check will always fail
for all comparsions, until our path is compared with the actual entry we
are looking for; in this case, the matching will succeed with the file
type of the entry -- whatever it was initially.
I hope that makes sense.
PS: While I was at it, I switched the cmp methods to use cached values
for the length of each filename. That makes searches and sorts
retardedly fast -- I was wondering the reason of the performance hiccups
on massive trees; it's because of 2*strlen for each comparsion call.
mode field of git_index_entry_unmerged is array of unsigned ints. It's
unsafe to cast pointer to an element of the array to long int *. It may
cause overflow in git_strtol32().
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Type casting usually points to some trick or bug. It's better not hide
it between useless type castings.
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
The `hashfile` function has been moved to ODB, next to `git_odb_hash`.
Global state has been removed from the dirent call in `status.c`,
because global state is killing the rainforest and causing global
warming.
