Git upstream bans strncpy() with commit:
banned.h: mark strncpy() as banned
e488b7aba743d23b830d239dcc33d9ca0745a9ad
Signed-off-by: Christian Hesse <mail@eworm.de>
Git upstream bans strcpy() with commit:
automatically ban strcpy()
c8af66ab8ad7cd78557f0f9f5ef6a52fd46ee6dd
Signed-off-by: Christian Hesse <mail@eworm.de>
Update to git version v2.18.0. Required changes follow upstream commits:
* Convert find_unique_abbrev* to struct object_id
(aab9583f7b5ea5463eb3f653a0b4ecac7539dc94)
* sha1_file: convert read_sha1_file to struct object_id
(b4f5aca40e6f77cbabcbf4ff003c3cf30a1830c8)
* sha1_file: convert sha1_object_info* to object_id
(abef9020e3df87c441c9a3a95f592fce5fa49bb9)
* object-store: move packed_git and packed_git_mru to object store
(a80d72db2a73174b3f22142eb2014b33696fd795)
* treewide: rename tree to maybe_tree
(891435d55da80ca3654b19834481205be6bdfe33)
The changed data types required some of our own functions to be converted
to struct object_id:
ls_item
print_dir
print_dir_entry
print_object
single_tree_cb
walk_tree
write_tree_link
And finally we use new upstream functions that were added for
struct object_id:
hashcpy -> oidcpy
sha1_to_hex -> oid_to_hex
Signed-off-by: Christian Hesse <mail@eworm.de>
Reviewed-by: John Keeping <john@keeping.me.uk>
Annotated tags have some extra information... Descriptive text or signature.
Highlighting annotated tags in a different color show what tag may be worth
clicking for extra information.
Signed-off-by: Christian Hesse <mail@eworm.de>
Reviewed-by: John Keeping <john@keeping.me.uk>
Update to git version v2.16.0:
* refs: convert resolve_ref_unsafe to struct object_id
(49e61479be913f67e66bb3fdf8de9475c41b58bd)
* diff: remove DIFF_OPT_SET macro
(23dcf77f48feb49c54bad09210f093a799816334)
* log: add option to choose which refs to decorate
(65516f586b69307f977cd67cc45513a296cabc25)
* diff: convert flags to be stored in bitfields
(02f2f56bc377c287c411947d0e1482aac888f8db)
Signed-off-by: Christian Hesse <mail@eworm.de>
Numerous changes were made to git functions to use an object_id
structure rather than sending sha1 hashes as raw unsigned character
arrays. The functions that affect cgit are: parse_object,
lookup_commit_reference, lookup_tag, lookup_tree, parse_tree_indirect,
diff_root_tree_sha1, diff_tree_sha1, and format_display_notes.
Commit b2141fc (config: don't include config.h by default) made it
necessary to that config.h be explicitly included when needed.
Commit 07a3d41 (grep: remove regflags from the public grep_opt API)
removed one way of specifying the ignore-case grep option.
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
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.
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>
