git/remote.c, branch main

odb: rename `odb_has_object()` flags

2026-04-01T03:43:14Z

Rename `odb_has_object()` flags to be properly prefixed with the function name. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'hn/status-compare-with-push'

2026-03-12T21:09:06Z

"git status" learned to show comparison between the current branch and various other branches listed on status.compareBranches configuration. * hn/status-compare-with-push: status: clarify how status.compareBranches deduplicates status: add status.compareBranches config for multiple branch comparisons refactor format_branch_comparison in preparation

status: add status.compareBranches config for multiple branch comparisons

2026-02-26T15:25:48Z

Add a new configuration variable status.compareBranches that allows users to specify a space-separated list of branch comparisons in git status output. Supported values: - @{upstream} for the current branch's upstream tracking branch - @{push} for the current branch's push destination Any other value is ignored and a warning is shown. When not configured, the default behavior is equivalent to setting `status.compareBranches = @{upstream}`, preserving backward compatibility. The advice messages shown are context-aware: - "git pull" advice is shown only when comparing against @{upstream} - "git push" advice is shown only when comparing against @{push} - Divergence advice is shown for upstream branch comparisons This is useful for triangular workflows where the upstream tracking branch differs from the push destination, allowing users to see their status relative to both branches at once. Example configuration: [status] compareBranches = @{upstream} @{push} Signed-off-by: Harald Nordgren Signed-off-by: Junio C Hamano

refactor format_branch_comparison in preparation

2026-02-26T15:25:48Z

Refactor format_branch_comparison function in preparation for showing comparison with push remote tracking branch. Signed-off-by: Harald Nordgren Signed-off-by: Junio C Hamano

Merge branch 'ps/commit-list-functions-renamed'

2026-02-13T21:39:25Z

Rename three functions around the commit_list data structure. * ps/commit-list-functions-renamed: commit: rename `free_commit_list()` to conform to coding guidelines commit: rename `reverse_commit_list()` to conform to coding guidelines commit: rename `copy_commit_list()` to conform to coding guidelines

Merge branch 'jk/remote-tracking-ref-leakfix'

2026-02-05T23:41:57Z

Leakfix. * jk/remote-tracking-ref-leakfix: remote: always allocate branch.push_tracking_ref remote: fix leak in branch_get_push_1() with invalid "simple" config remote: drop const return of tracking_for_push_dest() remote: return non-const pointer from error_buf()

Merge branch 'jk/remote-tracking-ref-leakfix' into hn/status-compare-with-push

2026-01-20T21:35:47Z

* jk/remote-tracking-ref-leakfix: remote: always allocate branch.push_tracking_ref remote: fix leak in branch_get_push_1() with invalid "simple" config remote: drop const return of tracking_for_push_dest() remote: return non-const pointer from error_buf()

remote: always allocate branch.push_tracking_ref

2026-01-20T00:24:02Z

In branch_get_push(), we usually allocate a new string for the @{push} ref, but will not do so in push.default=upstream mode, where we just pass back the result of branch_get_upstream() directly. This led to a hacky memory management scheme in e291c75a95 (remote.c: add branch_get_push, 2015-05-21): we store the result in the push_tracking_ref field of a "struct branch", under the assumption that the branch struct will last until the end of the program. So even though the struct doesn't know if it has an allocated string or not, it doesn't matter because we hold on to it either way. But that assumption was violated by f5ccb535cc (remote: fix leaking config strings, 2024-08-22), which added a function to free branch structs. Any struct which is fed to branch_release() is at risk of leaking its push_tracking_ref member. I don't think this can actually be triggered in practice. We rarely actually free the branch structs, and we only fill in the push_tracking_ref string lazily when it is needed. So triggering the leak would require a code path that does both, and I couldn't find one. Still, this is an ugly trap that may eventually spring on us. Since there is only one code path in branch_get_push() that doesn't allocate, let's just have it copy the string. And then we know that push_tracking_ref is always allocated, and we can free it in branch_release(). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

remote: fix leak in branch_get_push_1() with invalid "simple" config

2026-01-20T00:24:02Z

Most of the code paths in branch_get_push_1() allocate a string for the @{push} value. We then return the result, which is stored in a "struct branch", so the value is not leaked. But there's one path that does leak: when we are in the "simple" push mode, we have to check that the @{push} value matches what we'd get for @{upstream}. If it doesn't, we return an error, but forget to free the @{push} value we computed. Curiously, the existing tests don't trigger this with LSan, even though they do exercise the code path. As far as I can tell, it should be triggered via: git -c push.default=simple \ -c branch.foo.remote=origin \ -c branch.foo.merge=refs/heads/not-foo \ rev-parse foo@{push} which will complain that the upstream ("not-foo") does not match the push destination ("foo"). We do die() shortly after this, but not until after returning from branch_get_push_1(), which is where the leak happens. So it seems like a false negative in LSan. However, I can trigger it reliably by printing the @{push} value using for-each-ref. This takes a little more setup (because we need "foo" to actually exist to iterate over it with for-each-ref), but we can piggy-back on the existing repo config in t6300. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

remote: drop const return of tracking_for_push_dest()

2026-01-20T00:24:02Z

The string returned from tracking_for_push_dest() comes from apply_refspec(), and thus is always an allocated string (or NULL). We should return a non-const pointer so that the caller knows that ownership of the string is being transferred. This goes back to the function's origin in e291c75a95 (remote.c: add branch_get_push, 2015-05-21). It never really mattered because our return is just forwarded through branch_get_push_1(), which returns a const string as part of an intentionally hacky memory management scheme (see that commit for details). As the first step of untangling that hackery, let's drop the extra const from this helper function (and from the variables that store its result). There should be no functional change (yet). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano