As libgit.a moves away from using fixed size buffers, there is no
guarantee that PATH_MAX is sufficient for all of the paths in a Git
tree, so we should use a dynamically sized buffer here.
Coverity-Id: 141884
Signed-off-by: John Keeping <john@keeping.me.uk>
Free the taginfo when we're done with it. Also reduce the scope of a
couple of variables so that it's clear that this is the only path that
uses the taginfo structure.
Coverity-Id: 141883
Signed-off-by: John Keeping <john@keeping.me.uk>
If we have only a single element in a directory (for example in Java
package paths), display multiple directories in one go so that it is
possible to navigate directly to the first directory that contains
either files or multiple directories.
Signed-off-by: John Keeping <john@keeping.me.uk>
git.git's coding style avoids decl-after-statement and we generally try
to follow it but a few warnings have crept in recently. Fix the one in
ui-ssdiff.c
Signed-off-by: John Keeping <john@keeping.me.uk>
git.git's coding style avoids decl-after-statement and we generally try
to follow it but a few warnings have crept in recently. Fix the ones in
ui-shared.c
Signed-off-by: John Keeping <john@keeping.me.uk>
Currently we can end up passing EOF to isspace(), which is in fact
libgit's sane_isspace which does:
((sane_ctype[(unsigned char)(x)] & (GIT_SPACE)) != 0)
It is very unlikely that EOF cast to "unsigned char" will end up in a
character that has the GIT_SPACE bit set, but the standard only requires
that EOF be a negative integer, so it could access any value in the
sane_ctype array.
If it does end up returning true for isspace() then this loop will never
terminate, so handle EOF as a special value in the same way as the other
loops in this function.
Signed-off-by: John Keeping <john@keeping.me.uk>
Upstream continues to replace unsigned char *sha1 with struct
object_id old_oid. This makes the required changes.
The git lib has its own main function now. Rename our main function
to cmd_main, it is called from main then.
Not sure if there's a better fix for this. defbranch is
NULL here on my setup when a crawler hit an invalid URL,
causing strcmp to segfault.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
When composing snapshot file names for a tag with a prefix of the form
v[0-9] (resp. V[0-9]), the leading "v" (resp. "V") is stripped. This
leads to conflicts if a tag with the stripped name already exists or if
there are tags only differing in the capitalization of the leading "v".
Make sure we do not strip the "v" in these cases.
Reported-by: Juuso Lapinlampi <wub@partyvan.eu>
Signed-off-by: Lukas Fleischer <lfleischer@lfos.de>
Otherwise we get the classic Python UTF-8 errors, and the text is all
out of order. While we're at it, switch to python3 so we only have to
support one set of oddball semantics.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Suggested-by: Daniel Campbell <dlcampbell@gmx.com>
Update to git version v2.8.2.
* Upstream commit 1a0c8dfd89475d6bb09ddee8c019cf0ae5b3bdc2 (strbuf: give
strbuf_getline() to the "most text friendly" variant) changed API.
Signed-off-by: Christian Hesse <mail@eworm.de>
The decoration code inside of git returns the decoration type, so
utilize this to create the decoration spans. Additionally, use
prettify_refname(...) to get the shorter name for the ref.
Signed-off-by: Tim Nordell <tim.nordell@logicpd.com>
The decoration span does not need to be emited if there aren't
any decorations to show. This modification saves slightly
on bandwidth.
Signed-off-by: Tim Nordell <tim.nordell@logicpd.com>
Your mileage may vary, but for me the old icon looks blurry. The new
one is character 0xf08e from OTF font awsome in size 10.
The icon color is black, gray level is adjusted via opacity.
Signed-off-by: Christian Hesse <mail@eworm.de>
This is to fix the case of accessing http://host.com/cgit.cgi/repo.git/plain/
There is code here to make this case work (match_baselen is set to -1
for top-of-the-tree views) but the unsigned to signed comparison was
always false in this case, causing an empty directory listing without
this fix.
Signed-off-by: Joe Anakata <jea-signup-github@anakata.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Git's DATE_STRFTIME ignores the timezone argument and just uses the
local timezone regardless of whether the "local" flag is set.
Since Atom accepts ISO8601 dates [1], we can use Git's
DATE_ISO8601_STRICT instead, which does get this right. Additionally,
we never use the local timezone here so we can use the
date_mode_from_type() wrapper to simplify the code a bit.
[1] https://tools.ietf.org/html/rfc4287#section-3.3
Signed-off-by: John Keeping <john@keeping.me.uk>
Git's DATE_STRFTIME ignores the timezone argument and just uses the
local timezone regardless of whether the "local" flag is set.
Since our existing FMT_LONGDATE and FMT_SHORTDATE are pretty-much
perfect matches to DATE_ISO8601 and DATE_SHORT, switch to taking a
date_mode_type directly in cgit_date_mode().
Signed-off-by: John Keeping <john@keeping.me.uk>
We abuse the "void *util" field as a counter and recently started to
cast it to a uintptr_t to avoid risking nasal demons by performing
arithmetic on a void pointer.
However, compilers are also known to do "interesting" things if they
know that a pointer is or isn't NULL. Make this safer by checking if
the counter (after casting) is non-zero rather than checking if the
pointer is non-null.
Signed-off-by: John Keeping <john@keeping.me.uk>
