| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- actually implement HTML escaping;
- include cached_run for (hopefully) reusing across HTML generating
functions;
- include the repository name on the $CACHE_DIR;
- use the existence of a .asc file to decide on which HTML to output on
the refs page;
- implement all FIXMEs but the WIP one on the commit HTML generation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I got a bit frustrated that libgit2 didn't offer an API
or "git archive" commands. I started implementing generating tarballs
from scratch in src/tar.c and I'm quite liking it: the specification is
very small, and the code can be very simple, since all I'm doing is
writing fresh tarballs, and not reading or updating them.
However I felt a bit locked-in to libgit2 itself, and what a detour from
my original goal that is, and the question "what should libgit2 provide"
came up to my mind. This made me realize that libgit2 is playing
catch-up with Git itself, for as long as Git doesn't explicit has an
explicit API, a standard, a public version of its internal libgit.a, or
something like that. In fact, I'm locked in to Git, even.
So even though a C version would probably be much faster, it wouldn't
really have less dependencies, and that's what I'm actually optimising
for: having the software be as portable as possible. On that front, C
is unbeatable with sh as a close second. But the extreme portability
of C aren't being fully exploited here: libgit2 does depend on non-POSIX
things like CMake (and quick grep even shows
references to -D_GNU_SOURCE!!), and Git's Makefile itself isn't POSIX
at all. The point is: by depending on either Git or libgit2, I'm
already loosing many selling points of writing the software in C, and
sh becomes much more attractive. Had existed a common DVCS interface
that could make me decouple gistatic from Git somehow I would insist a
bit more in C, but now I'm switching to sh.
The fact that I was able to get further with sh in one sitting than I
did with C shows that a) I'm a bit less fluent in C than I would like
(at least for now ^^) and b) that it is actually much simpler to do.
I am quite satisfied with the quality of C code that I got so far. The
error handling and propagation is pretty robust, and the implementation
is very disciplined. I did most of the development with Valgrind, and
other sanitizers would help even further, with some fuzzers on top.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of this change is two-fold:
- make function and variable declarations grep-friendly (one can use a
pattern /^fn_name/ to find the definition);
- make the lines shorter, so less functions need to have their arguments
span over many lines.
This is more grep-friendly both for finding the function definition, but
also for matching on the return type of the function or the variable.
Update tests/c-lint.sh to enforce this.
|
| |
|
| |
|
| |
|
|
|
|
| |
src/tar.c
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Git references
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of each .c file becoming a self-standing .t executable file,
and being run for executing the unit tests local to the file, now each
.c becomes a .to object (akin to a .o object, but one where the -DTEST
flag is given to the compiler). After that, all the .to objects are
linked together in a gistatic-tests executable, in a equivalent way
that all .o files get linked together in a gistatic executable.
This change was necessary in order to allow dependencies between
objects. The next task will be making a tar of a repository tree
checkout, and src/gistatic.{o,to} will start depending on
src/tar.{o,to}. If each file has its own main function when -DTEST is
given, then I wont be able to link them together.
I took the opportunity that I had to change the Makefile, and I
improved the dependency between targets and dependencies greatly. From
what I can tell now, it is correct.
|
| |
|
|
|
|
| |
table in refs.html
|
| |
|
|
|
|
| |
content
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is more accessible, as the links have the extra visual queue that
they're links.
|
| |
|