Nicolas Pitre [Sat, 23 Sep 2006 01:25:04 +0000 (21:25 -0400)]
make pack data reuse compatible with both delta types
This is the missing part to git-pack-objects allowing it to reuse delta
data to/from any of the two delta types. It can reuse delta from any
type, and it outputs base offsets when --allow-delta-base-offset is
provided and the base is also included in the pack. Otherwise it
outputs base sha1 references just like it always did.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Nicolas Pitre [Thu, 21 Sep 2006 04:09:44 +0000 (00:09 -0400)]
make git-pack-objects able to create deltas with offset to base
This is enabled with --delta-base-offset only, and doesn't work with
pack data reuse yet.
The idea is to allow for the fetch protocol to use an extension flag
to notify the remote end that --delta-base-offset can be used with
git-pack-objects. Eventually git-repack will always provide this flag.
With this, all delta base objects are now pushed before deltas that depend
on them. This is a requirements for OBJ_OFS_DELTA. This is not a
requirement for OBJ_REF_DELTA but always doing so makes the code simpler.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Nicolas Pitre [Thu, 21 Sep 2006 04:06:49 +0000 (00:06 -0400)]
introduce delta objects with offset to base
This adds a new object, namely OBJ_OFS_DELTA, renames OBJ_DELTA to
OBJ_REF_DELTA to better make the distinction between those two delta
objects, and adds support for the handling of those new delta objects
in sha1_file.c only.
The OBJ_OFS_DELTA contains a relative offset from the delta object's
position in a pack instead of the 20-byte SHA1 reference to identify
the base object. Since the base is likely to be not so far away, the
relative offset is more likely to have a smaller encoding on average
than an absolute offset. And for those delta objects the base must
always be stored first because there is no way to know the distance of
later objects when streaming a pack. Hence this relative offset is
always meant to be negative.
The offset encoding is slightly denser than the one used for object
size -- credits to <linux@horizon.com> (whoever this is) for bringing
it to my attention.
This allows for pack size reduction between 3.2% (Linux-2.6) to over 5%
(linux-historic). Runtime pack access should be faster too since delta
replay does skip a search in the pack index for each delta in a chain.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: extend blame to show links to diff and previous
git_blame2() now has two more columns, "Prev" and "Diff",
before the "Commit" column, as follows:
Prev Diff Commit Line Data
SHA Diff SHA N ...
...
The "Prev" column shows the SHA of the parent commit,
between which this line changed. Clicking on it shows the
blame of the file as of the parent commit, for that line.
So clicking repeatedly on "Prev" would show you the blame
of that file, from the point of view of the changes
of that particular line whose "Prev" you're clicking on.
The "Diff" column shows "Diff" which is a link to blobdiff
between "Prev" and "Commit" commits _for that line_.
So clicking on "Diff" would show you the blobdiff (HTML)
between the parent commit and this commit which changed
that particular line.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a simple one liner to decode long title string in perl's
internal form to utf-8 for link tooltips.
This is not crucial if the commit message is all in ASCII, however, if
you decide to use other encoding, such as UTF-8, tooltips ain't
readable any more.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Ignore executable bit when adding files if filemode=0.
If the user has configured core.filemode=0 then we shouldn't set
the execute bit in the index when adding a new file as the user
has indicated that the local filesystem can't be trusted.
This means that when adding files that should be marked executable
in a repository with core.filemode=0 the user must perform a
'git update-index --chmod=+x' on the file before committing the
addition.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
The "list" table element of tree view is identical
to the "blob" link part of the link table element.
I.e. clicking on "blob" is identical to clicking on
the entry itself.
Thus, eliminate "blob" from being shown -- the user
can get identical result by simply clicking on the
entry itself.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano [Mon, 25 Sep 2006 02:49:47 +0000 (19:49 -0700)]
Deprecate merge-recursive.py
This renames merge-recursive written in Python to merge-recursive-old,
and makes merge-recur as a synonym to merge-recursive. We do not remove
merge-recur yet, but we will remove merge-recur and merge-recursive-old
in a few releases down the road.
Petr Baudis [Sun, 24 Sep 2006 21:57:40 +0000 (14:57 -0700)]
gitweb: fix over-eager application of esc_html().
Contents of %diffinfo hash should be quoted upon output but kept
unquoted internally. Later users of this hash expect filenames
to be filenames, not HTML gibberish.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
When trying to import an SVN revision which has no author the Git
user may desire to relabel '(no author)' to another name and email
address with their svn.authorsfile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow 'svn fetch' on '(no date)' revisions in Subversion.
Added --ignore-nodate to allow 'git svn fetch' to import revisions
from Subversion which have '(no date)' listed as the date of the
revision. By default 'git svn fetch' will crash with an error
when encountering such a revision. The user may restart the fetch
operation by adding --ignore-nodate if they want to continue tracking
that repository.
I'm not entirely sure why a centralized version control system such
as Subversion permits revisions to be created with absolutely no
date/time associated with it but it apparently is possible as one
of the Subversion repositories that I'm tracking with 'git svn'
created such a revision on '(no date)' and by '(no user)'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano [Sun, 24 Sep 2006 21:42:01 +0000 (14:42 -0700)]
Remove upload-tar and make git-tar-tree a thin wrapper to git-archive
The command now issues a big deprecation warning message and runs
git-archive command with appropriate arguments.
git-tar-tree $tree_ish $base always forces $base to be the leading
directory name, so the --prefix parameter passed internally to
git-archive is a slash appended to it, i.e. "--prefix=$base/".
generate_tar() eventually calls write_tar_archive() which does all the
"real" work and which also calls git_config(git_tar_config). We only
need to do this once.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano [Mon, 25 Sep 2006 02:53:52 +0000 (19:53 -0700)]
Merge branch 'jc/filter-commit'
* jc/filter-commit:
git log: Unify header_filter and message_filter into one.
Update grep internal for grepping only in head/body
git-log --author and --committer are not left-anchored by default
rev-list: fix segfault with --{author,committer,grep}
revision traversal: --author, --committer, and --grep.
revision traversal: prepare for commit log match.
builtin-grep: make pieces of it available as library.
Junio C Hamano [Mon, 25 Sep 2006 02:20:26 +0000 (19:20 -0700)]
Merge branch 'sb/branch-attributes'
* sb/branch-attributes:
Add test for the default merges in fetch.
fetch: get the remote branches to merge from the branch properties
Add t5510 to test per branch configuration affecting git-fetch.
Fetch: default remote repository from branch properties
Junio C Hamano [Sat, 23 Sep 2006 07:37:19 +0000 (00:37 -0700)]
git-apply: second war on whitespace.
This makes --whitespace={warn,error,strip} option to also notice
the leading whitespace errors in addition to the trailing
whitespace errors. Spaces that are followed by a tab in indent
are detected as errors, and --whitespace=strip option fixes them.
We ought to handle anything in filenames and I actually see no reason why
we don't, modulo very little missing escaping that this patch hopefully
also fixes.
I have also made esc_param() escape [?=&;]. Not escaping [&;] was downright
buggy and [?=] just feels better escaped. ;-) YMMV.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
Petr Baudis [Sat, 23 Sep 2006 22:25:19 +0000 (00:25 +0200)]
Deprecate git-resolve.sh
Seriously, is anyone still using this thing? It's collecting dust and
blocking the name for something potentially useful like a tool for
user-friendly marking of resolved conflicts or resolving index conflicts.
We've loved you when Git was young, now thank you and please go away. ;-)
This makes git-resolve.sh print a big deprecation warning and sleep a bit
for extra annoyance. It should be removed completely after the next release.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
Petr Baudis [Sat, 23 Sep 2006 18:20:47 +0000 (20:20 +0200)]
Git.pm: Kill Git.xs for now
This patch removes Git.xs from the repository for the time being. This
should hopefully enable Git.pm to finally make its way to master.
Git.xs is not going away forever. When the Git libification makes some
progress, it will hopefully return (but most likely as an optional
component, due to the portability woes) since the performance boosts are
really important for applications like Gitweb or Cogito. It needs to go
away now since it is not really reliable in case you use it for several
repositories in the scope of a single process, and that is not possible
to fix without some either very ugly or very intrusive core changes.
Rest in peace. (While you can.)
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-zip-tree can be safely removed because it was never part of a formal
release. This patch makes 'git-archive --format=zip' the one and only git
ZIP file creation command.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
Nicolas Pitre [Thu, 21 Sep 2006 04:05:37 +0000 (00:05 -0400)]
many cleanups to sha1_file.c
Those cleanups are mainly to set the table for the support of deltas
with base objects referenced by offsets instead of sha1. This means
that many pack lookup functions are converted to take a pack/offset
tuple instead of a sha1.
This eliminates many struct pack_entry usages since this structure
carried redundent information in many cases, and it increased stack
footprint needlessly for a couple recursively called functions that used
to declare a local copy of it for every recursion loop.
In the process, packed_object_info_detail() has been reorganized as well
so to look much saner and more amenable to deltas with offset support.
Finally the appropriate adjustments have been made to functions that
depend on the above changes. But there is no functionality changes yet
simply some code refactoring at this point.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svnimport: Parse log message for Signed-off-by: lines
This add '-S' option. When specified svn-import will try to parse
commit message for 'Signed-off-by: ...' line, and if found will use
the name and email address extracted at first occurrence as this commit
author name and author email address. Committer name and email are
extracted in usual way.
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Petr Baudis [Fri, 22 Sep 2006 23:00:12 +0000 (01:00 +0200)]
Make path in tree view look nicer
Based on talk on the IRC with Junio some evenings ago, I've updated the
path showing in tree view to look better and sent updated patches
privately, but it seems the old version ended up being used, so here's
the new one again.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
Petr Baudis [Fri, 22 Sep 2006 01:19:41 +0000 (03:19 +0200)]
gitweb: More per-view navigation bar links
Navigation bars in various views were empty or missed important items that
should have been there, e.g. getting a snapshot in tree view or log of
ancestry in commit view...
This feeble patch attempts to consolidate that.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
Petr Baudis [Thu, 21 Sep 2006 23:58:40 +0000 (01:58 +0200)]
gitweb: Link (HEAD) tree for each project from projects list
Current projects list is oriented on easily getting "what's new"
information. But when already using gitweb as an interface to something,
I personally find myself to _much_ more frequently wanting to rather
see "what's in" (or "what's new in") and it's quite annoying to have to
go through the summary page (which is also rather expensive to generate)
just to get there.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
This was lost in the packed-ref updates. The original test was a bit
dubious, so I cleaned that up, too. It fixes the case when the current HEAD
is refs/heads/bla/master: the original test was true for both bla/master
_and_ master.
However, it shares a hard-to-fix bug with the original test: if the current
HEAD is refs/heads/master, and there is a branch refs/heads/heads/master,
then both are marked active.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
Andy Whitcroft [Thu, 21 Sep 2006 09:19:17 +0000 (10:19 +0100)]
git-for-each-ref: improve the documentation on scripting modes
When reading the synopsis for git-for-each-ref it is easy to miss
the obvious power of --shell and family. Call this feature out in
the primary paragragh. Also add more description to the examples
to indicate which features we are demonstrating. Finally add a
very simple eval based example in addition to the very complex one
to give a gentler introduction.
Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Petr Baudis [Thu, 21 Sep 2006 00:05:50 +0000 (02:05 +0200)]
Fix showing of path in tree view
This patch fixes two things - links to all path elements except the last
one were broken since gitweb does not like the trailing slash in them, and
the root tree was not reachable from the subdirectory view.
To compensate for the one more slash in the front, the trailing slash is
not there anymore. ;-) I don't care if it stays there though.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano [Thu, 21 Sep 2006 07:40:28 +0000 (00:40 -0700)]
Merge branch 'lt/refs' into jc/lt-ref2-with-lt-refs
* lt/refs: (58 commits)
git-pack-refs --prune
pack-refs: do not pack symbolic refs.
Tell between packed, unpacked and symbolic refs.
Add callback data to for_each_ref() family.
symbolit-ref: fix resolve_ref conversion.
Fix broken sha1 locking
fsck-objects: adjust to resolve_ref() clean-up.
gitignore: git-pack-refs is a generated file.
wt-status: use simplified resolve_ref to find current branch
Fix t1400-update-ref test minimally
Enable the packed refs file format
Make ref resolution saner
Add support for negative refs
Start handling references internally as a sorted in-memory list
gitweb fix validating pg (page) parameter
git-repack(1): document --window and --depth
git-apply(1): document --unidiff-zero
gitweb: fix warnings in PATH_INFO code and add export_ok/strict_export
upload-archive: monitor child communication even more carefully.
gitweb: export options
...
Junio C Hamano [Thu, 21 Sep 2006 07:29:37 +0000 (00:29 -0700)]
Merge branch 'lt/refs' into jc/for-each-ref-with-lt-refs
* lt/refs: (58 commits)
git-pack-refs --prune
pack-refs: do not pack symbolic refs.
Tell between packed, unpacked and symbolic refs.
Add callback data to for_each_ref() family.
symbolit-ref: fix resolve_ref conversion.
Fix broken sha1 locking
fsck-objects: adjust to resolve_ref() clean-up.
gitignore: git-pack-refs is a generated file.
wt-status: use simplified resolve_ref to find current branch
Fix t1400-update-ref test minimally
Enable the packed refs file format
Make ref resolution saner
Add support for negative refs
Start handling references internally as a sorted in-memory list
gitweb fix validating pg (page) parameter
git-repack(1): document --window and --depth
git-apply(1): document --unidiff-zero
gitweb: fix warnings in PATH_INFO code and add export_ok/strict_export
upload-archive: monitor child communication even more carefully.
gitweb: export options
...
Junio C Hamano [Thu, 21 Sep 2006 07:06:06 +0000 (00:06 -0700)]
git-pack-refs --prune
"git pack-refs --prune", after successfully packing the existing
refs, removes the loose ref files. It tries to protect against
race by doing the usual lock_ref_sha1() which makes sure the
contents of the ref has not changed since we last looked at.
Also we do not bother trying to prune what was already packed, and
we do not try pruning symbolic refs.
Junio C Hamano [Thu, 21 Sep 2006 05:02:01 +0000 (22:02 -0700)]
Tell between packed, unpacked and symbolic refs.
This adds a "int *flag" parameter to resolve_ref() and makes
for_each_ref() family to call callback function with an extra
"int flag" parameter. They are used to give two bits of
information (REF_ISSYMREF and REF_ISPACKED) about the ref.
Junio C Hamano [Thu, 21 Sep 2006 04:47:42 +0000 (21:47 -0700)]
Add callback data to for_each_ref() family.
This is a long overdue fix to the API for for_each_ref() family
of functions. It allows the callers to specify a callback data
pointer, so that the caller does not have to use static
variables to communicate with the callback funciton.
The updated for_each_ref() family takes a function of type
int (*fn)(const char *, const unsigned char *, void *)
and a void pointer as parameters, and calls the function with
the name of the ref and its SHA-1 with the caller-supplied void
pointer as parameters.
The commit updates two callers, builtin-name-rev.c and
builtin-pack-refs.c as an example.
Junio C Hamano [Thu, 21 Sep 2006 04:10:17 +0000 (21:10 -0700)]
symbolit-ref: fix resolve_ref conversion.
An earlier conversion accidentally hardcoded "HEAD" to be passed to
resolve_ref(), thereby causing git-symbolic-ref command to always
report where the HEAD points at, ignoring the command line parameter.
If receive.denyNonFastforwards is set to true, git-receive-pack will deny
non fast-forwards, i.e. forced updates. Most notably, a push to a repository
which has that flag set will fail.
As a first user, 'git-init-db --shared' sets this flag, since in a shared
setup, you are most unlikely to want forced pushes to succeed.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano [Wed, 20 Sep 2006 19:39:46 +0000 (12:39 -0700)]
Update grep internal for grepping only in head/body
This further updates the built-in grep engine so that we can say
something like "this pattern should match only in head". This
can be used to simplify grepping in the log messages.
Junio C Hamano [Mon, 18 Sep 2006 00:23:20 +0000 (17:23 -0700)]
revision traversal: --author, --committer, and --grep.
This adds three options to setup_revisions(), which lets you
filter resulting commits by the author name, the committer name
and the log message with regexp.
Junio C Hamano [Sun, 17 Sep 2006 23:02:52 +0000 (16:02 -0700)]
builtin-grep: make pieces of it available as library.
This makes three functions and associated option structures from
builtin-grep available from other parts of the system.
* options to drive built-in grep engine is stored in struct
grep_opt;
* pattern strings and extended grep expressions are added to
struct grep_opt with append_grep_pattern();
* when finished calling append_grep_pattern(), call
compile_grep_patterns() to prepare for execution;
* call grep_buffer() to find matches in the in-core buffer.
This also adds an internal option "status_only" to grep_opt,
which suppresses any output from grep_buffer(). Callers of the
function as library can use it to check if there is a match
without producing any output.
Jakub Narebski [Tue, 19 Sep 2006 18:47:27 +0000 (20:47 +0200)]
gitweb: Fix thinko in git_tags and git_heads
git_get_refs_list always return reference to list (and reference to
hash which we ignore), so $taglist (in git_tags) and $headlist (in
git_heads) are always defined, but @$taglist / @$headlist might be
empty. Replaced incorrect "if (defined @$taglist)" with
"if (@$taglist)" in git_tags and respectively in git_heads.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Jakub Narebski [Tue, 19 Sep 2006 12:33:22 +0000 (14:33 +0200)]
gitweb: Make git_get_refs_list do work of git_get_references
Make git_get_refs_list do also work of git_get_references, to avoid
calling git-peek-remote twice. Change meaning of git_get_refs_list
meaning: it is now type, and not a full path, e.g. we now use
git_get_refs_list("heads") instead of former
git_get_refs_list("refs/heads").
Modify git_summary to use only one call to git_get_refs_list instead
of one call to git_get_references and two to git_get_refs_list.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Jakub Narebski [Tue, 19 Sep 2006 12:31:49 +0000 (14:31 +0200)]
gitweb: Always use git-peek-remote in git_get_references
Instead of trying to read info/refs file, which might not be present
(we did fallback to git-ls-remote), always use git-peek-remote in
git_get_references.
It is preparation for git_get_refs_info to also return references
info. We should not use info/refs for git_get_refs_info as the
repository is not served for http-fetch clients.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Andy Whitcroft [Wed, 20 Sep 2006 16:37:04 +0000 (17:37 +0100)]
cvsimport: move over to using git-for-each-ref to read refs.
cvsimport opens all of the files in $GIT_DIR/refs/heads and reads
out the sha1's in order to work out what time the last commit on
that branch was made (in CVS) thus allowing incremental updates.
However, this takes no account of hierachical refs naming producing
the following error for each directory in $GIT_DIR/refs:
Use of uninitialized value in chomp at /usr/bin/git-cvsimport line 503.
Use of uninitialized value in concatenation (.) or string at
/usr/bin/git-cvsimport line 505.
usage: git-cat-file [-t|-s|-e|-p|<type>] <sha1>
Take advantage of the new packed refs work to use the new
for-each-ref iterator to get this information.
Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Jakub Narebski [Tue, 19 Sep 2006 22:49:51 +0000 (00:49 +0200)]
gitweb: Even more support for PATH_INFO based URLs
Now the following types of path based URLs are supported:
* project overview (summary) page of project
* project/branch shortlog of branch
* project/branch:file file in branch, blob_plain view
* project/branch:dir/ directory listing of dir in branch, tree view
The following shortcuts works (see explanation below):
* project/branch: directory listing of branch, main tree view
* project/:file file in HEAD (raw)
* project/:dir/ directory listing of dir in HEAD
* project/: directory listing of project's HEAD
We use ':' as separator between branch (ref) name and file name
(pathname) because valid branch (ref) name cannot have ':' inside.
This limit applies to branch name only. This allow for hierarchical
branches e.g. topic branch 'topic/subtopic', separate remotes
tracking branches e.g. 'refs/remotes/origin/HEAD', and discriminate
between head (branch) and tag with the same name.
Empty branch should be interpreted as HEAD.
If pathname (the part after ':') ends with '/', we assume that pathname
is name of directory, and we want to show contents of said directory
using "tree" view. If pathname is empty, it is equivalent to '/' (top
directory).
If pathname (the part after ':') does not end with '/', we assume that
pathname is name of file, and we show contents of said file using
"blob_plain" view.
Pathname is stripped of leading '/', so we can use ':/' to separate
branch from pathname. The rationale behind support for PATH_INFO based
URLs was to support project web pages for small projects: just create
an html branch and then use an URL like
http://nowhere.com/gitweb.cgi/project.git/html:/index.html
The ':/' syntax allow for working links between .html files served
in such way, e.g. <a href="main.html"> link inside "index.html"
would get
http://nowhere.com/gitweb.cgi/project.git/html:/main.html.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Petr Baudis [Tue, 19 Sep 2006 20:58:23 +0000 (22:58 +0200)]
Fix broken sha1 locking
Current git#next is totally broken wrt. cloning over HTTP, generating refs
at random directories. Of course it's caused by the static get_pathname()
buffer. lock_ref_sha1() stores return value of mkpath()'s get_pathname()
call, then calls lock_ref_sha1_basic() which calls git_path(ref) which
calls get_pathname() at that point returning pointer to the same buffer.
So now you are sprintf()ing a format string into itself, wow! The resulting
pathnames are really cute. (If you've been paying attention, yes, the
mere fact that a format string _could_ write over itself is very wrong
and probably exploitable here. See the other mail I've just sent.)
I've never liked how we use return values of those functions so liberally,
the "allow some random number of get_pathname() return values to work
concurrently" is absolutely horrible pit and we've already fallen in this
before IIRC. I consider it an awful coding practice, you add a call
somewhere and at some other point some distant caller of that breaks since
it reuses the same return values. Not to mention this takes quite some time
to debug.
My gut feeling tells me that there might be more of this. I don't have
time to review the rest of the users of the refs.c functions though.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
Jakub Narebski [Tue, 19 Sep 2006 11:57:03 +0000 (13:57 +0200)]
gitweb: Fix mimetype_guess_file for files with multiple extensions
Fix getting correct mimetype for "blob_plain" view for files which have
multiple extensions, e.g. foo.1.html; now only the last extension
is used to find mimetype.
Noticed by Martin Waitz.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Art Haas [Tue, 19 Sep 2006 12:20:19 +0000 (07:20 -0500)]
Patch for http-fetch.c and older curl releases
Older curl releases do not define CURLE_HTTP_RETURNED_ERROR, they
use CURLE_HTTP_NOT_FOUND instead. Newer curl releases keep the
CURLE_HTTP_NOT_FOUND definition but using a -DCURL_NO_OLDIES
preprocessor flag the old name will not be present in the 'curl.h'
header.
This patch makes our code written for newer releases of the curl
library but allow compiling against an older curl (older than
0x070a03) by defining the missing CURLE_HTTP_RETURNED_ERROR as a
synonym for CURLE_HTTP_NOT_FOUND.
Signed-off-by: Art Haas <ahaas@airmail.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
projects / rit / log