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>
When clicking on "log" from a tag we end up showing the log of whatever
branch we used to reach the tag. If the tag doesn't point onto a branch
then the tagged commit won't appear in this output.
By linking to tags with the head parameter instead of the "id" parameter
the log link will show the log of the tag. This is clearly desirable
when the tag has been reached from the refs UI and changing the
behaviour for tag decorations makes them match branch decorations where
log -> decoration -> log shows the log of the decoration.
Reported-by: Ferry Huberts <mailings@hupie.com>
Signed-off-by: John Keeping <john@keeping.me.uk>
This will allow us to reuse the same logic to add clone URL <link/>
elements to the header of all repo-specific pages in order to support
the rel-vcs microformat.
Signed-off-by: John Keeping <john@keeping.me.uk>
Jason A. Donenfeld
Juuso Lapinlampi
John Keeping
Lukas Fleischer
Christian Hesse
Lukas Fleischer