git/notes.c, branch v2.24.2

Merge branch 'mh/notes-duplicate-entries'

2019-09-30T04:19:25Z

A few implementation fixes in the notes API. * mh/notes-duplicate-entries: notes: avoid potential use-after-free during insertion notes: avoid leaking duplicate entries

notes: avoid potential use-after-free during insertion

2019-08-26T17:29:56Z

The note_tree_insert() function may free the leaf_node struct we pass in (e.g., if it's a duplicate, or if it needs to be combined with an existing note). Most callers are happy with this, as they assume that ownership of the struct is handed off. But in load_subtree(), if we see an error we'll use the handed-off struct's key_oid to generate the die() message, potentially accessing freed memory. We can easily fix this by instead using the original oid that we copied into the leaf_node struct. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

notes: avoid leaking duplicate entries

2019-08-26T17:29:38Z

When add_note is called multiple times with the same key/value pair, the leaf_node it creates is leaked by notes_tree_insert. Signed-off-by: Mike Hommey Signed-off-by: Junio C Hamano

tree-walk.c: remove the_repo from get_tree_entry()

2019-06-27T19:45:17Z

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

tree-walk.c: remove the_repo from fill_tree_descriptor()

2019-06-27T19:45:17Z

While at there, clean up the_repo usage in builtin/merge-tree.c a tiny bit. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Merge branch 'en/merge-directory-renames'

2019-05-08T15:37:22Z

"git merge-recursive" backend recently learned a new heuristics to infer file movement based on how other files in the same directory moved. As this is inherently less robust heuristics than the one based on the content similarity of the file itself (rather than based on what its neighbours are doing), it sometimes gives an outcome unexpected by the end users. This has been toned down to leave the renamed paths in higher/conflicted stages in the index so that the user can examine and confirm the result. * en/merge-directory-renames: merge-recursive: switch directory rename detection default merge-recursive: give callers of handle_content_merge() access to contents merge-recursive: track information associated with directory renames t6043: fix copied test description to match its purpose merge-recursive: switch from (oid,mode) pairs to a diff_filespec merge-recursive: cleanup handle_rename_* function signatures merge-recursive: track branch where rename occurred in rename struct merge-recursive: remove ren[12]_other fields from rename_conflict_info merge-recursive: shrink rename_conflict_info merge-recursive: move some struct declarations together merge-recursive: use 'ci' for rename_conflict_info variable name merge-recursive: rename locals 'o' and 'a' to 'obuf' and 'abuf' merge-recursive: rename diff_filespec 'one' to 'o' merge-recursive: rename merge_options argument from 'o' to 'opt' Use 'unsigned short' for mode, like diff_filespec does

Use 'unsigned short' for mode, like diff_filespec does

2019-04-08T07:02:07Z

struct diff_filespec defines mode to be an 'unsigned short'. Several other places in the API which we'd like to interact with using a diff_filespec used a plain unsigned (or unsigned int). This caused problems when taking addresses, so switch to unsigned short. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

notes: replace sha1_to_hex

2019-04-01T02:57:38Z

Replace the uses of sha1_to_hex in this function with hash_to_hex to allow the use of SHA-256 as well. Rename some variables since this code is no longer limited to SHA-1. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

notes: make hash size independent

2019-04-01T02:57:38Z

Switch out various uses of the GIT_SHA1_* constants with GIT_MAX_* constants for allocations and the_hash_algo for general parsing. Update a comment to no longer be SHA-1 specific. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

tree-walk: store object_id in a separate member

2019-01-15T17:57:41Z

When parsing a tree, we read the object ID directly out of the tree buffer. This is normally fine, but such an object ID cannot be used with oidcpy, which copies GIT_MAX_RAWSZ bytes, because if we are using SHA-1, there may not be that many bytes to copy. Instead, store the object ID in a separate struct member. Since we can no longer efficiently compute the path length, store that information as well in struct name_entry. Ensure we only copy the object ID into the new buffer if the path length is nonzero, as some callers will pass us an empty path with no object ID following it, and we will not want to read past the end of the buffer. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano