It's been quite a while now that GIT is able to read version 3 packs.
Let's create them at last.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When there are single-character filenames in the test directory,
the shell tries to expand regexps meant for tr.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It would just give HEAD snapshot instead of one of the particular tree.
Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

As it is now, that array was never used because the customurl accessor was
broken and ''unless @Url_list'' never happenned.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The link forgot to have hb parameter and the resulting tree view
failed to show the navbar for that commit.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

"head" is a reference in refs/heads/, while those labels mean HEAD,
the latest revision of the default branch.
Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

I don't have much preference either way and as far as I'm concerned, it may
go the other way as well. Consistency is what is important.
Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When adding a / to the URL, git should display the corresponding
tree object, but it has to remove the / first.
Signed-off-by: NMartin Waitz <tali@admingilde.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

[jc: with a fix to config handling in t5400 test, which took
 annoyingly long to diagnose.]
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

builtin-mailinfo.c has its own hexval implementaiton but it can
share the table-lookup one recently implemented in sha1_file.c
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Require that project (repository) is given for all actions except
project_list, project_index and opml.
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJonas Fonseca <fonseca@diku.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Pointed out by Alan Chandler.
Signed-off-by: NJonas Fonseca <fonseca@diku.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NArt Haas <ahaas@airmail.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* sk/ftp:
  Add ftp:// protocol support for git-http-fetch
  http-fetch.c: consolidate code to detect missing fetch target

* jc/pack:
  pack-objects: document --revs, --unpacked and --all.
  pack-objects --unpacked=<existing pack> option.
  pack-objects: further work on internal rev-list logic.
  pack-objects: run rev-list equivalent internally.
  Separate object listing routines out of rev-list

* jc/am:
  Fix git-am safety checks

* jk/diff:
  wt-status: remove extraneous newline from 'deleted:' output
  git-status: document colorization config options
  Teach runstatus about --untracked
  git-commit.sh: convert run_status to a C builtin
  Move color option parsing out of diff.c and into color.[ch]
  diff: support custom callbacks for output

Currently it is possible to give any string ending with a number as
page.  -1 for example is quite bad (error log shows probably 100
warnings).
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Copy and pasted from git-pack-objects(1).
Signed-off-by: NJonas Fonseca <fonseca@diku.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJonas Fonseca <fonseca@diku.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

The current code works like this: if others flags than POLLIN is
raised we assume that (a) something bad happened and the child died or
(b) the child has closed the pipe because it had no more data to send.

For the latter case, we assume wrongly that one call to
process_input() will empty the pipe. Indeed it reads only 16Ko of data
by call and the the pipe capacity can be larger than that (on current
Linux kernel, it is 65536 bytes). Therefore the child can write 32ko
of data, for example, and close the pipe. After that poll will return
POLLIN _and_ POLLHUP and the parent will read only 16ko of data.

This patch forces the parent to empty the pipe as soon as POLLIN is
raised and even if POLLHUP or something else is raised too.

Moreover, some implementations of poll might return POLLRDNORM flag
even if it is non standard.
Signed-off-by: NFranck Bui-Huu <vagabon.xyz@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>