user/sven/git.git/refs.c, branch v2.26.0-rc2

hashmap_entry: remove first member requirement from docs

2019-10-07T01:20:12Z

Comments stating that "struct hashmap_entry" must be the first member in a struct are no longer valid. Suggested-by: Phillip Wood Signed-off-by: Eric Wong Signed-off-by: Junio C Hamano

hashmap_cmp_fn takes hashmap_entry params

2019-10-07T01:20:11Z

Another step in eliminating the requirement of hashmap_entry being the first member of a struct. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee Signed-off-by: Junio C Hamano

hashmap_get{,_from_hash} return "struct hashmap_entry *"

2019-10-07T01:20:11Z

Update callers to use hashmap_get_entry, hashmap_get_entry_from_hash or container_of as appropriate. This is another step towards eliminating the requirement of hashmap_entry being the first field in a struct. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee Signed-off-by: Junio C Hamano

hashmap_put takes "struct hashmap_entry *"

2019-10-07T01:20:10Z

This is less error-prone than "void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee Signed-off-by: Junio C Hamano

hashmap_entry_init takes "struct hashmap_entry *"

2019-10-07T01:20:09Z

C compilers do type checking to make life easier for us. So rely on that and update all hashmap_entry_init callers to take "struct hashmap_entry *" to avoid future bugs while improving safety and readability. Signed-off-by: Eric Wong Reviewed-by: Derrick Stolee Signed-off-by: Junio C Hamano

object: convert lookup_unknown_object() to use object_id

2019-06-20T17:06:19Z

There are no callers left of lookup_unknown_object() that aren't just passing us the "hash" member of a "struct object_id". Let's take the whole struct, which gets us closer to removing all raw sha1 variables. It also matches the existing conversions of lookup_blob(), etc. The conversions of callers were done by hand, but they're all mechanical one-liners. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'nd/worktree-name-sanitization'

2019-06-13T20:19:40Z

In recent versions of Git, per-worktree refs are exposed in refs/worktrees// hierarchy, which means that worktree names must be a valid refname component. The code now sanitizes the names given to worktrees, to make sure these refs are well-formed. * nd/worktree-name-sanitization: worktree add: sanitize worktree names

worktree add: sanitize worktree names

2019-05-15T04:56:43Z

Worktree names are based on $(basename $GIT_WORK_TREE). They aren't significant until 3a3b9d8cde (refs: new ref types to make per-worktree refs visible to all worktrees - 2018-10-21), where worktree name could be part of a refname and must follow refname rules. Update 'worktree add' code to remove special characters to follow these rules. In the future the user will be able to specify the worktree name by themselves if they're not happy with this dumb character substitution. Reported-by: Konstantin Kharlamov Helped-by: Jeff King Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

refs.c: remove the_repo from read_ref_at()

2019-04-08T08:26:33Z

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

refs.c: add repo_dwim_log()

2019-04-08T08:26:33Z

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