{"thread":{"id":"63229","subject":"[GSoC][Proposal RFC] Consolidate ref-related functionality into git-refs","startedAt":"2025-04-01T01:37:33Z","lastAt":"2025-04-04T12:24:31Z","messageCount":8,"participants":["Meet Soni","Patrick Steinhardt","Karthik Nayak"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"515404","messageId":"CAPhwyn3McL-2rwjkexsDUWqxt0Kr4UsDVy_G=s1DmKhrw5BZ-A@mail.gmail.com","threadId":"63229","inReplyTo":null,"subject":"[GSoC][Proposal RFC] Consolidate ref-related functionality into git-refs","fromName":"Meet Soni","fromEmail":"meetsoni3017@gmail.com","sentAt":"2025-04-01T01:37:21Z","receivedAt":"2025-04-01T01:37:33Z","isPatch":false,"sender":{"key":"meetsoni3017@gmail.com","avatar":"https://avatars.githubusercontent.com/u/92802561?v=4"},"body":"Hi Everyone,\nThis is my proposal for \"Consolidate ref-related functionality into\ngit-refs\" in Google Summer of Code 2025. The Doc version:\nhttps://docs.google.com/document/d/1Nfg6Dner1eU10LIlhkSJ5-N31Y6QuWj8bad_bAiMBa8/edit?usp=sharing\n\nI'd appreciate any feedback on this.\n\nThanks,\nMeet\n\n---------8<----------8<----------8<----------8<----------8<----------8<----------8<----------8<\nGSoC 2025 @ Git | Meet Soni\nConsolidate ref-related functionality into git-refs\n---------------------------------------------------\n\n\nPersonal Information:\n---------------------\nName: Meet Soni\nE-mail: meetsoni3017@gmail.com\nMobile No.: +91 9054520887\n\nEducation: Silver Oak University, Gujarat, India\nYear: III/IV\nDegree: Bachelors in Computer Engineering\n\nTime-Zone: UTC + 5:30 (IST)\nGitHub: github.com/inosmeet\nBlog: inosmeet.github.io\nLinkedIn: https://www.linkedin.com/in/meet-soni-4230701b9/\n\n\nPre-GSoC:\n---------\n\nI got into Git’s codebase in November 2024 by reviewing various documentations,\nprevious patches and began contributing in mid-December 2024.\n\nFollowing is the list of contributions that I have made:\n\n* [PATCH v3] t7611: replace test -f with test_path_is* helpers\n  Status: Merged into master\n  Merge commit:cef3d4a89f8d21fae6669822cbb540927020d93b\n  Description:\n    This patch is my first contribution to fulfill microproject criteria. It\n    improves test t7611-merge-abort.sh by converting old style path\nchecks to use\n    modern helper functions in order to achieve better debuggability.\n  Mailing list thread:\n    https://lore.kernel.org/git/20241227105345.10184-1-meetsoni3017@gmail.com/\n\n* [GSoC][PATCH v4 0/5] refspec: centralize refspec-related logic\n  Status: Merged into master\n  Merge Commit: e4f6ab008522c5ad386485720770b8d03b4fb880\n  Description:\n    This patch series addresses a design inconsistency noted by Patrick, where\n    the refspec-related logic was scattered across multiple headers, by renaming\n    and relocating this logic for improved cohesion. In particular, functions\n    such as omit_name_by_refspec() have been renamed to better reflect their\n    intended functionality, and the core refspec-related routines have been\n    moved from remote.c into a dedicated refspec.c file, ensuring a clear\n    separation of concerns and more maintainable code.\n  Mailing list thread:\n    https://lore.kernel.org/git/20250204040558.34766-1-meetsoni3017@gmail.com/\n\n* [GSoC][PATCH v2] remote: relocate valid_remote_name\n  Status: Merged into master\n  Merge Commit: f21ea69d945f958704f2fe143c2638ecae6e0d12\n  Description:\n    This patch, prompted by Junio's feedback in my previous patch series,\n    moves the valid_remote_name() function from refspec to remote to\n    centralize functionality related to remote repositories, thereby\n    maintaining a clearer separation of concerns.\n  Mailing list thread:\n    https://lore.kernel.org/git/20250204142852.13035-1-meetsoni3017@gmail.com\n\n* [GSoC][PATCH v2] merge-recursive: optimize time complexity for process_renames\n  Status: Merged into master\n  Merge Commit: b07dd9078b8ba5f3b7f5c88f84f7ee9c34fa65e1\n  Description:\n    This patch reduces time complexity for process_renames() from O(n^2) to\n    O(n log n) when building a sorted string_list by constructing it unsorted\n    and sorting it afterward, thereby addressing a previously noted TODO\n    comment.\n  Mailing list thread:\n    https://lore.kernel.org/git/20250214044129.15282-1-meetsoni3017@gmail.com/\n\n* [GSoC][PATCH v2] refspec: clarify function naming and documentation\n  Status: Merged into master\n  Merge Commit: 044b6f04f23d6c7e3c3750c9829db96b71470874\n  Description:\n    This patch renames a function and its parameters to improve clarity and\n    consistency in refspec matching, addressing earlier feedback from Junio to\n    resolve documentation ambiguities and enhance overall code readability.\n  Mailing list thread:\n    https://lore.kernel.org/git/20250215084539.73799-1-meetsoni3017@gmail.com\n\n* [GSoC PATCH v5 0/3] reftable: return proper error codes from block_writer_add\n  Status: Will merge to next (Currently approved and in seen)\n  Description:\n    This patch series refines error handling by eliminating assumptions about\n    the error codes returned by block_writer_add(), a change motivated by a\n    TODO comment to ensure more robust and flexible behavior.\n  Mailing list thread:\n    https://lore.kernel.org/git/20250319152927.1263033-1-meetsoni3017@gmail.com\n\n* [GSoC][RFC PATCH] show-branch: use commit-slab for flag storage\n  Status: On-hold from my side\n  Description:\n    This patch attempts to replace direct access to commit->object.flags with\n    a commit-slab mechanism by introducing get_commit_flags() and\n    set_commit_flags() for flag management and ensuring the canonical\n    UNINTERESTING definition is used. Initially prompted by a TODO comment,\n    review feedback broadened the scope to address several additional aspects\n    that were new to me; while further investigating these changes, I was\n    selected for LFX mentorship, which resulted in increased time constraints\n    and so I had to temporarily deprioritise further refinements -- though I\n    plan to continue advancing this work in the near future.\n  Mailing list thread:\n    https://lore.kernel.org/git/20250217055049.9217-1-meetsoni3017@gmail.com/\n\n* [Practice PATCH] refs: add list subcommand\n  Status: As PR on my fork\n  Description:\n    As it would’ve been inappropriate to send this patch to the mailing list\n    without getting selected in GSoC, I decided to push it to my fork in order\n    to showcase my abilities and get a better understanding of the project\n    scope by this proof-of-concept type of practice patch. This will be used\n    as a reference ahead.\n  PR link:\n    https://github.com/inosmeet/git/pull/1\n\n* Reviewed fellow contributors’ patches:\n  Mailing list threads:\n  * https://lore.kernel.org/git/CAPhwyn0tGHuX_Gh=rno9wj8fLb6zG4M3QAZyQDQ8qZyE+Uyg_Q@mail.gmail.com/\n  * https://lore.kernel.org/git/CAPhwyn2qeN_tZOEyhD6=TLEdQbcCEV1thxpDwNzApqaET0+5og@mail.gmail.com/\n  * https://lore.kernel.org/git/CAPhwyn03LbYexkk4YsaC6F2H_m6o73fU6aQ-c0urfdAsyEqPMg@mail.gmail.com/\n  * https://lore.kernel.org/git/CAPhwyn0Sq0hDktPtf53Qs6LKwNsmn6yXuVyEfcYzyXK4yjd7HA@mail.gmail.com/\n\n\nThe Project:\n------------\nCurrently, Git’s reference management is distributed among several commands,\nincluding git update-ref, git show-ref, git for-each-ref, git pack-refs, git\nsymbolic-ref and git check-ref-format. The functionality of these commands is\nimplemented using the functions from refs.[c|h]\n\nThis project aims to streamline reference management in Git by consolidating\nfunctionality currently spread across multiple commands into a single git-refs\ncommand. The project-idea page specifically mentions update-ref, show-ref,\nfor-each-ref, and pack-refs; therefore, this project will initially focus on\nthese four commands, with the remaining ones slated as stretch goals, more on\nthat below.\n\nThe updated git refs command will offer subcommands to list, retrieve,\nverify/check existence, write, and optimise references.\n\nSince the project involves developing new subcommands, selecting appropriate\nnames and addressing design considerations will be one of its primary\nchallenges.\n\n\nThe Plan:\n---------\nTo tackle this project, the consolidation of each command will be divided into\nthe following steps:\n\n    1. Create subcommands:\n      Develop the actual subcommand under  the refs\ncommand(builtin/refs file) by\n      leveraging core functions from the refs module. The implementation will\n      mimic the logic of the legacy commands to maintain consistency\nwith existing\n      behavior.\n    2. Tests:\n      Develop comprehensive tests to verify that the new subcommands function as\n      expected. This will involve creating a range of tests, including shell\n      scripts and/or unit tests located in the t/ directory. For the existing\n      tests covering the legacy commands targeted for consolidation, the plan is\n      to retain them initially—even if this results in some duplication—with the\n      intention of deprecating them gradually over time.\n    3. Update old usage:\n      Modify all call sites of the legacy commands to invoke the newly created\n      subcommands, ensuring a smooth transition and seamless integration with\n      the consolidated command.\n    4. Documentation:\n      Develop comprehensive documentation for the newly implemented\nsubcommands to\n      ensure clear guidance for users and maintainers.\n\n\nCommand mapping and naming:\n---------------------------\n\nI have taken reference for potential names for these subcommands from Patrick’s\nsuggestion (https://gitlab.com/gitlab-org/git/-/issues/330):\n\n  # Replaces git-show-ref(1) and git-for-each-ref(1).\n  $ git refs list\n\n  # Replaces `git show-ref --exists`.\n  $ git refs exist\n\n  # Replaces `git show-ref --verify <ref>`.\n  $ git refs show\n\n  # Replaces git-symbolic-ref(1) to show a ref.\n  $ git refs resolve\n\n  # Replaces git-pack-ref(1).\n  $ git refs pack\n\n  # Replaces git-update-ref(1).\n  $ git refs write\n\n  # Replaces git-check-ref-format(1).\n  $ git refs check-format\n\nBelow is a list of the commands along with their associated subcommands/flags\nthat need to be considered for consolidation under this project:\n\ngit show-ref -> git refs list\nUsed to list references in a local repository.\n* abbrev\n* branches\n* tags\n* exists\n* verify\n* exclude-existing\n* dereference\n* head\n* hash\n* quiet\n\n\ngit update-ref -> git refs update/write\nUsed to update the object name stored in a ref safely.\nSubcommands:\n* [symref-]update\n* [symref-]create\n* [symref-]delete\n* [symref-]verify\n* option\n* start\n* prepare\n* commit\n* Abort\nOptions/Flags:\n* --stdin\n* -m\n* -d\n* --no-deref\n* --create-reflog\n\n\ngit for-each-ref -> git refs list\nUsed to output information on each ref, quite similar to show-ref.\n* --count\n* --shell|--perl|--python|--tcl\n* --sort\n* --format\n* --include-root-refs\n* --points-at\n* --merged|--no-merged\n* --contains|--no-contains\n* --exclude\n* --ignore-case\n* --omit-empty\n\n\ngit pack-refs -> git refs pack\nUsed to pack heads and tags for efficient repository access.\n* --all\n* --no-prune\n* --auto\n* --include\n* --exclude\n\n\nOptions/Config sharing:\n-----------------------\nFor sharing configuration options, I propose a structure-based approach that\ncentralizes common options while grouping subcommand-specific settings into\ndedicated substructures. This design embeds common options directly in the\ntop-level configuration structure (struct refs_options), and then uses separate\nstructures (such as struct list_options) to encapsulate options unique to each\nsubcommand.\n\nBelow is a representative code snippet illustrating this approach:\n\nstruct refs_options {\n        ...\n        // ... Common Options …\n\n        struct list_options list_opts;\n             struct exist_options exist_opts;\n\n        // ... Similar fields for other subcommands ...\n        ...\n};\n\nstruct list_options {\n     // ... options specific to 'list' subcommand ...\n};\n\n\nstruct exist_options {\n     // ... options specific to 'exist' subcommand ...\n};\n\n\nSince we plan to maintain the legacy commands for the foreseeable future, we\nmust ensure backward compatibility while developing these new subcommands. Going\nthrough this I wonder if we should make the commands as a standalone\nentity, like\na library. However, it needs to be thoroughly discussed.\n\nWhile studying these commands, I thought why not try out one of them to better\nunderstand the project’s requirements, scope and get a firmer grip on the\ncodebase. So, I developed a reference implementation of git refs list that\nmimics the behaviour of git show-ref with [--head], [--branches|--heads] and\n[--tag] flags, which can be found (https://github.com/inosmeet/git/pull/1).\n\nAlthough this reference implementation is still a work in progress and not yet\nready for merging into master, it demonstrates my understanding of navigating\nthe Git codebase and the process of creating commands and subcommands. More\nimportantly, it indicates my ability to execute this project effectively.\n\n\nTimeline:\n---------\nPre-GSoC (Until May 8):\n* Continue to work on different things like the pending WIP patch that I have.\n  Be engaged/involved in the community.\n\nCommunity Bonding (May 8 - June 1):\n* Talk with mentors and discuss potential names for the new subcommands and\n  interface design. Start the consolidation early with mentors’ permission.\n\nPhase I (June 2 - 29 June):\n* Consolidate update-ref command along with subcommands/flags to refs… command.\n\nPhase II (30 June - 27 July):\n* Consolidate for-each-ref command along with subcommands/flags to refs…\n  command.\n\nPhase III (28 July - 24 August):\n* Consolidate show-ref and pack-refs command along with their subcommands/flags\n  to refs… command.\n\nFinal Week:\n* Some final touches. Make a final report about the work accomplished and\n  outline future work.\n\nI have not allocated separate timeline slots for tests and documentation, as\nthese will be integrated into the patches that introduce the new subcommands.\n\nI think if permitted to start early, I can consolidate one more command within\nthe GSoC period.\n\n\nRelated previous work:\n----------------------\n\ngit-switch Command:\nhttps://github.com/git/git/commit/d787d311\nMailing list thread:\nhttps://lore.kernel.org/git/20190130094831.10420-1-pclouds@gmail.com/\n\n\ngit-restore Command:\nhttps://github.com/git/git/commit/46e91b663badd99b3807ab34decfd32f3cbf15e7\nMailing list thread:\nhttps://lore.kernel.org/git/20190308101655.9767-2-pclouds@gmail.com/\n\n\nStretch goals:\n--------------\n\nIf the consolidation of the 4 commands is completed ahead of schedule, I would\nlike to consolidate the remaining commands (these can be done even after the\nGSoC period). These commands include git symbolic-ref and git check-ref-format.\n\nList of commands along with their subcommands/flags that needs to be considered\nfor consolidation:\n\ngit symbolic-ref -> git refs resolve\nUsed for reading or updating symbolic references.\n* -m\n* --delete\n* --quiet\n* --short\n* --recurse | --no-recurse\n\n\ngit check-ref-format -> git refs check-format\nUsed for validating whether a given reference adheres to Git’s naming\nconventions\nfor references.\n* --[no-]allow-onelevel\n* --normalize\n* --refspec-pattern\n* --branch\n\n\nBlogging:\n---------\n\nBlogging is a good way to foster transparency and community engagement in\nopen-source projects. By sharing insights, challenges, and milestones, blog\nposts not only document the project’s progress but also create opportunities for\nfeedback and collaboration from the broader community.\n\nIn my project, I plan to commit to bi-weekly blog posts. These updates will\ndetail my progress, share lessons learned, and highlight any obstacles\nencountered along the way, ensuring that the development process remains open\nand interactive.\n\nThe blog will be at: https://inosmeet.github.io\n\n\nPost-GSoC:\n----------\n\nOver the past three months, the Git community has been an invaluable source of\nsupport and learning, significantly contributing to my growth as a developer.\nEven after the summer program, I intend to stay active in the mailing list and\ncontinue contributing meaningful patches. I'm thinking of consolidating\nremaining commands after GSoC is over. I've also been following the early\nefforts to integrate Rust components into Git via libgit-sys, and I would be\nexcited to contribute to that initiative as it matures.\n\nLastly, if given the opportunity, I would be delighted to mentor new\ncontributors and help the community grow even further.\n\n\nSome credits to myself:\n-----------------------\n\nI am an open source enthusiast, I have contributed to some other open-source\nprojects as well. I was selected as a GSoC 2024 mentee for the Python Software\nFoundation’s cve-bin-tool sub-organization where I worked on improving Product\nmapping using PURLs (Package URLs).\n\nMore recently, I got selected as a LFX 2025 term-1 mentee for Cloud Native\nComputing Foundation’s Microcks sub-organization. Here I’m working on improving\nMicrocks’ delivery and validation using GitHub Actions CI deployment tests.\n\nThese opportunities have given me valuable initial exposure to open source\npractices and community collaboration, and I’m excited to further build my\nskills while contributing fresh ideas to this project.\n\nBlogs for both my GSoC as well as LFX journey can be found at my blog site:\nhttps://inosmeet.github.io/posts\n\n\nAvailability:\n-------------\n\nMy current semester ends on 24th April and my exam tentatively on 15th May,\nleaving me enough time to prepare for my GSoC project. If I am selected, I shall\nbe able to work five days per week, 7 - 8 hours per day, dedicating around 35-40\nhrs a week on the project.\n\nThe difficulty level of this project is medium, and the expected project size is\nestimated to require about 350 hours of work. Based on my proposed commitment of\n35-40 hours per week, this project aligns with my availability and intended\nworkload for the GSoC period, ensuring that I have sufficient time to\naccommodate any unforeseen circumstances that may arise during the project.\n\n---\nThank you for considering my application. I am excited about the possibility of\ncontributing to this project and learning from the mentorship experience.\n\nThanks & Regards,\nMeet\n"},{"id":"515490","messageId":"Z-zzbOrZde8B1kA6@pks.im","threadId":"63229","inReplyTo":"CAPhwyn3McL-2rwjkexsDUWqxt0Kr4UsDVy_G=s1DmKhrw5BZ-A@mail.gmail.com","subject":"Re: [GSoC][Proposal RFC] Consolidate ref-related functionality into git-refs","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-02T08:21:00Z","receivedAt":"2025-04-02T08:21:09Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Tue, Apr 01, 2025 at 07:07:21AM +0530, Meet Soni wrote:\n> GSoC 2025 @ Git | Meet Soni\n> Consolidate ref-related functionality into git-refs\n> ---------------------------------------------------\n> \n> \n> Personal Information:\n> ---------------------\n> Name: Meet Soni\n> E-mail: meetsoni3017@gmail.com\n> Mobile No.: +91 9054520887\n> \n> Education: Silver Oak University, Gujarat, India\n> Year: III/IV\n> Degree: Bachelors in Computer Engineering\n> \n> Time-Zone: UTC + 5:30 (IST)\n> GitHub: github.com/inosmeet\n> Blog: inosmeet.github.io\n> LinkedIn: https://www.linkedin.com/in/meet-soni-4230701b9/\n> \n> \n> Pre-GSoC:\n> ---------\n> \n> I got into Git’s codebase in November 2024 by reviewing various documentations,\n> previous patches and began contributing in mid-December 2024.\n> \n> Following is the list of contributions that I have made:\n\nQuite an impressive list.\n\n> The Project:\n> ------------\n> Currently, Git’s reference management is distributed among several commands,\n> including git update-ref, git show-ref, git for-each-ref, git pack-refs, git\n> symbolic-ref and git check-ref-format. The functionality of these commands is\n> implemented using the functions from refs.[c|h]\n> \n> This project aims to streamline reference management in Git by consolidating\n> functionality currently spread across multiple commands into a single git-refs\n> command. The project-idea page specifically mentions update-ref, show-ref,\n> for-each-ref, and pack-refs; therefore, this project will initially focus on\n> these four commands, with the remaining ones slated as stretch goals, more on\n> that below.\n> \n> The updated git refs command will offer subcommands to list, retrieve,\n> verify/check existence, write, and optimise references.\n> \n> Since the project involves developing new subcommands, selecting appropriate\n> names and addressing design considerations will be one of its primary\n> challenges.\n> \n> \n> The Plan:\n> ---------\n> To tackle this project, the consolidation of each command will be divided into\n> the following steps:\n> \n>     1. Create subcommands:\n>       Develop the actual subcommand under  the refs\n> command(builtin/refs file) by\n>       leveraging core functions from the refs module. The implementation will\n>       mimic the logic of the legacy commands to maintain consistency\n> with existing\n>       behavior.\n\nIt should mimic existing commands where it makes sense indeed, but we\nshould also consider whether there is opportunity for improvement. That\nis of course a harder question to answer, but I'm sure that we will find\nsome subcommands where it would make sense to break with existing\nbehaviour.\n\n>     2. Tests:\n>       Develop comprehensive tests to verify that the new subcommands function as\n>       expected. This will involve creating a range of tests, including shell\n>       scripts and/or unit tests located in the t/ directory. For the existing\n>       tests covering the legacy commands targeted for consolidation, the plan is\n>       to retain them initially—even if this results in some duplication—with the\n>       intention of deprecating them gradually over time.\n>     3. Update old usage:\n>       Modify all call sites of the legacy commands to invoke the newly created\n>       subcommands, ensuring a smooth transition and seamless integration with\n>       the consolidated command.\n\nThis would be nice indeed, but it's not necessary as part of the GSoC\nproject from my point of view. The old commands won't go away anytime\nsoon as they are extensively used in scripts outside of our control.\n\n>     4. Documentation:\n>       Develop comprehensive documentation for the newly implemented\n> subcommands to\n>       ensure clear guidance for users and maintainers.\n> \n> \n> Command mapping and naming:\n> ---------------------------\n> \n> I have taken reference for potential names for these subcommands from Patrick’s\n> suggestion (https://gitlab.com/gitlab-org/git/-/issues/330):\n> \n>   # Replaces git-show-ref(1) and git-for-each-ref(1).\n>   $ git refs list\n> \n>   # Replaces `git show-ref --exists`.\n>   $ git refs exist\n> \n>   # Replaces `git show-ref --verify <ref>`.\n>   $ git refs show\n> \n>   # Replaces git-symbolic-ref(1) to show a ref.\n>   $ git refs resolve\n> \n>   # Replaces git-pack-ref(1).\n>   $ git refs pack\n\nAs I suggested elsewhere already, I think `git refs optimize` would be a\nbetter name. The verb \"packing\" mostly stems from the \"files\" backend,\nwhere loose files are indeed moved into a \"packed-refs\" file. But with\nthe \"reftable\" backend that name makes less sense.\n\n>   # Replaces git-update-ref(1).\n>   $ git refs write\n> \n>   # Replaces git-check-ref-format(1).\n>   $ git refs check-format\n\nI think this one could be improved, as well, as it doesn't quite\nindicate what format you're checking. \"check-name\" might be a better\nfit.\n\n[snip]\n> Options/Config sharing:\n> -----------------------\n> For sharing configuration options, I propose a structure-based approach that\n> centralizes common options while grouping subcommand-specific settings into\n> dedicated substructures. This design embeds common options directly in the\n> top-level configuration structure (struct refs_options), and then uses separate\n> structures (such as struct list_options) to encapsulate options unique to each\n> subcommand.\n> \n> Below is a representative code snippet illustrating this approach:\n> \n> struct refs_options {\n>         ...\n>         // ... Common Options …\n> \n>         struct list_options list_opts;\n>              struct exist_options exist_opts;\n> \n>         // ... Similar fields for other subcommands ...\n>         ...\n> };\n\nThe other structures probably do make sense, but I don't think it makes\nsense to have a structure that summarizes all of them. If there are\ncommon options that will need handling for all of the subcommands (are\nthere?) then I'd rather go the other way round and introduce a\n`refs_common_options` structure that gets embedded in e.g.\n`list_options`.\n\n> struct list_options {\n>      // ... options specific to 'list' subcommand ...\n> };\n> \n> \n> struct exist_options {\n>      // ... options specific to 'exist' subcommand ...\n> };\n> \n> \n> Since we plan to maintain the legacy commands for the foreseeable future, we\n> must ensure backward compatibility while developing these new subcommands. Going\n> through this I wonder if we should make the commands as a standalone\n> entity, like\n> a library. However, it needs to be thoroughly discussed.\n\nMuch of the functionality probably already is somewhat encapsulated,\nit's mostly the option handling that we'll have to unify somehow. In any\ncase I expect that the exact mechanism will vary between the different\nsubcommands and it's fine to decide on a case-by-case basis once you\nstart to implement them.\n\n> While studying these commands, I thought why not try out one of them to better\n> understand the project’s requirements, scope and get a firmer grip on the\n> codebase. So, I developed a reference implementation of git refs list that\n> mimics the behaviour of git show-ref with [--head], [--branches|--heads] and\n> [--tag] flags, which can be found (https://github.com/inosmeet/git/pull/1).\n> \n> Although this reference implementation is still a work in progress and not yet\n> ready for merging into master, it demonstrates my understanding of navigating\n> the Git codebase and the process of creating commands and subcommands. More\n> importantly, it indicates my ability to execute this project effectively.\n\nNice :)\n\n> Timeline:\n> ---------\n> Pre-GSoC (Until May 8):\n> * Continue to work on different things like the pending WIP patch that I have.\n>   Be engaged/involved in the community.\n> \n> Community Bonding (May 8 - June 1):\n> * Talk with mentors and discuss potential names for the new subcommands and\n>   interface design. Start the consolidation early with mentors’ permission.\n> \n> Phase I (June 2 - 29 June):\n> * Consolidate update-ref command along with subcommands/flags to refs… command.\n> \n> Phase II (30 June - 27 July):\n> * Consolidate for-each-ref command along with subcommands/flags to refs…\n>   command.\n> \n> Phase III (28 July - 24 August):\n> * Consolidate show-ref and pack-refs command along with their subcommands/flags\n>   to refs… command.\n\nPart of what git-show-ref(1) does is also covered by\ngit-for-each-ref(1). So it would probably make sense to implement those\ntwo parts in a specific phase, but single out the non-shared parts (e.g.\nthe `--exists` flag) into a separate phase.\n\nAlso, given that you've already started to work on git-show-ref(1) a\nbit, wouldn't it make sense to move that to phase I?\n\n> Final Week:\n> * Some final touches. Make a final report about the work accomplished and\n>   outline future work.\n> \n> I have not allocated separate timeline slots for tests and documentation, as\n> these will be integrated into the patches that introduce the new subcommands.\n> \n> I think if permitted to start early, I can consolidate one more command within\n> the GSoC period.\n\nWe cannot keep you from doing this, but please keep in mind that if we\nend up picking a different candidate for this project we would favor\ntheir work so that they can successfully finish GSoC. So I would\ndefinitely wait until you've been selected before starting to work on\nanything.\n\nThanks for your interest!\n\nPatrick\n"},{"id":"515573","messageId":"CAPhwyn2GugzXg5LgcdMGjrvP9kAvCFj31RXrUpp7ZJdoGfiyKA@mail.gmail.com","threadId":"63229","inReplyTo":"Z-zzbOrZde8B1kA6@pks.im","subject":"Re: [GSoC][Proposal RFC] Consolidate ref-related functionality into git-refs","fromName":"Meet Soni","fromEmail":"meetsoni3017@gmail.com","sentAt":"2025-04-03T10:05:09Z","receivedAt":"2025-04-03T10:05:21Z","isPatch":false,"sender":{"key":"meetsoni3017@gmail.com","avatar":"https://avatars.githubusercontent.com/u/92802561?v=4"},"body":"On Wed, 2 Apr 2025 at 13:51, Patrick Steinhardt <ps@pks.im> wrote:\n>\n> On Tue, Apr 01, 2025 at 07:07:21AM +0530, Meet Soni wrote:\n[snip]\n> > The Plan:\n> > ---------\n> > To tackle this project, the consolidation of each command will be divided into\n> > the following steps:\n> >\n> >     1. Create subcommands:\n> >       Develop the actual subcommand under  the refs\n> > command(builtin/refs file) by\n> >       leveraging core functions from the refs module. The implementation will\n> >       mimic the logic of the legacy commands to maintain consistency\n> > with existing\n> >       behavior.\n>\n> It should mimic existing commands where it makes sense indeed, but we\n> should also consider whether there is opportunity for improvement. That\n> is of course a harder question to answer, but I'm sure that we will find\n> some subcommands where it would make sense to break with existing\n> behaviour.\n>\nMakes sense. I'll reflect this in the upcoming version.\n\n> >     2. Tests:\n> >       Develop comprehensive tests to verify that the new subcommands function as\n> >       expected. This will involve creating a range of tests, including shell\n> >       scripts and/or unit tests located in the t/ directory. For the existing\n> >       tests covering the legacy commands targeted for consolidation, the plan is\n> >       to retain them initially—even if this results in some duplication—with the\n> >       intention of deprecating them gradually over time.\n> >     3. Update old usage:\n> >       Modify all call sites of the legacy commands to invoke the newly created\n> >       subcommands, ensuring a smooth transition and seamless integration with\n> >       the consolidated command.\n>\n> This would be nice indeed, but it's not necessary as part of the GSoC\n> project from my point of view. The old commands won't go away anytime\n> soon as they are extensively used in scripts outside of our control.\n>\nI wonder if this is a better candidate for \"Post GSoC\" section maybe?\n\n> >     4. Documentation:\n> >       Develop comprehensive documentation for the newly implemented\n> > subcommands to\n> >       ensure clear guidance for users and maintainers.\n> >\n> >\n> > Command mapping and naming:\n> > ---------------------------\n> >\n> > I have taken reference for potential names for these subcommands from Patrick’s\n> > suggestion (https://gitlab.com/gitlab-org/git/-/issues/330):\n> >\n> >   # Replaces git-show-ref(1) and git-for-each-ref(1).\n> >   $ git refs list\n> >\n> >   # Replaces `git show-ref --exists`.\n> >   $ git refs exist\n> >\n> >   # Replaces `git show-ref --verify <ref>`.\n> >   $ git refs show\n> >\n> >   # Replaces git-symbolic-ref(1) to show a ref.\n> >   $ git refs resolve\n> >\n> >   # Replaces git-pack-ref(1).\n> >   $ git refs pack\n>\n> As I suggested elsewhere already, I think `git refs optimize` would be a\n> better name. The verb \"packing\" mostly stems from the \"files\" backend,\n> where loose files are indeed moved into a \"packed-refs\" file. But with\n> the \"reftable\" backend that name makes less sense.\n>\n> >   # Replaces git-update-ref(1).\n> >   $ git refs write\n> >\n> >   # Replaces git-check-ref-format(1).\n> >   $ git refs check-format\n>\n> I think this one could be improved, as well, as it doesn't quite\n> indicate what format you're checking. \"check-name\" might be a better\n> fit.\n>\nYeah, makes sense; I'll reflect this in the upcoming version.\n\n> [snip]\n> > Options/Config sharing:\n> > -----------------------\n> > For sharing configuration options, I propose a structure-based approach that\n> > centralizes common options while grouping subcommand-specific settings into\n> > dedicated substructures. This design embeds common options directly in the\n> > top-level configuration structure (struct refs_options), and then uses separate\n> > structures (such as struct list_options) to encapsulate options unique to each\n> > subcommand.\n> >\n> > Below is a representative code snippet illustrating this approach:\n> >\n> > struct refs_options {\n> >         ...\n> >         // ... Common Options …\n> >\n> >         struct list_options list_opts;\n> >              struct exist_options exist_opts;\n> >\n> >         // ... Similar fields for other subcommands ...\n> >         ...\n> > };\n>\n> The other structures probably do make sense, but I don't think it makes\n> sense to have a structure that summarizes all of them. If there are\n> common options that will need handling for all of the subcommands (are\n> there?) then I'd rather go the other way round and introduce a\n> `refs_common_options` structure that gets embedded in e.g.\n> `list_options`.\n>\nOkay. I'll update this in the upcoming version.\nIn terms of common options, there are a few that come to mind--such as\n--quiet, -m, and --branch.\n> > struct list_options {\n> >      // ... options specific to 'list' subcommand ...\n> > };\n> >\n> >\n> > struct exist_options {\n> >      // ... options specific to 'exist' subcommand ...\n> > };\n> >\n> >\n> > Since we plan to maintain the legacy commands for the foreseeable future, we\n> > must ensure backward compatibility while developing these new subcommands. Going\n> > through this I wonder if we should make the commands as a standalone\n> > entity, like\n> > a library. However, it needs to be thoroughly discussed.\n>\n> Much of the functionality probably already is somewhat encapsulated,\n> it's mostly the option handling that we'll have to unify somehow. In any\n> case I expect that the exact mechanism will vary between the different\n> subcommands and it's fine to decide on a case-by-case basis once you\n> start to implement them.\n>\n> > While studying these commands, I thought why not try out one of them to better\n> > understand the project’s requirements, scope and get a firmer grip on the\n> > codebase. So, I developed a reference implementation of git refs list that\n> > mimics the behaviour of git show-ref with [--head], [--branches|--heads] and\n> > [--tag] flags, which can be found (https://github.com/inosmeet/git/pull/1).\n> >\n> > Although this reference implementation is still a work in progress and not yet\n> > ready for merging into master, it demonstrates my understanding of navigating\n> > the Git codebase and the process of creating commands and subcommands. More\n> > importantly, it indicates my ability to execute this project effectively.\n>\n> Nice :)\n>\n> > Timeline:\n> > ---------\n> > Pre-GSoC (Until May 8):\n> > * Continue to work on different things like the pending WIP patch that I have.\n> >   Be engaged/involved in the community.\n> >\n> > Community Bonding (May 8 - June 1):\n> > * Talk with mentors and discuss potential names for the new subcommands and\n> >   interface design. Start the consolidation early with mentors’ permission.\n> >\n> > Phase I (June 2 - 29 June):\n> > * Consolidate update-ref command along with subcommands/flags to refs… command.\n> >\n> > Phase II (30 June - 27 July):\n> > * Consolidate for-each-ref command along with subcommands/flags to refs…\n> >   command.\n> >\n> > Phase III (28 July - 24 August):\n> > * Consolidate show-ref and pack-refs command along with their subcommands/flags\n> >   to refs… command.\n>\n> Part of what git-show-ref(1) does is also covered by\n> git-for-each-ref(1). So it would probably make sense to implement those\n> two parts in a specific phase, but single out the non-shared parts (e.g.\n> the `--exists` flag) into a separate phase.\n>\n> Also, given that you've already started to work on git-show-ref(1) a\n> bit, wouldn't it make sense to move that to phase I?\n>\nBoth of these suggestions make sense. I'll update this :)\n> > Final Week:\n> > * Some final touches. Make a final report about the work accomplished and\n> >   outline future work.\n> >\n> > I have not allocated separate timeline slots for tests and documentation, as\n> > these will be integrated into the patches that introduce the new subcommands.\n> >\n> > I think if permitted to start early, I can consolidate one more command within\n> > the GSoC period.\n>\n> We cannot keep you from doing this, but please keep in mind that if we\n> end up picking a different candidate for this project we would favor\n> their work so that they can successfully finish GSoC. So I would\n> definitely wait until you've been selected before starting to work on\n> anything.\n>\nI completely understand. Just to clarify, I meant that if I'm fortunate enough\nto be selected, I’d be eager to start contributing during the community\nbonding period--only if it's allowed--so that I can try to consolidate one more\ncommand within the GSoC period.\n\n> Thanks for your interest!\n>\n> Patrick\n\nThank you for reviewing :)\nMeet\n"},{"id":"515576","messageId":"Z-5itjoHBV-dEPwU@pks.im","threadId":"63229","inReplyTo":"CAPhwyn2GugzXg5LgcdMGjrvP9kAvCFj31RXrUpp7ZJdoGfiyKA@mail.gmail.com","subject":"Re: [GSoC][Proposal RFC] Consolidate ref-related functionality into git-refs","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-03T10:28:06Z","receivedAt":"2025-04-03T10:28:10Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Apr 03, 2025 at 03:35:09PM +0530, Meet Soni wrote:\n> On Wed, 2 Apr 2025 at 13:51, Patrick Steinhardt <ps@pks.im> wrote:\n> > On Tue, Apr 01, 2025 at 07:07:21AM +0530, Meet Soni wrote:\n> > >     2. Tests:\n> > >       Develop comprehensive tests to verify that the new subcommands function as\n> > >       expected. This will involve creating a range of tests, including shell\n> > >       scripts and/or unit tests located in the t/ directory. For the existing\n> > >       tests covering the legacy commands targeted for consolidation, the plan is\n> > >       to retain them initially—even if this results in some duplication—with the\n> > >       intention of deprecating them gradually over time.\n> > >     3. Update old usage:\n> > >       Modify all call sites of the legacy commands to invoke the newly created\n> > >       subcommands, ensuring a smooth transition and seamless integration with\n> > >       the consolidated command.\n> >\n> > This would be nice indeed, but it's not necessary as part of the GSoC\n> > project from my point of view. The old commands won't go away anytime\n> > soon as they are extensively used in scripts outside of our control.\n> >\n> I wonder if this is a better candidate for \"Post GSoC\" section maybe?\n\nPotentially, yeah. It doesn't really have to be part of the proposal in\nthe first place from my point of view, but having a section about future\nwork after the GSoC wouldn't hurt, either.\n\n> > > I think if permitted to start early, I can consolidate one more command within\n> > > the GSoC period.\n> >\n> > We cannot keep you from doing this, but please keep in mind that if we\n> > end up picking a different candidate for this project we would favor\n> > their work so that they can successfully finish GSoC. So I would\n> > definitely wait until you've been selected before starting to work on\n> > anything.\n> >\n> I completely understand. Just to clarify, I meant that if I'm fortunate enough\n> to be selected, I’d be eager to start contributing during the community\n> bonding period--only if it's allowed--so that I can try to consolidate one more\n> command within the GSoC period.\n\nWe won't give you a strict time schedule of \"you first do that and then\ndo that\". Only thing that I'd like to avoid is that you're basically\nalready done before the project starts ;)\n\nI'd just define these additinoal subcommands as stretch goals and then\nit's fine.\n\nPatrick\n"},{"id":"515660","messageId":"CAOLa=ZQ4nTP7Ls=JsnQSbvpvw+OhjXqqoQxpsTKA0x-HxaDH5A@mail.gmail.com","threadId":"63229","inReplyTo":"CAPhwyn3McL-2rwjkexsDUWqxt0Kr4UsDVy_G=s1DmKhrw5BZ-A@mail.gmail.com","subject":"Re: [GSoC][Proposal RFC] Consolidate ref-related functionality into git-refs","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2025-04-04T11:46:58Z","receivedAt":"2025-04-04T11:46:59Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Meet Soni <meetsoni3017@gmail.com> writes:\n\n[snip]\n\n> Command mapping and naming:\n> ---------------------------\n>\n> I have taken reference for potential names for these subcommands from Patrick’s\n> suggestion (https://gitlab.com/gitlab-org/git/-/issues/330):\n>\n>   # Replaces git-show-ref(1) and git-for-each-ref(1).\n>   $ git refs list\n>\n>   # Replaces `git show-ref --exists`.\n>   $ git refs exist\n>\n>   # Replaces `git show-ref --verify <ref>`.\n>   $ git refs show\n>\n>   # Replaces git-symbolic-ref(1) to show a ref.\n>   $ git refs resolve\n>\n>   # Replaces git-pack-ref(1).\n>   $ git refs pack\n>\n>   # Replaces git-update-ref(1).\n>   $ git refs write\n>\n>   # Replaces git-check-ref-format(1).\n>   $ git refs check-format\n>\n\nOne other command that I noticed, which we didn't talk about it 'git\nreflog'. I would think, it would be nice to also fit this as 'git refs\nlogs', but it doesn't have to be part of GSoC.\n\n> Below is a list of the commands along with their associated subcommands/flags\n> that need to be considered for consolidation under this project:\n>\n> git show-ref -> git refs list\n> Used to list references in a local repository.\n> * abbrev\n> * branches\n> * tags\n> * exists\n> * verify\n> * exclude-existing\n> * dereference\n> * head\n> * hash\n> * quiet\n>\n>\n> git update-ref -> git refs update/write\n> Used to update the object name stored in a ref safely.\n> Subcommands:\n> * [symref-]update\n> * [symref-]create\n> * [symref-]delete\n> * [symref-]verify\n> * option\n> * start\n> * prepare\n> * commit\n> * Abort\n> Options/Flags:\n> * --stdin\n> * -m\n> * -d\n> * --no-deref\n> * --create-reflog\n>\n\nOne of the issues we had with 'git update-ref' was that it wasn't\ninitially built with symref compatibility with mind, which is why we\nhad to add 'symref-*' as new subcommands. This time, we can fix that and\nreduce the surface of subcommands.\n\n[snip]\n\nI agree with Patricks comments already. Just wanted to comment on some\nadditional points. Thanks for the proposal.\n\n- Karthik\n"},{"id":"515661","messageId":"Z-_HBe1lOu6_oRbr@pks.im","threadId":"63229","inReplyTo":"CAOLa=ZQ4nTP7Ls=JsnQSbvpvw+OhjXqqoQxpsTKA0x-HxaDH5A@mail.gmail.com","subject":"Re: [GSoC][Proposal RFC] Consolidate ref-related functionality into git-refs","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-04-04T11:48:21Z","receivedAt":"2025-04-04T11:48:26Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, Apr 04, 2025 at 04:46:58AM -0700, Karthik Nayak wrote:\n> Meet Soni <meetsoni3017@gmail.com> writes:\n> \n> [snip]\n> \n> > Command mapping and naming:\n> > ---------------------------\n> >\n> > I have taken reference for potential names for these subcommands from Patrick’s\n> > suggestion (https://gitlab.com/gitlab-org/git/-/issues/330):\n> >\n> >   # Replaces git-show-ref(1) and git-for-each-ref(1).\n> >   $ git refs list\n> >\n> >   # Replaces `git show-ref --exists`.\n> >   $ git refs exist\n> >\n> >   # Replaces `git show-ref --verify <ref>`.\n> >   $ git refs show\n> >\n> >   # Replaces git-symbolic-ref(1) to show a ref.\n> >   $ git refs resolve\n> >\n> >   # Replaces git-pack-ref(1).\n> >   $ git refs pack\n> >\n> >   # Replaces git-update-ref(1).\n> >   $ git refs write\n> >\n> >   # Replaces git-check-ref-format(1).\n> >   $ git refs check-format\n> >\n> \n> One other command that I noticed, which we didn't talk about it 'git\n> reflog'. I would think, it would be nice to also fit this as 'git refs\n> logs', but it doesn't have to be part of GSoC.\n\nWouldn't that become awkward though as you now basically have\nsubsubcommands? `git refs log expire`, `git refs log exists` and\nrelated.\n\nPatrick\n"},{"id":"515662","messageId":"CAOLa=ZTuyng6BSBsfr0Wcb9Fh9b+a-AJ3g5wdKMVeFaJYKMREQ@mail.gmail.com","threadId":"63229","inReplyTo":"Z-_HBe1lOu6_oRbr@pks.im","subject":"Re: [GSoC][Proposal RFC] Consolidate ref-related functionality into git-refs","fromName":"Karthik Nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2025-04-04T11:52:48Z","receivedAt":"2025-04-04T11:52:50Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> On Fri, Apr 04, 2025 at 04:46:58AM -0700, Karthik Nayak wrote:\n>> Meet Soni <meetsoni3017@gmail.com> writes:\n>>\n>> [snip]\n>>\n>> > Command mapping and naming:\n>> > ---------------------------\n>> >\n>> > I have taken reference for potential names for these subcommands from Patrick’s\n>> > suggestion (https://gitlab.com/gitlab-org/git/-/issues/330):\n>> >\n>> >   # Replaces git-show-ref(1) and git-for-each-ref(1).\n>> >   $ git refs list\n>> >\n>> >   # Replaces `git show-ref --exists`.\n>> >   $ git refs exist\n>> >\n>> >   # Replaces `git show-ref --verify <ref>`.\n>> >   $ git refs show\n>> >\n>> >   # Replaces git-symbolic-ref(1) to show a ref.\n>> >   $ git refs resolve\n>> >\n>> >   # Replaces git-pack-ref(1).\n>> >   $ git refs pack\n>> >\n>> >   # Replaces git-update-ref(1).\n>> >   $ git refs write\n>> >\n>> >   # Replaces git-check-ref-format(1).\n>> >   $ git refs check-format\n>> >\n>>\n>> One other command that I noticed, which we didn't talk about it 'git\n>> reflog'. I would think, it would be nice to also fit this as 'git refs\n>> logs', but it doesn't have to be part of GSoC.\n>\n> Wouldn't that become awkward though as you now basically have\n> subsubcommands? `git refs log expire`, `git refs log exists` and\n> related.\n\nGood point! I was thinking from consolidating all reference logic under\none command, but perhaps treating 'reflog' as its own entity is more\nsensible and best to leave 'git reflog' as is.\n\n> Patrick\n"},{"id":"515665","messageId":"CAPhwyn1bWWWW=AmRuVuFfoXk9D2rphh_sEwYWQr+5Kgh845JYQ@mail.gmail.com","threadId":"63229","inReplyTo":"CAOLa=ZTuyng6BSBsfr0Wcb9Fh9b+a-AJ3g5wdKMVeFaJYKMREQ@mail.gmail.com","subject":"Re: [GSoC][Proposal RFC v2] Consolidate ref-related functionality into git-refs","fromName":"Meet Soni","fromEmail":"meetsoni3017@gmail.com","sentAt":"2025-04-04T12:24:19Z","receivedAt":"2025-04-04T12:24:31Z","isPatch":false,"sender":{"key":"meetsoni3017@gmail.com","avatar":"https://avatars.githubusercontent.com/u/92802561?v=4"},"body":"Hi Everyone,\nThis is my proposal for \"Consolidate ref-related functionality into\ngit-refs\" in Google Summer of Code 2025. The Doc version:\nhttps://docs.google.com/document/d/1Nfg6Dner1eU10LIlhkSJ5-N31Y6QuWj8bad_bAiMBa8/edit?usp=sharing\n\nI'd appreciate any feedback on this.\n\nThanks,\nMeet\n\n---------8<----------8<----------8<----------8<----------8<----------8<----------8<----------8<\nGSoC 2025 @ Git | Meet Soni\nConsolidate ref-related functionality into git-refs\n---------------------------------------------------\n\n\nPersonal Information:\n---------------------\nName: Meet Soni\nE-mail: meetsoni3017@gmail.com\nMobile No.: +91 9054520887\n\nEducation: Silver Oak University, Gujarat, India\nYear: III/IV\nDegree: Bachelors in Computer Engineering\n\nTime-Zone: UTC + 5:30 (IST)\nGitHub: github.com/inosmeet\nBlog: inosmeet.github.io\nLinkedIn: https://www.linkedin.com/in/meet-soni-4230701b9/\n\n\nPre-GSoC:\n---------\n\nI got into Git’s codebase in November 2024 by reviewing various documentations,\nprevious patches and began contributing in mid-December 2024.\n\nFollowing is the list of contributions that I have made:\n\n* [PATCH v3] t7611: replace test -f with test_path_is* helpers\n  Status: Merged into master\n  Merge commit:cef3d4a89f8d21fae6669822cbb540927020d93b\n  Description:\n    This patch is my first contribution to fulfill microproject criteria. It\n    improves test t7611-merge-abort.sh by converting old style path\nchecks to use\n    modern helper functions in order to achieve better debuggability.\n  Mailing list thread:\n    https://lore.kernel.org/git/20241227105345.10184-1-meetsoni3017@gmail.com/\n\n* [GSoC][PATCH v4 0/5] refspec: centralize refspec-related logic\n  Status: Merged into master\n  Merge Commit: e4f6ab008522c5ad386485720770b8d03b4fb880\n  Description:\n    This patch series addresses a design inconsistency noted by Patrick, where\n    the refspec-related logic was scattered across multiple headers, by renaming\n    and relocating this logic for improved cohesion. In particular, functions\n    such as omit_name_by_refspec() have been renamed to better reflect their\n    intended functionality, and the core refspec-related routines have been\n    moved from remote.c into a dedicated refspec.c file, ensuring a clear\n    separation of concerns and more maintainable code.\n  Mailing list thread:\n    https://lore.kernel.org/git/20250204040558.34766-1-meetsoni3017@gmail.com/\n\n* [GSoC][PATCH v2] remote: relocate valid_remote_name\n  Status: Merged into master\n  Merge Commit: f21ea69d945f958704f2fe143c2638ecae6e0d12\n  Description:\n    This patch, prompted by Junio's feedback in my previous patch series,\n    moves the valid_remote_name() function from refspec to remote to\n    centralize functionality related to remote repositories, thereby\n    maintaining a clearer separation of concerns.\n  Mailing list thread:\n    https://lore.kernel.org/git/20250204142852.13035-1-meetsoni3017@gmail.com\n\n* [GSoC][PATCH v2] merge-recursive: optimize time complexity for process_renames\n  Status: Merged into master\n  Merge Commit: b07dd9078b8ba5f3b7f5c88f84f7ee9c34fa65e1\n  Description:\n    This patch reduces time complexity for process_renames() from O(n^2) to\n    O(n log n) when building a sorted string_list by constructing it unsorted\n    and sorting it afterward, thereby addressing a previously noted TODO\n    comment.\n  Mailing list thread:\n    https://lore.kernel.org/git/20250214044129.15282-1-meetsoni3017@gmail.com/\n\n* [GSoC][PATCH v2] refspec: clarify function naming and documentation\n  Status: Merged into master\n  Merge Commit: 044b6f04f23d6c7e3c3750c9829db96b71470874\n  Description:\n    This patch renames a function and its parameters to improve clarity and\n    consistency in refspec matching, addressing earlier feedback from Junio to\n    resolve documentation ambiguities and enhance overall code readability.\n  Mailing list thread:\n    https://lore.kernel.org/git/20250215084539.73799-1-meetsoni3017@gmail.com\n\n* [GSoC PATCH v5 0/3] reftable: return proper error codes from block_writer_add\n  Status: Merged into next\n  Merge Commit: 27571684ddca217d65c5f39947f20b9f5ec91863 (next)\n  Description:\n    This patch series refines error handling by eliminating assumptions about\n    the error codes returned by block_writer_add(), a change motivated by a\n    TODO comment to ensure more robust and flexible behavior.\n  Mailing list thread:\n    https://lore.kernel.org/git/20250319152927.1263033-1-meetsoni3017@gmail.com\n\n* [GSoC][RFC PATCH] show-branch: use commit-slab for flag storage\n  Status: On-hold from my side\n  Description:\n    This patch attempts to replace direct access to commit->object.flags with\n    a commit-slab mechanism by introducing get_commit_flags() and\n    set_commit_flags() for flag management and ensuring the canonical\n    UNINTERESTING definition is used. Initially prompted by a TODO comment,\n    review feedback broadened the scope to address several additional aspects\n    that were new to me; while further investigating these changes, I was\n    selected for LFX mentorship, which resulted in increased time constraints\n    and so I had to temporarily deprioritise further refinements -- though I\n    plan to continue advancing this work in the near future.\n  Mailing list thread:\n    https://lore.kernel.org/git/20250217055049.9217-1-meetsoni3017@gmail.com/\n\n* [Practice PATCH] refs: add list subcommand\n  Status: As PR on my fork\n  Description:\n    As it would’ve been inappropriate to send this patch to the mailing list\n    without getting selected in GSoC, I decided to push it to my fork in order\n    to showcase my abilities and get a better understanding of the project\n    scope by this proof-of-concept type of practice patch. This will be used\n    as a reference ahead.\n  PR link:\n    https://github.com/inosmeet/git/pull/1\n\n* Reviewed fellow contributors’ patches:\n  Mailing list threads:\n  * https://lore.kernel.org/git/CAPhwyn0tGHuX_Gh=rno9wj8fLb6zG4M3QAZyQDQ8qZyE+Uyg_Q@mail.gmail.com/\n  * https://lore.kernel.org/git/CAPhwyn2qeN_tZOEyhD6=TLEdQbcCEV1thxpDwNzApqaET0+5og@mail.gmail.com/\n  * https://lore.kernel.org/git/CAPhwyn03LbYexkk4YsaC6F2H_m6o73fU6aQ-c0urfdAsyEqPMg@mail.gmail.com/\n  * https://lore.kernel.org/git/CAPhwyn0Sq0hDktPtf53Qs6LKwNsmn6yXuVyEfcYzyXK4yjd7HA@mail.gmail.com/\n\n\nThe Project:\n------------\nCurrently, Git’s reference management is distributed among several commands,\nincluding git update-ref, git show-ref, git for-each-ref, git pack-refs, git\nsymbolic-ref and git check-ref-format. The functionality of these commands is\nimplemented using the functions from refs.[c|h]\n\nThis project aims to streamline reference management in Git by consolidating\nfunctionality currently spread across multiple commands into a single git-refs\ncommand. The project-idea page specifically mentions update-ref, show-ref,\nfor-each-ref, and pack-refs; therefore, this project will initially focus on\nthese four commands, with the remaining ones slated as stretch goals, more on\nthat below.\n\nThe updated git refs command will offer subcommands to list, retrieve,\nverify/check existence, write, and optimise references.\n\nSince the project involves developing new subcommands, selecting appropriate\nnames and addressing design considerations will be one of its primary\nchallenges.\n\n\nThe Plan:\n---------\nTo tackle this project, the consolidation of each command will be divided into\nthe following steps:\n\n    1. Create subcommands:\n      Develop the actual subcommand under the refs command(builtin/refs file)\n      by leveraging core functions from the refs module. The implementation\n      will mimic the logic of the legacy commands where it makes sense for\n      consistency with existing behavior, but we'll also evaluate opportunities\n      for improvement where deviating from the legacy behavior could be\n      beneficial.\n    2. Tests:\n      Develop comprehensive tests to verify that the new subcommands function as\n      expected. This will involve creating a range of tests, including shell\n      scripts and/or unit tests located in the t/ directory. For the existing\n      tests covering the legacy commands targeted for consolidation, the plan is\n      to retain them initially—even if this results in some duplication—with the\n      intention of deprecating them gradually over time.\n    3. Documentation:\n      Develop comprehensive documentation for the newly implemented\nsubcommands to\n      ensure clear guidance for users and maintainers.\n\n\nCommand mapping and naming:\n---------------------------\n\nI have taken reference for potential names for these subcommands from Patrick’s\nsuggestion (https://gitlab.com/gitlab-org/git/-/issues/330):\n\n  # Replaces git-show-ref(1) and git-for-each-ref(1).\n  $ git refs list\n\n  # Replaces `git show-ref --exists`.\n  $ git refs exist\n\n  # Replaces `git show-ref --verify <ref>`.\n  $ git refs show\n\n  # Replaces git-symbolic-ref(1) to show a ref.\n  $ git refs resolve\n\n  # Replaces git-pack-ref(1).\n  $ git refs optimize\n\n  # Replaces git-update-ref(1).\n  $ git refs write\n\n  # Replaces git-check-ref-format(1).\n  $ git refs check-name\n\nBelow is a list of the commands along with their associated subcommands/flags\nthat need to be considered for consolidation under this project:\n\ngit show-ref -> git refs list\nUsed to list references in a local repository.\n* abbrev\n* branches\n* tags\n* exists\n* verify\n* exclude-existing\n* dereference\n* head\n* hash\n* quiet\n\n\ngit for-each-ref -> git refs list\nUsed to output information on each ref, quite similar to show-ref.\n* --count\n* --shell|--perl|--python|--tcl\n* --sort\n* --format\n* --include-root-refs\n* --points-at\n* --merged|--no-merged\n* --contains|--no-contains\n* --exclude\n* --ignore-case\n* --omit-empty\n\n\ngit pack-refs -> git refs optimize\nUsed to pack heads and tags for efficient repository access.\n* --all\n* --no-prune\n* --auto\n* --include\n* --exclude\n\n\ngit update-ref -> git refs update/write\nUsed to update the object name stored in a ref safely.\nSubcommands:\n* [symref-]update\n* [symref-]create\n* [symref-]delete\n* [symref-]verify\n* option\n* start\n* prepare\n* commit\n* Abort\nOptions/Flags:\n* --stdin\n* -m\n* -d\n* --no-deref\n* --create-reflog\n\n\nOptions/Config sharing:\n-----------------------\nFor sharing configuration options, I propose a structure-based approach that\ncentralizes common options while grouping subcommand-specific settings into\ndedicated substructures. This design embeds common options directly in the\ntop-level configuration structure (struct refs_options), and then uses separate\nstructures (such as struct list_options) to encapsulate options unique to each\nsubcommand.\n\nBelow is a representative code snippet illustrating this approach:\n\nstruct refs_common_options {\n        ...\n        // ... Common Options ...\n        ...\n};\n\nstruct list_options {\n        struct refs_common_options common;\n        // ... options specific to 'list' subcommand ...\n};\n\n\nstruct exist_options {\n        struct refs_common_options common;\n        // ... options specific to 'exist' subcommand ...\n};\n\nThis design is tentative, and we will evaluate the best approach on a\ncase-by-case basis during implementation to ensure flexibility and efficiency.\n\nSince we plan to maintain the legacy commands for the foreseeable future, we\nmust ensure backward compatibility while developing these new subcommands. Going\nthrough this I wonder if we should make the commands as a standalone\nentity, like\na library. However, it needs to be thoroughly discussed.\n\nWhile studying these commands, I thought why not try out one of them to better\nunderstand the project’s requirements, scope and get a firmer grip on the\ncodebase. So, I developed a reference implementation of git refs list that\nmimics the behaviour of git show-ref with [--head], [--branches|--heads] and\n[--tag] flags, which can be found (https://github.com/inosmeet/git/pull/1).\n\nAlthough this reference implementation is still a work in progress and not yet\nready for merging into master, it demonstrates my understanding of navigating\nthe Git codebase and the process of creating commands and subcommands. More\nimportantly, it indicates my ability to execute this project effectively.\n\n\nTimeline:\n---------\n\nPre-GSoC (Until May 8):\n* Continue to work on different things like the pending WIP patch that I have.\n  Be engaged/involved in the community.\n\nCommunity Bonding (May 8 - June 1):\n* Talk with mentors and discuss potential names for the new subcommands and\n  interface design. Start the consolidation early with mentors’ permission.\n\nPhase I (June 2 - 29 June):\n* Consolidate shared functionality common to both show-ref and for-each-ref\n  commands along with their  subcommands/flags to refs... command.\n\nPhase II (30 June - 13 July):\n* Consolidate non-shared functionalities of show-ref and for-each-ref -- such\n  as --exists, --verify and related options -- into refs... command.\n\nPhase III (14 July - 27 July):\n* Consolidate pack-refs command along with subcommands/flags to refs...\n  command.\n\nPhase IV (28 July - 24 August):\n* Consolidate update-ref command along with subcommands/flags to refs...\n  command.\n\nFinal Week (25 August - 01 September):\n* Some final touches. Make a final report about the work accomplished and\n  outline future work.\n\nI have not allocated separate timeline slots for tests and documentation, as\nthese will be integrated into the patches that introduce the new subcommands.\n\nI think if permitted to start early, I can consolidate one more command within\nthe GSoC period.\n\n\nRelated previous work:\n----------------------\n\ngit-switch Command:\nhttps://github.com/git/git/commit/d787d311\nMailing list thread:\nhttps://lore.kernel.org/git/20190130094831.10420-1-pclouds@gmail.com/\n\n\ngit-restore Command:\nhttps://github.com/git/git/commit/46e91b663badd99b3807ab34decfd32f3cbf15e7\nMailing list thread:\nhttps://lore.kernel.org/git/20190308101655.9767-2-pclouds@gmail.com/\n\n\nStretch goals:\n--------------\n\nIf the consolidation of the 4 commands is completed ahead of schedule, I would\nlike to consolidate the remaining commands (these can be done even after the\nGSoC period). These commands include git symbolic-ref and git check-ref-format.\n\nList of commands along with their subcommands/flags that needs to be considered\nfor consolidation:\n\ngit symbolic-ref -> git refs resolve\nUsed for reading or updating symbolic references.\n* -m\n* --delete\n* --quiet\n* --short\n* --recurse | --no-recurse\n\n\ngit check-ref-format -> git refs check-name\nUsed for validating whether a given reference adheres to Git’s naming\nconventions\nfor references.\n* --[no-]allow-onelevel\n* --normalize\n* --refspec-pattern\n* --branch\n\n\nBlogging:\n---------\n\nBlogging is a good way to foster transparency and community engagement in\nopen-source projects. By sharing insights, challenges, and milestones, blog\nposts not only document the project’s progress but also create opportunities for\nfeedback and collaboration from the broader community.\n\nIn my project, I plan to commit to bi-weekly blog posts. These updates will\ndetail my progress, share lessons learned, and highlight any obstacles\nencountered along the way, ensuring that the development process remains open\nand interactive.\n\nThe blog will be at: https://inosmeet.github.io\n\n\nPost-GSoC:\n----------\n\nOver the past three months, the Git community has been an invaluable source of\nsupport and learning, significantly contributing to my growth as a developer.\nEven after the summer program, I intend to stay active in the mailing list and\ncontinue contributing meaningful patches. I'm thinking of consolidating\nremaining commands after GSoC is over. I've also been following the early\nefforts to integrate Rust components into Git via libgit-sys, and I would be\nexcited to contribute to that initiative as it matures.\n\nLastly, if given the opportunity, I would be delighted to mentor new\ncontributors and help the community grow even further.\n\n\nSome credits to myself:\n-----------------------\n\nI am an open source enthusiast, I have contributed to some other open-source\nprojects as well. I was selected as a GSoC 2024 mentee for the Python Software\nFoundation’s cve-bin-tool sub-organization where I worked on improving Product\nmapping using PURLs (Package URLs).\n\nMore recently, I got selected as a LFX 2025 term-1 mentee for Cloud Native\nComputing Foundation’s Microcks sub-organization. Here I’m working on improving\nMicrocks’ delivery and validation using GitHub Actions CI deployment tests.\n\nThese opportunities have given me valuable initial exposure to open source\npractices and community collaboration, and I’m excited to further build my\nskills while contributing fresh ideas to this project.\n\nBlogs for both my GSoC as well as LFX journey can be found at my blog site:\nhttps://inosmeet.github.io/posts\n\n\nAvailability:\n-------------\n\nMy current semester ends on 24th April and my exam tentatively on 15th May,\nleaving me enough time to prepare for my GSoC project. If I am selected, I shall\nbe able to work five days per week, 7 - 8 hours per day, dedicating around 35-40\nhrs a week on the project.\n\nThe difficulty level of this project is medium, and the expected project size is\nestimated to require about 350 hours of work. Based on my proposed commitment of\n35-40 hours per week, this project aligns with my availability and intended\nworkload for the GSoC period, ensuring that I have sufficient time to\naccommodate any unforeseen circumstances that may arise during the project.\n\n---\nThank you for considering my application. I am excited about the possibility of\ncontributing to this project and learning from the mentorship experience.\n\nThanks & Regards,\nMeet\n"}]}