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>
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>
If parse_commit() fails, none of the fields in the commit structure will
have been populated so we will dereference NULL when accessing
item->tree.
There isn't much we can do about the error at this point, but if we
return true then we'll try parsing the commit again from print_commit()
and we can report an error to the user at that point.
Coverity-id: 13801
Signed-off-by: John Keeping <john@keeping.me.uk>
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>
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>
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 is slightly more involved than just bumping the version number
because it pulls in a change to convert the commit buffer to a slab,
removing the "buffer" field from "struct commit". All sites that access
"commit->buffer" have been changed to use the new functions provided for
this purpose.
Signed-off-by: John Keeping <john@keeping.me.uk>
If you search for a bogus range string here:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/
Using something like "range" and "qwerty123456", it returns an "Internal
Server Error" and the following in the logs:
> [Tue Jun 10 17:45:32 2014] [error] [client 172.21.1.6] fatal:
> ambiguous argument 'qwerty123456': unknown revision or path not in the
> working tree., referer:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
> [Tue Jun 10 17:45:32 2014] [error] [client 172.21.1.6] Use '--' to
> separate paths from revisions, like this:, referer:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
> [Tue Jun 10 17:45:32 2014] [error] [client 172.21.1.6] 'git <command>
> [<revision>...] -- [<file>...]', referer:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
> [Tue Jun 10 17:45:32 2014] [error] [client 172.21.1.6] Premature end
> of script headers: cgit, referer:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
The cache will kick in, so if you search for the same string again,
it'll show an empty range, so you have to change the bogus strings each
time.
This is because we just pass the arguments straight to Git's revision
parsing machinery which die()s if it cannot parse an argument, printing
the above to stderr and exiting.
The patch below makes it a bit friendlier by just ignoring unhandled
arguments, but I can't see an easy way to report errors when we can't
parse revision arguments without losing the flexibility of supporting
all of the revision specifiers supported by Git.
Reported-by: Konstantin Ryabitsev <mricon@kernel.org>
prefixcmp() and suffixcmp() have been remove, functionality is now
provided by starts_with() and ends_with(). Retrurn values have been
changed, so instead of just renaming we have to fix logic.
Everything else looks just fine.
Since the email filter is called from lots of places, the script might
benefit from knowing the origin. That way it can modify its contents
and/or size depending.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
* Name "cgit Development Team" as copyright holder to avoid listing
every single developer.
* Update copyright ranges.
Signed-off-by: Lukas Fleischer <cgit@crytocrack.de>
Instead of using our own vector implementation, use argv_array from Git
which has been specifically designed for dynamic size argv arrays.
Drop vector.h and vector.c which are no longer needed.
Signed-off-by: Lukas Fleischer <cgit@cryptocrack.de>
This helps projects that have a large number of tags to display them all
using custom CSS.
The default stylesheet has not been updated since what is useful for
projects with a lot of tags is not the same as what is useful for
projects with only a small number of decorations per commit.
Suggested-by: Konstantin Ryabitsev <mricon@kernel.org>
Signed-off-by: John Keeping <john@keeping.me.uk>
While doing any kind of git loading, unset HOME variables and set
NOSYSTEM variables so that cgit does not load any settings that a user
may have set for his own /usr/bin/git usage.
This fixes a fatal error introduced with git 1.8, whereupon git would
fatally exit when failing to access particular files.
The result of this is that only repo-local configuration files are
accessed:
zx2c4@thinkpad ~/Projects/cgit $ HOME=/root QUERY_STRING="url=foo/log"
CGIT_CONFIG=tests/trash/cgitrc strace -e access ./cgit >/dev/null
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
access("repos/foo/.git/objects", X_OK) = 0
access("repos/foo/.git/refs", X_OK) = 0
access("repos/foo/.git/config", R_OK) = 0
access("repos/foo/.git/config", R_OK) = 0
access("repos/foo/.git/objects/b3/bafdbf0183f4897ef8b1319cb8c490ed54717e", F_OK) = 0
access("repos/foo/.git/objects/b3/bafdbf0183f4897ef8b1319cb8c490ed54717e", F_OK) = 0
access("repos/foo/.git/objects/b3/bafdbf0183f4897ef8b1319cb8c490ed54717e", F_OK) = 0
access("repos/foo/.git/objects/b3/bafdbf0183f4897ef8b1319cb8c490ed54717e", F_OK) = 0
+++ exited with 0 +++
Reported-by: Ferry Huberts <ferry.huberts@pelagic.nl>
Tested-by: Jason A. Donenfeld <Jason@zx2c4.com>
Tested-by: Ferry Huberts <ferry.huberts@pelagic.nl>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Use "struct strbuf" from Git to remove the limit on file path length.
Notes on scan-tree:
This is slightly involved since I decided to pass the strbuf into
add_repo() and modify if whenever a new file name is required, which
should avoid any extra allocations within that function. The pattern
there is to append the filename, use it and then reset the buffer to its
original length (retaining a trailing '/').
Notes on ui-snapshot:
Since write_archive modifies the argv array passed to it we
copy the argv_array values into a new array of char* and then free the
original argv_array structure and the new array without worrying about
what the values now look like.
Signed-off-by: John Keeping <john@keeping.me.uk>
While doing this, remove declarations from header files where the
corresponding definition is declared "static" in order to avoid build
errors.
Also re-order existing headers in ui-*.c so that the file-specific
header always comes immediately after "cgit.h", helping with future
consistency.
Signed-off-by: John Keeping <john@keeping.me.uk>
This requires a small change to how we handle notes, but otherwise just
works.
Note that we can't use anything from v1.8.0 until v1.8.2.1 because some
of the symbols that we need for graph drawing were made private in
v1.8.0 and this was not reverted until v1.8.2.1.
Signed-off-by: John Keeping <john@keeping.me.uk>
It is common practice and semantically appropriate to use unordered
lists for long navigation lists.
This also fixes the layout of very long pager navigations in
Webkit-based browsers.
Signed-off-by: Lukas Fleischer <cgit@cryptocrack.de>
This fixes a couple of minor oversights in previous commits and adjusts
all cells using colspan to use the correct width.
Signed-off-by: Lukas Fleischer <cgit@cryptocrack.de>
This makes it possible to use strict commit date ordering or strict
topological ordering by passing the corresponding flags to "git log".
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
The link url wasn't properly escaped, and since the link was identical
to the one used on the commit message it didn't serve any special purpose.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
You should be able to independently switch file and line count on and
off. This patch makes the code work like the documentation suggests: no
dependency for line counts to be displayed only when file counts are.
Signed-off-by: Julius Plenz <plenz@cis.fu-berlin.de>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
When the commit graph is present, we prefer to draw it along the left edge,
and moving the 'Age' column to the right of the 'Author' column, like in gitk.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
When showmsg is disabled ui-log truncates long commit subjects. This is good.
However, the same is not desirable when showmsg is enabled, since you then
end up with a truncated commit subject followed by the rest of the commit
message below.
Instead, when showmsg is enabled (and we're using all this space to display
the entire commit message, anyway), line-wrap the commit subject instead of
truncating it.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Use the existing coloring logic in Git's graph code to color the lines
between commits in the commit graph.
Whereas Git normally uses ANSI color escapes to produce colors, we here
use graph_set_column_colors() to replace those with HTML color escapes,
that embed the graph lines in <span> tags that apply the desired color
using CSS.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Teach CGit to print an ASCII art commit graph to the left of the commit
message, similar to 'git log --graph'. The graph adds extra lines (table
rows) to the log when needed to add/remove/shuffle edges in the graph.
When 'showmsg' is enabled, the graph is automatically padded to account
for the extra lines added by the commit message/notes.
This feature is controlled by a new config variable: "enable-commit-graph"
(disabled by default), and individual repos can control it by setting
"repo.enable-commit-graph".
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
When showmsg is enabled, ui-log (in addition to the table row containing
the details of the current commit) adds a second table row containing the
remainder of the commit message, and yet another table row containing the
commit notes (if any). The vertical margins between commit subject, commit
message and commit notes are controlled by CSS.
In preparation for the commit graph (which will be printed to the left of
the commit message/notes) we need to eliminate these vertical margins (as
they would produce ugly gaps in the commit graph) and instead achieve them
by adding newlines to the commit message/notes. Furthermore, we can no
longer print the "Notes:" header in the "Age" column, since the graph will
be drawn between the "Age" column and the "Commit message" column.
This patch therefore prepares the commit message and commit notes in a
single buffer (properly formatting the notes using the NOTES_SHOW_HEADER
and NOTES_INDENT flags to format_note()), and then prints the entire
buffer into a single table row.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
When using ui-log with path limits, the listing of commits enables parent
rewriting in Git's internal log machinery. This did not work well together
with cgit_diff_commit() which is used to generate the filecount and
linecount numbers for each commit in the log view. cgit_diff_commit() would
operate without any path limits, and would therefore process the full diff
between the commits shown (which, because of parent rewriting, is not the
same as processing the diff for the commit itself). Additionally, the bottom
commit in the log view would (again, because of parent rewriting) have zero
parents, causing us to process the entire diff between the empty tree and
that commit. Since path limits were not in effect, this would (in large
projects) reports thousands of files and millions of lines changed in that
bottom commit.
This patch fixes the issue by applying the same path limit to
cgit_diff_commit() as is applied to the rest of the log view. The result is
that the filecount/linecount now only reflects the diff as it pertains to
the given path limit.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
There were many places where the arguments to a printf-like function did
not match the format string. Mostly, these were a missing 'l' flag, but
there were three exceptions:
- In ui-stats.c, a size_t argument must be printed. C99 has the "%zu"
flag for this purpose, but not all compilers support this. Therefore,
we mimic what git does - use a NO_C99_FORMAT Makefile variable.
- In ui-stats.c, cgit_print_error() was called with a pointer instead of
a character.
- In ui-log.c, the "columns" argument was never used.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
The new ctx.qry.ignorews variable is passed via cgit_diff_files() and
cgit_diff_tree() to Git's diff machinery. This is equivalent to passing
--ignore-all-space to 'git diff'.
Signed-off-by: Johan Herland <johan@herland.net>
