All cgit_xxx_link functions take const char* for the 'name' parameter,
except for cgit_commit_link, which takes a char* and subsequently
modifies the contents. Avoiding the content changes, and making it
const char* will avoid the need to make copies of const char* strings
being passed to cgit_commit_link.
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: John Keeping <john@keeping.me.uk>
The ui-blame code will also need to call set_title_from_path, so go
ahead and move it to ui-shared.
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Reviewed-by: John Keeping <john@keeping.me.uk>
cgit_print_path_crumbs() can call repolink() which assumes that ctx.repo
is non-null. Currently we don't have any commands that set want_vpath
without also setting want_repo so it shouldn't be possible to fail this
test, but the check in cgit.c is in the wrong order so it is possible to
specify a query string like "?p=log&path=foo/bar" to end up here without
a valid repository.
This was found by American fuzzy lop [0].
[0] http://lcamtuf.coredump.cx/afl/
Signed-off-by: John Keeping <john@keeping.me.uk>
Upstream git is replacing 'unsigned char sha1[20]' with 'struct object_id
oid'. We have some code that can be changed independent from upstream. So
here we go...
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>
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>
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>
This affects the tooltip showing the full time and the case when a date
is sufficiently old to be shown in full rather than as an offset.
Signed-off-by: John Keeping <john@keeping.me.uk>
This returns the correct mode value for use with Git's show_date() based
on the current CGit configuration and will be used in the following
patches.
Signed-off-by: John Keeping <john@keeping.me.uk>
The ctx.qry.page variable might be unset at this point, e.g. when an
invalid command is passed and cgit_print_pageheader() is called to show
an error message.
Signed-off-by: Lukas Fleischer <lfleischer@lfos.de>
Update to git version v2.7.0.
* Upstream commit ed1c9977cb1b63e4270ad8bdf967a2d02580aa08 (Remove
get_object_hash.) changed API:
Convert all instances of get_object_hash to use an appropriate
reference to the hash member of the oid member of struct object.
This provides no functional change, as it is essentially a macro
substitution.
Signed-off-by: Christian Hesse <mail@eworm.de>
Most errors we generate are (potentially) transient, such as
non-existent object IDs so we don't want them to be cached forever.
Signed-off-by: John Keeping <john@keeping.me.uk>
These will avoid needing to call three functions to start page layout in
subsequent patches when we move the layout setup into each individual
page.
Signed-off-by: John Keeping <john@keeping.me.uk>
This will allow us to generate error responses with the correct HTTP
response code without needing all of the layout boilerplate.
Signed-off-by: John Keeping <john@keeping.me.uk>
Commit caed6cb (ui-shared: show absolute time in tooltip for relative
dates, 2014-12-20) added a toolip when we show a relative time.
However, in some cases we show a short date (that is, the date but not
the time) if an event was sufficiently far in the past and that commit
did not update that case to add the same tooltip.
Signed-off-by: John Keeping <john@keeping.me.uk>
Teach the "log" UI to behave in the same way as "git log --follow", when
given a suitable instruction by the user. The default behaviour remains
to show the log without following renames, but the follow behaviour can
be activated by following a link in the page header.
Follow is not the default because outputting merges in follow mode is
tricky ("git log --follow" will not show merges). We also disable the
graph in follow mode because the commit graph is not simplified so we
end up with frequent gaps in the graph and many lines that do not
connect with any commits we're actually showing.
We also teach the "diff" and "commit" UIs to respect the follow flag on
URLs, causing the single-file version of these UIs to detect renames.
This feature is needed only for commits that rename the path we're
interested in.
For commits before the file has been renamed (i.e. that appear later in
the log list) we change the file path in the links from the log to point
to the old name; this means that links to commits always limit by the
path known to that commit. If we didn't do this we would need to walk
down the log diff'ing every commit whenever we want to show a commit.
The drawback is that the "Log" link in the top bar of such a page links
to the log limited by the old name, so it will only show pre-rename
commits. I consider this a reasonable trade-off since the "Back" button
still works and the log matches the path displayed in the top bar.
Since following renames requires running diff on every commit we
consider, I've added a knob to the configuration file to globally
enable/disable this feature. Note that we may consider a large number
of commits the revision walking machinery no longer performs any path
limitation so we have to examine every commit until we find a page full
of commits that affect the target path or something related to it.
Suggested-by: René Neumann <necoro@necoro.eu>
Signed-off-by: John Keeping <john@keeping.me.uk>
Update to git version v2.5.0.
* Upstream commit 5455ee0573a22bb793a7083d593ae1ace909cd4c (Merge branch
'bc/object-id') changed API:
for_each_ref() callback functions were taught to name the objects
not with "unsigned char sha1[20]" but with "struct object_id".
* Upstream commit dcf692625ac569fefbe52269061230f4fde10e47 (path.c: make
get_pathname() call sites return const char *)
Signed-off-by: Christian Hesse <mail@eworm.de>
Instead of linking to the current page ("href='#'"), do not add a link
to a submodule entry at all if the module-link setting is not used.
Signed-off-by: Lukas Fleischer <cgit@cryptocrack.de>
Sparse complains that we are using a plain integer as a NULL pointer
here, but in fact we do not have to specify a value for this variable at
all since it has static storage duration and thus will be initialized to
NULL by the compiler.
Signed-off-by: John Keeping <john@keeping.me.uk>
