Hi Patrick, Thanks for your feedback! Here are some adjustments based on your suggestions: > 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. OK! I may have misunderstood it. I will remove it. > This one is something that is up for debate. While I do expect that most > of the commands should remain current semantics and options, we could > also use this as an opportunity to think whether there are any issues > with the current design and improve upon it. So, discussing the specific implementation of the command should also be included in the proposal, right? >> - 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`. Sorry, I made a mistake. I meant to convey that the `--exclude-existing` option should be included in `git-refs list` (replacing `git-show-ref --exclude-existing`), which then lists refs within a certain scope. >> - 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. Thanks for pointing that out. I will correct it afterward. >> - 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. Agree with it. >> - 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. > I think maybe separate `update` and `delete` can be more direct. Separating these commands can enhance clarity in their usage, although I'm open to further discussion if the community prefers a unified command. >> 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. > Got it. I will list my thoughts below. > You don't actually have to change "git.c" to introduce new subcommands. > We don't want `git refs-pack`, but rather `git refs pack`, which is an > important distinction. Sorry for my oversight. I will be more careful from now on. >> 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. Got it. > 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. > Thanks for your reminder! I plan to focus on implementing `git-refs list` and `git-refs update` first. These will form the foundation of the new design, and once stable, I will consider addressing `git-refs resolve` and additional commands if time permits. So, I need to update my proposal to reduce the number of subcommands so that I can complete this project with high quality. I also need to further discuss the implications of these commands. By reducing the number of subcommands, I can dedicate more time to refining each one and ensuring they integrate well with the existing system. I will also detail the implications of each command in my updated proposal. Thanks! Zheng Yuting
