Open-Source · Pablo Sabater

GSoC 2026 with Git

Mon, 24 Aug 2026 20:27:00 +0200

Note

This is a quick look at the work done. I suggest getting into the threads of the two series, reading my blog or my proposal if you want more detailed information. I consider this a more intimate writing recapping what I did this summer.

Complete and extend the remote-object-info command for git cat-file§

Sometimes it is only needed to know something about an object, its size, its type, etc. Before this project, it was not possible to know that without downloading it. Git’s v2 protocol had a server-side object-info capability since 2021, but no client used it.

This project finishes that. git cat-file --batch-command now understands a remote-object-info command that asks a remote for object metadata over the v2 protocol and prints it, without downloading it.

Two patch series came out of the summer:

Series	Patches	Final iteration	Status
`cat-file: add remote-object-info to batch-command`	13	v21	merged into `master`
`cat-file: extend remote-object-info to support %(objecttype)`	10	v6	will merge into `master`

About the project§

About `cat-file` and `object-info` protocol§

git cat-file prints information about objects in a cloned repository locally, you can get lots of information such as the size, type, size:disk, delta. But it had no way of gathering that information from a remote, you had to download that object beforehand using git cat-file.

Protocol v2 already had the server half of this. Support for answering object size requests landed in a2ba162cda (object-info: support for retrieving object info, 2021-04-20). What was missing was any client that used it.

Prior work§

This project continues the work of Calvin Wan and Eric Ju. They introduced remote-object-info into cat-file, but the work had stalled and wasn’t ready yet. The code worked in the ideal path but lacked proper supported handling, the transport was piggy-backing on fetch and there were some logic issues.

The problem§

Well, there was a lot of previous work done. This has been a multi-GSoC project, and I had to rebase everything up to today’s master. Some things were easy and some were not, especially the ODB-related code, as there had been a lot of refactoring related to ODB code, a lot of functions moved, and whole files removed.

The goal§

Get remote-object-info merged with %(objectsize) working end to end, then extend it to support %(objecttype) as well.

You can see more about the problems if you read my blog or my proposal.

What was implemented§

Goal 1 series: `remote-object-info` in `--batch-command` (v21, 13 patches)§

Completes Eric’s work and gets it to master.

The main contribution on top of the inherited series is a rework of placeholder validation: instead of a hardcoded list, an allow-list is used to filter what it supports instead of accepting the same placeholders as local. Also, with this allow-list, placeholders known in local but unsupported by the remote will return an empty string, as suggested by Jeff King.

The idea of the allow-list evolved to a list that initially accepts everything but once the connection with the remote is established, the remote returns what it supports, and after receiving it, the client would trim the allow-list to only contain what the server supports. Later on, when printing the data, the requested data that had no match in the allow-list meant it was unsupported and therefore an empty string is printed.

This series was originally intended to be client-side only, but it was decided to add a server-side patch where we would allow a request without attributes such as size, type, … This would serve as an existence check.

https://lore.kernel.org/git/20260724-ps-eric-work-rebase-v21-0-ba67f024fdff@gmail.com/

Goal 2 series: end-to-end for `%(objecttype)` (v6, 10 patches)§

Type was the next attribute that we wanted to add support for. I thought at first that after type the rest would follow the same path, but after working on it, I realized that the rest of the attributes depend on how the object is packed; they are not intrinsic to the object. So we discarded support for them.

This series relies heavily on the previous one obviously, but I didn’t want to make it just work. Of the 10 patches, 6 are preparatory patches that clean, trim ambiguity and fix the current work.

This series extends the object-info protocol to support the type attribute, and handles it both on the server and the client: advertising it, parsing it, sending the data, … To later, in the last patch, unify the default format to match the local info command one.

For this patch I could count on the expertise of Jeff King and Junio, who noted that the use of an array of object_info was not good. This structure is used to mark what the user wants to get and to later hold the object being printed, so using an array of it breaks the intended use of it. Instead, this new structure was created:

struct fetch_object_info_results {
	size_t *sizes;
	enum object_type *types;
	uint8_t *unrecognized;
	size_t nr;
	unsigned wants_size:1;
	unsigned wants_type:1;
};

Instead of having the indirections of having to allocate object_info and then for each field, we have the data contiguously in its own attribute array, we also split from using object_info marked pointer to bit fields that mark what the user wants.

https://lore.kernel.org/git/20260808-objecttype-support-v6-0-e5cdaf27a49c@gmail.com/

Backward compatibility§

The server-side needed to have backward compatibility with the 2021 work, and we also had to think about different client versions and different servers:

the client knows it but the server does not (new client vs old server)
the client does not know it but the server does (old client vs new server)
both know it (everyone is new)
neither knows it (unsupported capability)

Learning from git§

Well, TBH it has been a very rewarding experience. I’ve learned a lot and imma skip the obvious: better logic, a broader perspective, etc.

I learned how to work on a mailing list and with people. I always code alone, so this was a new experience for me.
I learned how git works under the hood.
I went through review loops and learned to review other people’s code.
I learned protocol stuff, like not being ambiguous (yes, I know that it is obvious). This comes from the number parsing function: I made a function that was too broad, you could parse HEX when there was no need, we only wanted to parse the size in base 10.

Could it have been done better?§

Hummmmm, yes I do think that. I have two itches. The first is the object-info protocol, having to rely on the previous protocol and not starting from the beginning of it made the protocol with type look like:

command=object-info
object-format=$(test_oid algo)
0001
size
type
oid $two_oid
oid $two_oid
0000
EOF

The new line after size, although not something to cry about, ideally should be size type on the same line.

struct fetch_object_info_results {
	size_t *sizes;
	enum object_type *types;
	uint8_t *unrecognized;
	size_t nr;
	unsigned wants_size:1;
	unsigned wants_type:1;
};

For this same data structure mentioned before, unrecognized could be optimized to be a true bit array, instead of wasting 7 bits for each one.

How do I plan to keep working§

Right now I have the idea to add the dry-run option for git backfill, the object-info protocol could be used to fetch the size of those objects to give the user the number of objects to be fetched with an estimate of the size that they will take.

I have also read that it could be interesting for VFS, but for that, sadly, I’m completely ignorant and I will have to study it.

Not just GSoC§

This summer I didn’t just make the project, in fact I worked on other areas such as the graph one. I really like this one because what I did was very visual and cool looking:

git log --graph had a problem with visual roots that made the graph sometimes ambiguous, as two completely unrelated commits could be rendered one below the other seeming that they are related when in reality they are not:

The idea is to indent/shift the visual roots that can cause that given ambiguity, fixing a long-known rule: vertically contiguous commits don’t have to mean a relation between them.

Before indentation:

* A
* B1
* B2
* C1
* C2

After indentation:

 * A
* B1
 \
 * B2
* C1
* C2

You can see more about how this works at:

https://lore.kernel.org/git/20260714-ps-pre-commit-indent-v12-0-d50938e006df@gmail.com/

And lastly, at the end of this GSoC period I wanted to do a favour for the next contributors that come to Git and maybe not that new but curious, a tool called WhatToGit

This tool gathers all the markers in the codebase such as TODO, NEEDSWORK, etc., and #leftoverbits on the mailing list into documents so it is easier to know literal pieces of wanted work.

This is the part for which I wanted to write this whole thing instead of just sending a link to the work.

I cannot express how grateful I am to Karthik and Chandra. This summer has been “un antes y un después” for me, a turning point forward. They have been great mentors and have helped me as much as I needed. More than that, they have been friends this summer.

I consider myself to be very intense and passionate about what I do, so I was worried about spamming too much, talking too much, etc. Those are things I tend to do when I’m nervous. I liked that they had no problems with it. (Also, my idea brainstorms at 3am have been for the good.)

I also want to be thankful to Tian Yuchen, another GSoC contributor this summer along with me at Git. He’s been someone I’ve talked to a lot throughout this summer and I’m sad that I won’t be seeing him at the Git Merge this year, maybe one day.

I also want to thank everyone who has reviewed my work or helped in any way, and Paco, my friend who told me about GSoC.

GSoC Week 11

Fri, 07 Aug 2026 21:08:11 +0200

Tic Tac, Tic, Tac… I am already getting emails from GSoC warning me that there is little time left.

Picking up where I left it last week, a few hours later I sent the v3 and out of this version came some nits and a small ordering problem.

The past series, the client already had %(objecttype) in its list and I did this for a simple reason, there are 4 possible cases:

the client knows it but the server does not (new client vs old server)
the client does not know it but the server does (old client vs new server)
both know it (everyone is new)
neither knows it (unsupported capability)

From what we have been building, invented placeholders like %(IJustInventedThis) simply die(), for the placeholders that exist locally there is another behavior: If it is not supported by the client or the server, the output of these when expanding them will be an empty string.

For example:

we ask for “%(objectname) %(objectsize) %(objecttype)” but our server does not support type.

therefore our result will be:

“<OID> <size> "

The list was designed so that even if new placeholders were added it would be idempotent, because nothing would happen until a server did advertise that attribute, that’s why having type in there changed no behavior at all.

It was there because it was interesting for the tests, a client did not know how to parse if a server offered type and it did not know how to ask for it either, but it did know how to understand if a user wanted it. This way we had tested:

unknown + unsupported, as %(deltabase) is
known + unsupported, as %(objecttype) was (that’s why it was on the list)
known + supported, as %(objectsize) is

However with the back and forth of the type series that I am taking advantage of to leave things clean, this stopped making sense. Using object_info and the list worked because object_info already had a type field, so listing type cost nothing. Now that we dedicate an array per attribute it would mean carrying a types array that nobody fills, so I preferred to drop it there and implement type fully later in the series.

Patches 1-5 are preparatory. They don’t change what the command does:

[1/9] is a test cleanup.
[2/9] fixes a possible bug in case of a malformed response.
[3/9] and [4/9] refactor how the object data is stored and handled. The why about this refactor comes from [1].
[5/9] drops the last error return left in fetch_object_info().

Patches 6-9 are the actual objecttype support:

[6/9] teaches the server to answer type.
[7/9] teaches the client to parse it.
[8/9] advertises the capability so the client can start asking it.
[9/9] unifies the default format.

and for the v5 there will be one more preparatory patch that Jeff King made, for a total of 10 where 6 are prep.

The shape has changed quite a bit, there is no longer an allow-list that we filter but something simpler which is having our own struct where we have flags if the client wants X attribute of an object and these are saved in a new struct:

struct fetch_object_info_results {
 size_t *sizes;
 enum object_type *types;
 uint8_t *unrecognized;
 size_t nr;
 unsigned wants_size:1;
 unsigned wants_type:1;
};

instead of having an array of struct object_info we save all our data here so we do not have an array of object_info that was not made for that.

The truth is that it has been quiet and there is not much more, I will put in Jeff King’s patch, but there is nothing for now that I have to change.

I think this has been the briefest week of all (taking into account that the last one I published on Sunday) but it has been very quiet.

Saturday edit on friday night I sent the v5 and the static test failed, while all the others were fine, look, I usually wait for the tests to pass but I was already seeing everything green and I assumed the rest would go the same way.

However, it was not like that, strangely everything was fine except the static, which was a bit odd to me because I thought that at least on some platform or something it should fail too, but no, everything green except the static.

The solution was easy, two forward declarations and fixed.

Outside of GSoC these weeks I have been tying up loose ends to go live in Lisbon this year and everything is going smoothly, for now I already have all the paperwork done, so by the first days of September I will be there already since university starts.

I also did a couple of streams programming, I like it quite a lot and I talk, but to concentrate well I need to be in silence which is a bit counterproductive for streaming. But well, I have to improve.

I have bought a new book which is a well known one:

Designing Data-Intensive Applications

It will arrive next week.

See you next week,

Pablo

[1] https://lore.kernel.org/git/xmqqzez67yg1.fsf@gitster.g/

GSoC Week 10

Sun, 02 Aug 2026 23:51:31 +0200

Last group meeting

I’m trying out new techniques for writing, the way I’m going to write this week consists of writing in my native language (Spanish) and then translating it, I hope to be able to show more of my personality.

This week I think has been the last of the meetings we’ve had as a group, these group meetings we’ve had one a month, where the 4 GSoC in Git participants and mentors get together and talk about how our projects are going.

It makes me a bit sad to see that this is coming to an end and at the same time I look back and feel that I’ve learned a lot; even though I still make basic junior mistakes, even if I think I’m cool, at the end of the day I’m still in my second year of my degree and I have a lot left to learn, I’m not going to become a genius overnight I wish….

This week started off quiet, my mentors Karthik and Chandra are both tied up each with their own things, Karthik became a father a few weeks ago and Chandra is tied up with academic stuff. But it doesn’t worry me much, I think I’m already “independent”, I still make mistakes, but I’m able to keep putting out series on my own. However the mentors’ work is fundamental for the rerolls to move forward quickly and that the two of them have found time to do reviews… I’m very grateful.

A few days after the v1 I got feedback and got down to work.

Hey, I still have to say that the goal1 series has finally been merged and now I’m going full throttle with the goal2 series, this series is in principle muuuuch shorter, because all that infrastructure I needed for goal2 came in goal1 which took an eternity to get merged, for now I’m forgetting about it but not for long, I’ll tell you why in a bit….

Well, carrying on since I get distracted even writing on my own, goal 2 got feedback and following the usual flow, I fix and send a reroll, afterwards there were still some nits and fixes left, but it worked, however:

Junio pointed out that there was something about it that didn’t work for him, the way the data moves between the functions wasn’t correct. I was using struct object_info to store what the server answers. It’s the structure that read_object_info() uses, and, well, I saw sense in it, it has size, type, OID. But fitting isn’t the same as being the right type. The pointers of that structure exist to tell read_object_info() where to write the values; they aren’t the place where the values stay. Since fetch_object_info() doesn’t call read_object_info(), those pointers weren’t telling anyone anything, I was using them as storage. What gave it away was having an array of struct object_info, one per object. You never need more than one, if you’re going to read N objects, you reuse the same structure pointing it at the N-th variable on each pass of the loop. An array of them means you’ve confused “where to write the answer” with “the answer”. The solution is a type of its own for the results, one array per attribute, plus one flag per attribute saying whether the server answered it, because the server responds with the same set of attributes for all the OIDs. That forces changing the signature of fetch_object_info(), making parse_cmd_remote_object_info() copy the values into expand_data, and along the way free_object_info_contents() is left without its only caller and disappears.

Part of this I inherited from how the code was before I got here and I hadn’t read criticism about that code, so with it working and me understanding it, it seemed correct to me but when Junio mentioned it, the truth is that what I was doing really wasn’t very correct, although I think I’d probably still fall into the same thing if I found myself in a similar situation. BUT LET IT BE CLEAR, I know that I’m the one who takes responsibility for the project and that it isn’t an excuse, but it is a difficulty, and well that’s what the review is for, I’m glad it was questioned and now I do it right.

In case anyone is interested in that thread: https://lore.kernel.org/git/xmqqzez67yg1.fsf@gitster.g/#t

This means that I’m going to have to do a couple of prep commits to make a struct of my own for how the information moves along the transport path up to fetch_object_info() but well, today I’ve put a few hours into it and I have a big part of it done, a bit of frustration because if I had done it right from the start this wouldn’t have to be in this series, but well, time to suck it up and leave it right.

I’ll probably have the v3 by tomorrow, but I still have to write the commits properly and give one last look over whether I’ve done everything they asked me for, I keep trying things like using a notebook, notion, or just remembering, none of them quite wins me over but well, I have to organize myself somehow.

Since it’s coming to an end I’ve been thinking about whether to sign up for some internship or something more afterwards but I don’t know how I’m going to manage university life (partying, yes, I love going out), programming which is what I usually do in my free time and having to go to university. For now, I don’t think I’ll apply to any internship until I know I can juggle things, but, stop programming? nah, that for sure not.

I hope that for next week’s post I can say that v3 is looking good and is almost finished, there are approximately 2 weeks left and I trust that I can finish in time.

See you next week, Pablo

GSoC Week 9

Fri, 24 Jul 2026 13:09:11 +0200

This last week has probably been the one with the least work to do from all the GSoC period.

Last post I had sent v20 and thought that would be it, two tiny nits appeared but nothing “relevant”. This week has been waiting for any other review or further issues with the series, but seems that’s it.

But if something I’ve learned is that there can always be something else.

Let’s hope that there’s not

While it seems that there’s nothing else, v21 is already sent. Maybe this week will be THE WEEK?

To have things prepared, I have the second series updated to v21 so as soon as I have green light, I’ll send the goal2 series.

I have a lot of ideas to keep working on things (on Git outside of GSoC)… For example:

there are optimizations to the server-side that would be its own series.
I have my already started work with a --dry-run option for git backfill which I’m kinda gatekeeping because I don’t want to affect the ongoing of the GSoC project series.

But be sure that there will be an [RFC PATCH] sooner or later about the dry-run option haha.

I reviewed a few patches this week while waiting, and I still have to check out Siddharth’s series, but for that I want contiguous time to understand things, as I did with Yuchen’s series.

Other than that, this week has been brief. I’m really liking the experience and definitely I’ll keep contributing after GSoC.

I bought a book:

A Philosophy of Software Design

For now I’m liking it, it would have been good to have read it before GSoC… haha but nice book, I recommend it.

I have on my wanna-read list: Designing Data-Intensive Applications.

I’m building the habit of reading to avoid doomscrolling hours and it seems that it works.

Yuchen recommended a game called Turing Complete that looks cool, I’ll try it. I think it’s about building your own CPU starting from NAND gates.

One of my dream projects is to build physically my own CPU, designing its own ISA and then an assembler for it.

I have been talking with Yuchen these last weeks, sad he lives sooooo far, but I hope to keep talking with him after GSoC, same for Chandra and Karthik, my mentors :).

I think I’ve met cool people throughout this summer.

GSoC Weeks 7 and 8

Thu, 16 Jul 2026 00:20:57 +0200

This past week and a half has been exhausting; I still don’t have the Goal1 series merged into next.

This weekend, I had both my graph and Goal1 series pushed to the mailing list, and since the list is less active on weekends, I had some spare time.

I had been meaning to review Tian’s series from a while ago, but I hadn’t found the time to do it properly. This weekend was finally the time.

I wanted to do a thorough review, but until now, I had never reviewed further than just reading the code, maybe pulling it locally, and testing on the tip of the series. This time, I wanted to review it commit by commit.

My first (and not very clever) thought was to run git rebase -i $base and mark everything as edit. But that sounded very impractical, and having to type edit manually… No, it couldn’t be that.

What I ended up doing was running git switch --detach <commit>. This way, I could break and mess around with Tian’s commits as much as I wanted to get to the bottom of everything.

The experience… was tricky. I think it’s a very intricate topic where you must be very careful about what you’re doing. I originally meant to spend just one evening on it, but I ended up needing the next morning as well.

I really enjoyed that, now that I feel much more comfortable with the Git codebase, I can actually do deep reviews. It’s something I like because I get to see how others code, and I always end up learning new stuff.

After the weekend, some more nits landed on the graph series, but other than that, the series seems to be done. I hope to see a “Will merge to next” at next What’s cooking on Git.

You can check out the graph series here:

graph series

We went from one commit to seven, but I’m very proud of how the final result turned out.

The rest of the week was dedicated mainly to two series:

I “finished” the git backfill --dry-run option series (it’s on GitHub). There might still be some edge cases, and some of the code is rough, but it is RFC material—which is exactly what I wanted. The happy path works, along with some edge cases that I caught while testing. github series
The rest of my effort and the main focus this week, has been fast-tracking Goal1 to try and finish it once and for all.

I’m a bit worried about time; there’s only one month left, and this series is blocking Goal2, which has been sitting on my GitHub for many weeks. I’m a bit frustrated about that, though I can’t say it’s unfair because the feedback I’m getting is spot-on regarding things I actually need to fix.

Anyway, it does what it’s supposed to do. The remaining things to cover are just nits, making the protocol less ambiguous and not overly trusting.

In the last version, Junio suggested there should be a cheap way of requesting a bare OID so we could have an existence test, if you want to know if there’s an object on the remote, you could just send a bare OID.

However, the server side wasn’t ready for this. it was designed to always work with at least one requested attribute (“size” in this case). Because of that, I had to add a new patch to get the server side behaving how we want. Now the series is a mix of server-side and client-side changes, sadly.

As of today, I spent the whole day (and by whole day, I mean the whole day, haha) reviewing and cleaning up the Goal1 series so the next reroll can (hopefully!) be the last. I’m almost done, but I still have to finish the last two commits of the series. That will definitely be a task for tomorrow because today I’m so f* tired. After that, I’m really confident it will be ready or como muchísimo (exagerated “at most”), just some tiny nits.

This morning while I was coding, I’ve been in a voice channel on the Git Discord server talking with whoever wanted to join. Tian and Siddharth joined :).

To sum up, this week has been tough, I’ve been coding non-stop, but I think it will all be worth it.

See you next Thursday, Pablo

GSoC Week 6 and Half 7

Fri, 10 Jul 2026 23:49:31 +0200

This week I was at a campsite for a few days, but that doesn’t mean that I stopped :).

Me coding at a campsite

It is already the mid term evaluation, this means that we are half done with the project time.

I strongly think that I will be able to finish the whole project on time and even have some extra time to work on an idea I have related to my GSoC project

I’m waiting for the Goal 1 series which is finishing the end to end of the object-info protocol and the %(objectsize) placeholder. Once this series is at least on “next” I will send the next one which is the %(objecttype) support. This series will have a much more fast pace because it is muuuuch smaller than the Goal 1 series.

%(objecttype) support series§

Because the object-info protocol infrastructure is already built from the Goal 1 series this only has to focus on gathering the type and parsing it.

If you want to compare Goal 2 series is ~150 lines vs the ~1000 lines of the Goal 1 series.

at protocol-caps.c only size was supported and to get the size, odb_read_object_info() is called and size gets filled through a pointer, but the return type was actually the type.

We can also know through the type if the object is not recognized by the server in case of the type being <0.

 strbuf_addstr(&send_buffer, oid_str);

 object_type = odb_read_object_info(r->objects, &oid, &object_size);
 failed = object_type < 0;

 if (failed) {
 strbuf_addch(&send_buffer, ' ');
 goto write;
 }

 if (info->size)
 strbuf_addf(&send_buffer, " %"PRIuMAX,
 (uintmax_t)object_size);

 if (info->type)
 strbuf_addf(&send_buffer, " %s", type_name(object_type));

After that we just need to append to the buffer the type if it was asked. This was a very trivial change. The overhead is barely anything but at most 6 extra bytes from the “commit” string appended to the buffer.

That’s why I think that the hard part of the project is not actually the coding but rather knowing what everything around it means.

At the project description it was explicitly said to be cautious about the backward compatibility and I thought of four different cases:

The server doesn’t support type (updated client but old server):

After we get the server capabilities, the client sees that’s type is not advertised, filters out type from the request if it was asked by the client and returns an empty string where the type would be.
The server supports type but the client doesn’t (updated server but old client):

The client would get the server capabilities where type will show, I chose to let the client know type for testing purposes on the Goal 1 but the client doesn’t know how to parse the type capability.

So as far as the client knows type is never advertised and will only ask for what it knows. What it doesn’t know results in an empty string.
Both support type (everyone is updated)

Everything works as expected, the client asks for the type the server supports it and sends it.
Both support type but a middleware strips type:

This might happen but it will become case 1. or 2. depending of which side is affected by the middleware:
- In case of affecting the client, the client can’t ask for type and the server won’t get the type request.
- In case of affecting the server, the client never gets the type capability advertised and the client never asks for it.

What makes the client-server object-info protocol robust is that is negotiation based, the server advertises and the client always adapts to what the server can provide, no one assumes anything.

After this series, we need to discuss the need of supporting more placeholders like %(deltabase), %(size:disk), %(objectmode)… These options, delta and disk size, I think that they are not useful to be supported

why?

Because the delta or the disk size that you retrieve from the server are not reliably the exact same that once fetched onto your local. others like %(objectmode) need Tree context which is not even thought of yet for the object-info protocol.

The only intrinsic metadata that doesn’t change once fetched is size and type. That’s because size and type are object properties while delta and disk size depend on the way they are packed or your local objects.

Implementing their support is not hard, is just the same as type, but the hard part is to justify their support and usefulness.

However I have not only worked on the GSoC project during these six and a half weeks I have another series active and I have started with a sketch for my idea after the project.

Graph indentation series§

This series comes from the bonding period it ended up being messier than what I initially thought that it would be but now is close to be done.

Before this series graphs had a warning: “vertically adjacent commits DO NOT mean that they are related” and now after it this rule makes it that vertically adjacent commits are always related.

Because we are talking about graphs, some visual examples will help:

* A
* A
 \
 * A
* B
* B

A and B are two unrelated branches that would be rendered in the same column, this has the problem that you would be confused to know if A and B are related if you saw them like:

* A
* B

Now the last commit of a branch that it is a visual root, that means, that it is an actual root or a commit that looks like a root (have its parents filtered out) will be indented to remove the ambiguous graph.

 * A
* B

A bigger example could be with two unrelated branches with merges:

* C
|\
| * D
| * D
|/
 \
 * C <- indented
* A
|\
| * B
| * B
|/
* A

This series has become tricky because there are a lot of edge cases to care about.

Extending other commands with object-info protocol§

Now that after Goal 1 we will have the infrastructure for making object-info requests from the client many commands could make use of it. For example what I thought is git backfill, I’m not a git backfill user, the biggest project I’ve coded at is Git, but I believe that if you use git backfill is because you work at something massive and you care about the size and you may be interested in an option to preview what will happen after backfilling:

I want to add a git backfill --dry-run option for that purpose.

To make it output how many objects will be fetched is easily done because the number is already known by the current infrastructure, we just need to make the path where we avoid fetching and we print the preview.

The interesting part is mixing it with object-info to know the total size of those objects. Sadly the total size may not be the actual size once fetched because of the deltas and disk size that depends on your local but it works as a limit, we can be sure that it will not be more than the total size.

To make this possible some of the logic of the transport setup needs to be extracted from ‘cat-file.c’ get_remote_info() so other commands can reuse it.

Some things that I should care of but I don’t really know how to take care of them is:

For remote-object-info the maximum number of OIDs to be sent in a single request is 10k this was previously chosen before I got into the remote-object-info series but should we respect this? given that git backfill nature is to be used in massive repositories is 10k enough to not become dozens if not hundreds of requests?

After adding the –dry-run option it will look similar to:

$ git backfill --dry-run
After backfill X objects would be fetched (Y total size)

These are the four series I’m working on currently. I wanna try git worktree to be more chill about swapping between them but I haven’t done it yet.

I usually work at one, then push it to run CI tests, work for an hour on another branch or so while the tests run and then come back. I can sometimes be forgetful or get distracted easily so I bought a small notebook to take notes for when I get back to it.

I think that the work left to do for the remaining GSoC time is:

For Goal 1 series:

Send rerolls faster because I think it’s close to be done and this series is gatekeeping the %(objecttype) support series and the backfill –dry-run series because they both depend on the object-info infrastructure.
For %(objecttype) support series:

I think this one is very simple there’s not much else to do but once at the mailing list I’m sure that there will be something to discuss.
For the graph indentation series:

Same as Goal 1 series, it is close to be done, keep making fast rerolls and addressing the feedback quickly.
For the backfill –dry-run series:

I haven’t finished this series yet, I have only up to printing the number of objects that will be fetched and extracted the transport logic but it lacks the integration with object-info to retrieve the total size.

See you next Thursday 16th :)).

GSoC Week 4 & 5 Coding Period

Wed, 01 Jul 2026 14:34:54 +0200

The first part of the project which consisted of finishing what Eric Ju started, adding remote-object-info to --batch-command on git cat-file. We started with a v11 and we are at a v15 currently, where things are actually working.

It’s close to midterm so let’s do a quick summary of how this first part works:

What does `remote-object-info` do?§

Sometimes you want to know metadata about an object but you do not like having to download them. The server support for object-info was already merged in 2021 with the object-info capability in v2 protocol but there is no client-side implementation currently.

That’s where we come in with our new remote-object-info, this new command will let you query remotes for object info, similar to what you can do locally with info.

The way you would do this is:

$ git cat-file --batch-command="%(objectname) %(objectsize)"
 remote-object-info "https://example.com/repo" <oid>

Where did I start and what has been done§

Eric and Calvin made the foundation: the transport, the plumbing, the protocol handshake, etc. Their work covered most of the end to end for the client side and %(objectsize) atom.

However there were things to work at before calling it a day:

Segfault on uninitialized data. Atoms like %(objecttype) were recognized by expand_atom() but the remote never gave data for them.
Local queries were being blocked. Unknown atoms returned with 0 and died killing the whole process even if other commands like info could handle those placeholders.

My first fix (talked about in previous posts) was to add a static allow-list. A hardcoded array of supported atoms, so when we were in “remote” mode we would check this list, unsupported atoms return 1 with an empty string.

But as we talked about this hardcoded solution didn’t quite complete the job as good as I wanted. It works today because the only option is a server supporting object-info with size or it doesn’t support it at all.

But what about the future?

We need to think about cases like a server with a version that supports size and a version that supports size + more metadata. Then how do we handle these? we need to support up to what the newest server supports but if we allow the client to request metadata that it does not support we end up failing.

What I needed for the solution was already there, on the handshake, the server tells us already the metadata that object-info supports. Knowing this we jump to the last commit of the series:

Making the allow-list dynamic.

Knowing what the server supports, we filter what the client asks to only request to the server what it supports. If we end up having nothing to request we can completely skip requesting the server.

What do we have to do to support %(objecttype)?§

The process after the allow-list has become very trivial, we need to teach the server how to get the metadata that it needs, how to advertise it and for the client, teach it how to parse the server response and add our new atom to the allow-list.

How will the object-info protocol look?§

For the more formal guys this is how I plan to leave the object-info protocol:

The response of object-info is a list of the requested object ids and associated requested information, each separated by a single space.

output = info flush-pkt

info = PKT-LINE(attrs LF)
 *PKT-LINE(obj-info LF)

attrs = attr | attrs SP attrs

obj-type = "blob" | "tree" | "commit" | "tag"

obj-size = 1*DIGIT

obj-val = obj-size | obj-type

attr = "size" | "type"

obj-info = obj-id SP [obj-val *(SP obj-val)]

If the server does not recognize the object id, the response will be obj-id SP regardless of the number of attributes requested.

What I’ve learned§

Well, when I started all my code was a solo-job this means I used the PRs because I knew it was the “correct” way and I felt cool like “oh wow, this looks like a real job”.

Working with Karthik and Chandra has taught me a lot, consistency matters a lot and have I said that consistency matters a lot? Most of my doubts were answered with:

What do other relevant areas do?

I learned to read code and understand it faster, working solo, (unless you turbo vibe code things) you know all the codebase, so having to work on an already started series has made me read code that I didn’t write nor I was familiar with, and that’s without talking about that I had to bring this series up to master dealing with conflicts.

These are things that were new to me.

I’ve had to “learn” how to investigate about how the things I’m dealing with work, read others’ series to understand their changes and how they affect my series.

Now I think that if I had to start over again, it wouldn’t take me as long as it took me on the first time.

I’m still “wow” with how others on the mailing list are able to review and understand code as fast as they do, that makes me want to improve to get to their level.

What will come next?§

I think everything’s going as the timeline expects. Hopefully the first part gets the OK this v15, maybe a v16 because of some nits, but it’s close to being “done”.

After that the next series is the end to end %(objecttype) support which after the first series which is big, this second one is far smaller.

If there is time to do more we would need to discuss some things:

Are more atoms like %(size:disk) worth implementing? I’m not saying that implementing them is challenging, it’s the exact same process as the one done for %(objecttype). But other atoms and their metadata are server-intrinsic, What I mean is that it is metadata that once fetched it will change, differently from name, size and type the rest of them are not guaranteed to be the same after being fetched. If the motivation is to check before fetching for example, why would we want to check something that will become meaningless. I’m just not sure about them.
Firstly, I’m not a git backfill user but I saw a series about it some months ago and thought that this object-info infrastructure that we are building here could be used for a git backfill <path> --dry-run option. It would work similarly but instead of fetching the missing blobs it would tell you how much space it would take and how many blobs would be fetched:

$ git backfill src/ --dry-run
 backfilling src/ would take 47 MiB and would fetch 50 blobs

Apart from GSoC§

I still feel a bit intimidated by the mailing list, even if I now like it, I still feel that what I send needs to be serious and perfect (even though I make the most stupid mistakes like failing to remove cc from trailers)

I’ve been talking with Yuchen, another GSoC at Git contributor and he’s very nice. Now I can send him CS memes ;)).

We talked about our GSoC projects and a project I have which is a search engine for git’s commits using singular value decomposition. I have to study some more linear algebra to implement the known optimizations but I like the idea where it is going.

I also want to see Siddhart and Jayatheerth at Lisboa where Git Merge will be held.

These last weeks I’ve been busy with the paperwork of Erasmus because my next year I’ll be studying abroad at Lisboa for a whole year.

I also want to start grinding LeetCodes to get better at DSA.

Well, see you next week with more about my GSoC journey. As always any idea, feedback or opinion is always welcome.

GSoC Week 2 First Feedback Round

Tue, 09 Jun 2026 20:07:19 +0200

This week I finally sent what I consider my first version to the mailing list, well technically it’s v12, but it’s the first one for me.

Getting to v12§

The process was more tedious than what I expected, not because of the code itself, but because I’m starting from someone else’s commits and it hits different than starting from scratch. When it’s my own patch I know what to do but here it was reading what was done and the feedback from previous versions.

Karthik gave me his first private review of last week’s work and I started working on it. Saturday night I almost lost half my changes… it wasn’t very funny at that moment but my face after realizing I had obliterated half the rebase by mistake must have been worth to see.

At the end, starting from 8 commits we landed on 12, wanting to keep it concise and focused on end-to-end support for %(objectsize). The commits I added are:

A memory leak fix.
Splitting a move + refactor into two separate commits.
My two commits for the allow-list.

What do we have now§

If you read last week’s post, this is (very simplified) how it’s behaving now:

The client asks for size and type, the server only supports size, so it returns the size and an empty string for the unsupported placeholder.

New problems: unsupported vs empty-valued§

Karthik had a point: we’re building end-to-end support for %(objecttype) and %(objectsize), and the empty string behavior works fine for both of them but what about other placeholders?

The short answer is that is not great for all of them. %(objectmode) and %(rest) can return an empty string. So now we have a conflict between:

A placeholder the server doesn’t support -> returns empty string.
A placeholder the server supports, but its value is empty -> returns empty string.

The empty string approach was suggested by Jeff King and it honors what for-each-ref does for known but inapplicable atoms, but it seems like it might not be the right fit here, other thing that we could do is to use a placeholder, something like "???", the placeholder needs to be noticeable and can’t be a plausible value for any other placeholders.

This first round to the mailing list comes with the empty string behavior anyway. We thought it would be better to get more eyes on the series, but I’ve left this open question in the cover letter 1 in case someone has a better idea or thinks that the placeholder would be better. Hearing opinions would be great.

Apart from GSoC§

I also updated my Git this week.

I like to code and make “empty” commits maybe a word or two to distinguish them to later come and write them properly, with all this rebasing I was doing I wanted a way to edit commits directly without having to get into the interactive rebase every time. Turns out there’s a new command, git history, that does exactly that, how have you guys survived without it?.

As for the graph patch I mentioned last week, it’s almost done but I’m a bit frustated with it, some flags affect the rendering order and makes me hard to write the expect on tests to show what I want. And then there’s Windows… some tests there seem to just ignore my patch entirely. Oh, I love Windows so much… I’ll try to wrap it up this week.

See you next week,

Pablo.

v12 cover letter

GSoC Week 1 Coding Period

Tue, 02 Jun 2026 14:51:28 +0200

I believe that being able to see something helps a lot with the comprehension so expect a lot of schemas about what I do from now on.

First, I’ll explain what this project consists of in simple terms.

This project is the continuation of Eric Ju’s and Calvin Wan’s work on remote-object-info for the cat-file command plus extending it to support %(objecttype).

What does `remote-object-info` do?§

When you use git cat-file --batch-command with info, it only queries locally. If the OID doesn’t exist in your local repo it returns <OID> missing and doesn’t fetch anything. remote-object-info aims to extend this to make fetching the object metadata remotely from the server viable, without having to download them beforehand. Why fetch the full object when you just want its size or type?

The project goes back to 2021 with Calvin’s protocol v2 extension for object-info and last year Eric’s series that brings that extension up to the client side at the cat-file --batch-command. Eric’s work never got merged due to unresolved issues. Here is where I start.

What I did this week§

Well Git is always very active and from last year until today, a lot has happened and Eric’s series had some conflicts that needed to be resolved before starting with the project.

I had already started some days ahead of the coding period because I wanted to resolve all the conflicts to start from day 0 coding and thinking what I have to do.

The first part of my project consists of addressing the feedback left from Eric’s v11, mostly style, but one important part about how the unsupported placeholders are handled.

Static allow-list for remote placeholders§

Eric’s code used strstr() to validate the placeholders, which was not enough. Unsupported placeholders like %(objecttype) caused segfaults or dies directly. The idea is to replace this with an allow-list in expand_atom() that returns an empty string for unsupported placeholders, as Jeff King suggested.

I first thought of a simple static list where the supported placeholders were.

But this static allow-list has a problem

The backward and future compatibility of this approach is very poor if not non-existent.

This static approach is only reliable if the client and the server support the same capabilities.

Dynamic allow-list§

We have to think about the client as an “all-knower” it knows every placeholder option and it can ask whatever it wants and the server as an “authority” that the client has to obey.

So the client is the one who needs to adapt to what the server can provide without the need of the user to know what the server advertises.

This approach solves the client vs different servers making servers that only support size and future ones that support more options can be fetched by the same client.

This hasn’t been posted on the mailing list yet so it might change. But I really think this is the right approach, though with the empty strings we now have a problem: known but unsupported vs empty data. Placeholders like %(rest) and %(objectmode) can return an empty string, so, how do we differentiate unsupported placeholders that return an empty string vs the ones which their data is genuinely empty? Even if these placeholders are out of the scope currently, they will be implemented in the future so we have to think about this, as this will be the foundation for the rest of the placeholders.

Also, I still have a pending patch about indentation of visual roots at git log --graph, which I’m giving its final tweaks with the help of my great mentors Karthik and Chandra but I’ll keep this post focused on GSoC.

I enjoy making reviews also, it’s really cool to discuss and learn, so I try to read what is sent to the mailing list.

What to expect§

If this continues, the client could fill the allow-list to handle every placeholder as if it was local leaving only the server side work to implement for %(objecttype) and the rest of options that will come in the future.

Once we have the client side done, I’ll start with the server side to implement %(objecttype), and who knows, if there is time I want to add more support for more metadata.

I’m having lots of fun already and I’m very thankful to both my mentors Karthik and Chandra who are very supportive and helpful.

See you next week,

Pablo.

GSoC Week 1 Community Bonding

Tue, 05 May 2026 15:52:13 +0200

Last april 30th I started my GSoC at Git, and it’s been a few days already. This week has been more about what I’m gonna do rather than doing, but I think that having a clear plan will be worth.

This week I had the GSoC 2026 welcome meeting, I also have scheduled meetings with my mentors and the other three Git GSoC students. I’m excited about it :).

As part of my work is rebasing previous work, I’ve been reading what is left to do, good thing that most of what I have to do I had it already noted on my proposal. Rebasing was harder than what I expected, but mostly because I’m not used to having to deal with manual conflicts as most of the time I code alone, I knew one file got deleted so I had to trace what had happened with it.

I’d like to say that I’ve improved, with who I was before starting GSoC because tracing the history was an easy part, I could say I’m liking the mailing list. As it is community bonding I’m trying to be more active at the mailing list rather than patches I’m trying to review other’s work with what I know.

Even though it’s still community bonding, I’ve already started with the rebase and feedback left to do. But I need to read more docs to be sure that I understand everything and make sure I’m doing it correctly.

Pre GSoC

Sat, 02 May 2026 10:33:00 +0200

This post might be longer than others because it summarizes ~2 months of thoughts and the process of applying to GSoC.

Around 2 months before the GSoC opening for proposals submissions a friend of mine Paco told me about GSoC and encouraged me to apply. I’ve never heard about it before, but it sounded really interesting. I started looking for organizations and projects where I could fit, I thought about Llvm due to my interest in compilers sounded like a good fit, but I haven’t got into llvm as much as I’d like to and the projects weren’t something I felt a deep interest in.

Then I found Git, a few months before this I tried to start contributing to it, it is something I wanted because it is something I use everyday and contributing to it sounds so cool. But I didn’t because when I started looking into it, it felt massive and overwhelming, at that time I didn’t know what a mailing list was and the project felt intimidating.

Seeing Git as a GSoC organization was a click moment, I thought –This is it– Git has some requirements before sending a valid proposal, so I left choosing the project for later and focused on doing the requirements.

The coding itself in the microproject isn’t hard, the hard part was to know how things work in Git, making a patch, committing with git commit -s expressing correctly the git commit message and then sending it to the mailing list, which looked like the hell of designers.

First time I sent the patch multiple times to myself to make sure it was correct, I thought –These guys must be so serious, one error and I’m out– Jokes on me, Junio Hamano replied to my patch very quickly and helped me with everything I had wrong. After that, I felt more confident, once I got the patch accepted after a few rounds of review, I searched for more small parts to contribute to. I wanted to show that I wanted this and I wasn’t just a guy who does the bare minimum and then applies hoping for the best, I wanted to show that I was really interested.

I made some more contributions that weren’t just updating tests and after I felt confident I started looking at what the proposed projects for GSoC were. I chose the last one Complete and extend the remote-object-info command for git cat-file because it involved networking, something I had just studied at university, and I think it’s really cool.

This project was continuing work of two previous GSoC students, so I had a lot of things to read about before writing anything. I read all the cover letters for each version they sent noting what they’ve done in each one and for the last one I read what was left to do (bugs, features, style, etc). Once I knew what I was getting into, luckily, there were other proposals with feedback in the mailing list which helped me to know how I should write the proposal and what I should include in it. Writing the proposal took about a whole week having it as my main priority. I wrote it a few times before liking it. I could say that the hardest part was to write the timeline, at university you are given a deadline and that’s it, you don’t need to think what you will do in each week and how much time will it take. The second hardest part was the problem and solution, those parts are where you show that you’ve understood the problem, what’s already done and what I will do. For me, this being a continuation there was a lot of feedback about what was left to do, so I had to understand it for my proposed solution.

Sending the proposal v1 the day the application was open (16th March) was a mental checkpoint, I believe first impressions are important and I was proud of what I did, I got feedback for it and wrote a few versions during the application period 16th March - 30 March, while waiting for feedback about my proposal I kept contributing to Git to become more familiar with it and to have a stronger proposal. I didn’t just make patches, I also got involved in RFCs, made a few reviews and helped newcomers with their microproject for GSoC as Junio helped me.

After the application period, I was really proud of what my proposal was, I believe I was a strong candidate. I must say that the nervousness was real and even being more confident about what I can do I couldn’t get rid of the fear. I have no words to describe it but, this fear worked for me to be motivated to give the best of me until the results. After 30th March I had a whole month until the results, I kept contributing to Git, and I’m still doing it as there are still some weeks until the coding period starts. I kept up with my projects and studying for university.

30th April, The day had come. The results weren’t out until 20:00 (Spain is UTC+2 after the clocks change in spring). Once the results were out, and I received the email where it said that I was accepted, I was at the gym and I probably had the best workout of my life. I told my friends and family about it, I was really really happy, the next day I sent an email to my mentors Karthik who works at Gitlab and Chandra to thank them for selecting me and asking about the next steps which brings us here writing this blog post.

Summarizing, I believe that the process of applying to GSoC even if you are not selected still teaches you a lot and it’s worth all the time you spend on it. I think that applying to GSoC isn’t an excluding process where you need to be an expert or the best of your university, I think it’s doable by anyone who is interested and willing to put the effort to do it, and I’ll encourage more of my friends to apply next year.

Introduction

Sat, 02 May 2026 09:42:53 +0200

Hi!

My name is Pablo, this is my first time blogging, so… don’t expect amazing writing skills but I’ll do my best to try to share my experience through my journey at GSoC Git 2026 mentored by Karthik who works at Gitlab and Chandra.

I’m 19 years old and a second year Computer Science student at the University of Murcia, Spain. I love programming and I’m really interested about compilers and how things work under the hood. I mostly program in C but I also have experience with Java and typescript.

I started programming some years ago, close to 15 when I wanted to make a discord bot for my friends and me.

Besides programming, I love to cook and going to the gym.

The last project I’m working on is a compiler for my own programming language called Orn. Orn is a low level systems programming language that brings a Typescript inspired syntax and a soft learning curve so developers coming from high level languages can easily get into it.

Orn is not finished yet, but it is close to a v1.

Open-Source · Pablo Sabater

GSoC 2026 with Git

Complete and extend the remote-object-info command for git cat-file§

About the project§

About cat-file and object-info protocol§

Prior work§

The problem§

The goal§

What was implemented§

Goal 1 series: remote-object-info in --batch-command (v21, 13 patches)§

Goal 2 series: end-to-end for %(objecttype) (v6, 10 patches)§

Backward compatibility§

Learning from git§

Could it have been done better?§

How do I plan to keep working§

Not just GSoC§

GSoC Week 11

GSoC Week 10

GSoC Week 9

GSoC Weeks 7 and 8

GSoC Week 6 and Half 7

%(objecttype) support series§

Graph indentation series§

Extending other commands with object-info protocol§

GSoC Week 4 & 5 Coding Period

What does remote-object-info do?§

Where did I start and what has been done§

What do we have to do to support %(objecttype)?§

How will the object-info protocol look?§

What I’ve learned§

What will come next?§

Apart from GSoC§

GSoC Week 2 First Feedback Round

Getting to v12§

What do we have now§

New problems: unsupported vs empty-valued§

Apart from GSoC§

GSoC Week 1 Coding Period

What does remote-object-info do?§

What I did this week§

Static allow-list for remote placeholders§

Dynamic allow-list§

What to expect§

GSoC Week 1 Community Bonding

Pre GSoC

Introduction

About `cat-file` and `object-info` protocol§

Goal 1 series: `remote-object-info` in `--batch-command` (v21, 13 patches)§

Goal 2 series: end-to-end for `%(objecttype)` (v6, 10 patches)§

What does `remote-object-info` do?§

What does `remote-object-info` do?§