git/refspec.c, branch main

refspec: fix typo in comment

2026-03-24T04:27:17Z

Fix a long-standing typo in a comment: "refpsecs" -> "refspecs". Signed-off-by: K Jayatheerth Signed-off-by: Junio C Hamano

refspec: replace `refspec_item_init()` with fetch/push variants

2025-03-21T08:45:16Z

For similar reasons as in the previous refactoring of `refspec_init()` into `refspec_init_fetch()` and `refspec_init_push()`, apply the same refactoring to `refspec_item_init()`. Signed-off-by: Taylor Blau Acked-by: Elijah Newren Signed-off-by: Junio C Hamano

refspec: remove refspec_item_init_or_die()

2025-03-21T08:45:16Z

There are two callers of this function, which ensures that a dispatched call to refspec_item_init() does not fail. In the following commit, we're going to add fetch/push-specific variants of refspec_item_init(), which will turn one function into two. To avoid introducing yet another pair of new functions (such as refspec_item_init_push_or_die() and refspec_item_init_fetch_or_die()), let's remove the thin wrapper entirely. This duplicates a single line of code among two callers, but thins the refspec.h API by one function, and prevents introducing two more in the following commit. Note that we still have a trailing Boolean argument in the function `refspec_item_init()`. The following commit will address this. Signed-off-by: Taylor Blau Acked-by: Elijah Newren Signed-off-by: Junio C Hamano

refspec: replace `refspec_init()` with fetch/push variants

2025-03-21T08:45:16Z

To avoid having a Boolean argument in the refspec_init() function, replace it with two variants: - `refspec_init_fetch()` - `refspec_init_push()` to codify the meaning of that Boolean into the function's name itself. Signed-off-by: Taylor Blau Acked-by: Elijah Newren Signed-off-by: Junio C Hamano

refspec: treat 'fetch' as a Boolean value

2025-03-21T08:45:15Z

Since 6d4c057859 (refspec: introduce struct refspec, 2018-05-16), we have macros called REFSPEC_FETCH and REFSPEC_PUSH. This confusingly suggests that we might introduce other modes in the future, which, while possible, is highly unlikely. But these values are treated as a Boolean, and stored in a struct field called 'fetch'. So the following: if (refspec->fetch == REFSPEC_FETCH) { ... } , and if (refspec->fetch) { ... } are equivalent. Let's avoid renaming the Boolean values "true" and "false" here and remove the two REFSPEC_ macros mentioned above. Since this value is truly a Boolean and will only ever take on a value of 0 or 1, we can declare it as a single bit unsigned field. In practice this won't shrink the size of 'struct refspec', but it more clearly indicates the intent. Note that this introduces some awkwardness like: refspec_item_init_or_die(&spec, refspec, 1); , where it's unclear what the final "1" does. This will be addressed in the following commits. Signed-off-by: Taylor Blau Acked-by: Elijah Newren Signed-off-by: Junio C Hamano

refspec_ref_prefixes(): clean up refspec_item logic

2025-03-10T20:13:45Z

The point of refspec_ref_prefixes() is to look over the set of refspecs and set up an appropriate list of "ref-prefix" strings to send to the server. The logic for handling individual refspec_items has some confusing bits. The final part of our if/else cascade checks this: else if (item->src && !item->exact_sha1) prefix = item->src; But we know that "item->exact_sha1" can never be true, because earlier we did: if (item->exact_sha1 || item->negative) continue; This is due to 6c301adb0a (fetch: do not pass ref-prefixes for fetch by exact SHA1, 2018-05-31), which added the continue. So it is tempting to remove the extra exact_sha1 at the end of the cascade, leaving the one at the top of the loop. But I don't think that's quite right. The full cascade is: if (rs->fetch == REFSPEC_FETCH) prefix = item->src; else if (item->dst) prefix = item->dst; else if (item->src && !item->exact_sha1) prefix = item->src; which all comes from 6373cb598e (refspec: consolidate ref-prefix generation logic, 2018-05-16). That first "if" is supposed to handle fetches, where we care about the source name, since that is coming from the server. And the rest should be for pushes, where we care about the destination, since that's the name the server will use. And we get that either explicitly from "dst" (for something like "foo:bar") or implicitly from the source (a refspec like "foo" is treated as "foo:foo"). But how should exact_sha1 interact with those? For a fetch, exact_sha1 always means we do not care about sending a name to the server (there is no server refname at all). But pushing an exact sha1 should still care about the destination on the server! It is only if we have to fall back to the implicit source that we need to care if it is a real ref (though arguably such a push does not even make sense; where would the server store it?). So I think that 6c301adb0a "broke" the push case by always skipping exact_sha1 items, even though a push should only care about the destination. Of course this is all completely academic. We have still not implemented a v2 push protocol, so even though we do call this function for pushes, we'd never actually send these ref-prefix lines. However, given the effort I spent to figure out what was going on here, and the overlapping exact_sha1 checks, I'd like to rewrite this to preemptively fix the bug, and hopefully make it less confusing. This splits the "if" at the top-level into fetch vs push, and then each handles exact_sha1 appropriately itself. The check for negative refspecs remains outside of either (there is no protocol support for them, so we never send them to the server, but rather use them only to reduce the advertisement we receive). The resulting behavior should be identical for fetches, but hopefully sets us up better for a potential future v2 push. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

refspec: clarify function naming and documentation

2025-02-18T17:44:27Z

Rename `match_name_with_pattern()` to `match_refname_with_pattern()` to better reflect its purpose and improve documentation comment clarity. The previous function name and parameter names were inconsistent, making it harder to understand their roles in refspec matching. - Rename parameters: - `key` -> `pattern` (globbing pattern to match) - `name` -> `refname` (refname to check) - `value` -> `replacement` (replacement mapping pattern) Signed-off-by: Meet Soni Signed-off-by: Junio C Hamano

Merge branch 'ms/remote-valid-remote-name'

2025-02-12T18:08:54Z

Code shuffling. * ms/remote-valid-remote-name: remote: relocate valid_remote_name

remote: relocate valid_remote_name

2025-02-04T17:55:59Z

Move the `valid_remote_name()` function from the refspec subsystem to the remote subsystem to better align with the separation of concerns. Signed-off-by: Meet Soni Signed-off-by: Junio C Hamano

refspec: relocate apply_refspecs and related funtions

2025-02-04T17:51:42Z

Move the functions `apply_refspecs()` and `apply_negative_refspecs()` from `remote.c` to `refspec.c`. These functions focus on applying refspecs, so centralizing them in `refspec.c` improves code organization by keeping refspec-related logic in one place. Signed-off-by: Meet Soni Signed-off-by: Junio C Hamano