Re: [GSoC] git-refs proposal draft

> In any case, I don't think the naming and how exactly each of these
> commands should look and work like needs to be hashed out in this
> document. It's nice to scope out _what_ we want to achieve and propose
> how this could look like, but ultimately I think that most of the design
> should happen during the project itself.

>> - git-refs exists
>>   Replaces git-show-ref --exists, providing reference existence checks
>>   with positive (<ref>) and exclusion-based (--exclude-existing)
>>   verification.
>
> I'm not quite clear what exclusion-based existence checks is. How do you
> check whether something exists when you exclude it? I don't think that
> this option is relevant in the context of `git refs exists`.

>> - git-refs resolve
>>   Replaces git-symbolic-ref, resolving symbolic references with added
>>   recursion depth control (--max-depth), while retaining deletion (-d)
>>   and quiet mode (-q) options.
>
> Not quite. The difference to `git refs show` is that this command always
> resolves the ref to an object. So it's rather more similar to `git
> rev-parse --verify`, except that it only ever handles references.

>> - git-refs pack
>>   Replaces git-pack-refs, packing loose references with support for
>>   filtering (--include, --exclude) and automatic cleanup (--prune).
>
> I would probably call this `git refs optimize` or something like that.
> git-pack-refs(1) is mostly called this way because it was introduced to
> pack refs into the "packed-refs" file. But nowadays with the reftable
> backend I think that the command name is somewhat inaccurate.

>> - git-refs update
>>   Replaces git-update-ref, providing transactional reference updates
>>   with batch processing (--stdin) and atomic guarantees.
>> - git-refs delete
>>   Separates the delete functionality from git-update-ref, ensuring
>>   explicit handling of reference removals with safety checks and batch
>>   operations (--stdin).
>
> It's up for debate whether we should even have something like `git refs
> delete`. As you rightfully notice `git refs update` already handles the
> usecase, so it feels like needless duplication.
>

>> 1. Option Parsing: Each subcommand will reuse the argument parsing
>>    logic from legacy commands (e.g., git-pack-refs --prune).
>
> We cannot and do not want to do this for every case. As mentioned above,
> we may want to iterate on some of the subcommands to address historic
> warts. But overall I agree, we should of course aim to reduce
> duplication as far as it is sensible to do.

>
>> 2. Shared Backend Logic: Calls to common functions in refs/ (e.g.,
>>    reference traversal, locking mechanisms).
>> 3. Error Consistency: Maintain the same error codes and message
>>    formats as legacy commands.
>
> Same reasoning here, we may want to adapt some of them. The old commands
> won't go away as they are used everywhere, and that makes it more
> reasonable for us to change behaviour in their newer equivalents.
>

>> 3. Reuse refs/files-backend.c Logic:
>>    - Ensure cmd_refs_pack calls pack_refs correctly, adjusting as
>>      necessary for new options.
>
> We shouldn't have to touch any of the backends at all. You should rather
> make sure to integrate with "refs.c", which wraps the backends and
> provides a backend-agnostic interface to refs.

> You probably underestimate the time to review and land a specific change
> quite significantly. Landing new features in ~2 weeks is thus not quite
> realistic and you should allocate a lot more time for each of the
> specific subcommands.
>
> That of course raises the question of how to squeeze all of the
> subcommands into a single GSoC. And the answer is that you don't: it's
> perfectly fine to implement only a subset of the new proposed
> subcommands. I'd rather you spend more time thinking about how to
> improve upon the status quo for each of the subcommands and thus spend
> more time on it than trying to do everything in a hurry.
>