This was a tough week and borderline unproductive. I spent the majority of the first half of the week reading logs, trying to get a good approach on Hariom’s idea. The whole weekend was just me sitting and thinking about a way to implement the idea in a maintainable and efficient manner.

The whole idea is based upon the fact that we should use ref-filter logic in pretty wherever possible and to do that we need to know if the atom corresponding to the placeholder exists. My approach to implementing the idea was using a atom-placeholder map which would have all the atoms (through enum atom_type in ref-filter) mapped to their corresponding placeholders. Now, if we want to know if a correspondence exists, we just need to look up the map and we’ll know (see this branch).

Apart from being a mediocre idea, this has flaws which were not apparent when I was just thinking about the implementation but not actually implementing it (writing code). The biggest of them all is that the enum atom_type and the structs that it is a field of and the functions that make use of it and the structs are all internal to ref-filter.c (that is, they are defined as statics and cannot be used by other files).

struct placeholder_atom_map {
	char *placeholder;
	enum atom_type atom;
} placeholders[] = {
	{ "some placeholder", EQUIVALENT_ATOM }
};

static int in_ref_filter(char *pl)
{
	look up the map;
	if (found)
		return 1;
	return 0;
}

static size_t format_some_placeholder(related args, char *placeholder)
{
	if (in_ref_filter(placeholder)) {
		use ref-filter logic;
		return placeholder_len;
	}
	use pretty logic as usual;
	return placeholder_len;
}


So the above code won’t work and it is obvious that to make it work, we need to change things in ref-filter.c and ref-filter.h and it is exactly this that makes it a bad approach.

I told Christian and Hariom about this and they suggested that I look at some of Hariom’s previous work on this (Hariom’s commit about ref-filter printing commits and commit about making pretty use ref-filter logic ).

What’s happening on the main side of things?

As mentioned in my previous post, the above is essential for testing purposes only. So on the main side of things, I have been working on a transition table between ref-formats and pretty formats. I have also started work on duplication of other placeholders into atoms and the one I’m currently working on is %(describe[:options]).

This format gives a human-readable form of an object.

For a blob, this is given as a <commit-ish>:<path>, where <commit-ish> describes the first commit in which the blob occurs in a reverse revision-walk from HEAD.

For a commit, it goes to the most recent tag, suffixes it with the number of commits on top of it and the abreviated object name of the most recent commit.

For a tag, it just plainly shows the most recent tag. By default, it only shows annotated tags but we can also describe lightweight tags using --tags.

‘til next time,
Kousik