Now three types of path based URLs are supported:
gitweb.cgi/project.git
gitweb.cgi/project.git/branch
gitweb.cgi/project.git/branch/filename
The first one (show project summary) was already supported for a long time
now. The other two are new: they show the shortlog of a branch or
the plain file contents of some file contained in the repository.
This is especially useful to support project web pages for small
projects: just create an html branch and then use an URL like
gitweb.cgi/project.git/html/index.html.
Signed-off-by: Martin Waitz <tali@admingilde.org> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
In "git-apply", we have a few sanity checks and heuristics that
expects that the patch fed to us is a unified diff with at least
one line of context.
* When there is no leading context line in a hunk, the hunk
must apply at the beginning of the preimage. Similarly, no
trailing context means that the hunk is anchored at the end.
* We learn a patch deletes the file from a hunk that has no
resulting line (i.e. all lines are prefixed with '-') if it
has not otherwise been known if the patch deletes the file.
Similarly, no old line means the file is being created.
And we declare an error condition when the file created by a
creation patch already exists, and/or when a deletion patch
still leaves content in the file.
These sanity checks are good safety measures, but breaks down
when people feed a diff generated with --unified=0. This was
recently noticed first by Matthew Wilcox and Gerrit Pape.
This adds a new flag, --unified-zero, to allow bypassing these
checks. If you are in control of the patch generation process,
you should not use --unified=0 patch and fix it up with this
flag; rather you should try work with a patch with context. But
if all you have to work with is a patch without context, this
flag may come handy as the last resort.
I had a hard time figuring out why this test was failing with
the packed-refs update without running it under "sh -x". This
makes output from "sh t1400-update-ref.sh -v" more descriptive.
Updating other tests would be a good janitorial task.
This allows you to maintain a few filesystem pathnames concurrently, by
simply replacing the single static "pathname" buffer with a LRU of four
buffers.
We did exactly the same thing with sha1_to_hex(), for pretty much exactly
the same reason. Sometimes you want to use two pathnames, and while it's
easy enough to xstrdup() them, why not just do the LU buffer thing.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Allow for href() to be used for links without project param
Make it possible to use href() subroutine to generate link with
query string which does not include project ('p') parameter.
href() used to add project=$project to its parameters, if it
was not set (to be more exact if $params{'project'} was false).
Now you can pass "project => undef" if you don't want for href()
to add project parameter to query string in the generated link.
Links to "project_list", "project_index" and "opml" (all related
to list of all projects/all git repositories) doesn't need project
parameter. Moreover "project_list" is default view (action) if
project ('p') parameter is not set, just like "summary" is default
view (action) if project is set; project list served as a kind
of "home" page for gitweb instalation, and links to "project_list"
view were done without specyfying it as an action.
Convert remaining links (except $home_link and anchor links)
to use href(); this required adding 'order => "o"' to @mapping
in href(). This finishes consolidation of URL generation.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Add git_project_index for generating index.aux
Add git_project_index, which generates index.aux file that can be used
as a source of projects list, instead of generating projects list from
a directory. Using file as a source of projects list allows for some
projects to be not present in gitweb main (project_list) page, and/or
correct project owner info. And is probably faster.
Additionally it can be used to get the list of all available repositories
for scripts (in easily parseable form).
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Do not parse refs by hand, use git-peek-remote instead
This is in response to Linus's work on packed refs. Additionally it
makes gitweb work with symrefs, too.
Do not parse refs by hand, using File::Find and reading individual
heads to get hash of reference, but use git-peek-remote output
instead. Assume that the hash for deref (with ^{}) always follows hash
for ref, and that we have derefs only for tag objects; this removes
call to git_get_type (and git-cat-file -t invocation) for tags, which
speeds "summary" and "tags" views generation, but might slow generation
of "heads" view a bit. For now, we do not save and use the deref hash.
Remove git_get_hash_by_ref while at it, as git_get_refs_list was the
only place it was used.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Use File::Find::find in git_get_projects_list
Earlier code to get list of projects when $projects_list is a
directory (e.g. when it is equal to $projectroot) had a hardcoded flat
(one level) list of directories. Allow for projects to be in
subdirectories also for $projects_list being a directory by using
File::Find.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
It turns out that I actually wanted to avoid the filenames (because I
didn't care - I just wanted to see the context in which something was
used) when doing a grep. But since "git grep" didn't take the "-h"
parameter, I ended up having to do "grep -5 -h *.c" instead.
So here's a trivial patch that adds "-h" (and thus has to enable -H too)
to "git grep" parsing.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Fetch over http from a repository that uses alternates to borrow
from neighbouring repositories were quite broken, apparently for
some time now.
We parse input and count bytes to allocate the new buffer, and
when we copy into that buffer we know exactly how many bytes we
want to copy from where. Using strlcpy for it was simply
stupid, and the code forgot to take it into account that strlcpy
terminated the string with NUL.
Fetch over http from a repository that uses alternates to borrow
from neighbouring repositories were quite broken, apparently for
some time now.
We parse input and count bytes to allocate the new buffer, and
when we copy into that buffer we know exactly how many bytes we
want to copy from where. Using strlcpy for it was simply
stupid, and the code forgot to take it into account that strlcpy
terminated the string with NUL.
git_connect() can return 0 if we use git protocol for example.
Users of this function don't know and don't care if a process
had been created or not, and to avoid them to check it before
calling finish_connect() this patch allows finish_connect() to
take a null pid. And in that case return 0.
[jc: updated function signature of git_connect() with a comment on
its return value. ]
Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix a memory leak in "connect.c" and die if command too long.
Use "add_to_string" instead of "sq_quote" and "snprintf", so
that there is no memory allocation and no memory leak.
Also check if the command is too long to fit into the buffer
and die if this is the case, instead of truncating it to the
buffer size.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
git_history output is now divided into pages, like git_shortlog,
git_tags and git_heads output. As whole git-rev-list output is now
read into array before writing anything, it allows for better
signaling of errors.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
As pickaxe search (selected using undocumented 'pickaxe:' operator in
search query) is resource consuming, allow to turn it on/off using
feature meachanism. Turned on by default, for historical reasons.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
autoconf: Add support for setting NO_ICONV and ICONVDIR
Add support for ./configure options --without-iconv (if neither libc
nor libiconv properly support iconv), and for --with-iconv=PATH (to
set prefix to libiconv library and headers, used only when
NEED_LIBICONV is set). While at it, make ./configure set or unset
NO_ICONV always (it is not autodetected in Makefile).
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Historically we did not allow binary patch applied without an
explicit permission from the user, and this flag was the way to
do so. This makes the flag a no-op by always allowing binary
patch application.
When we are generating packs to update remote repositories we
want to supply as much information as possible about the revisions
that already exist to rev-list in order optimise the pack as much
as possible. We need to pass two revisions for each branch we are
updating in the remote repository and one for each additional branch.
Where the remote repository has numerous branches we can run out
of command line space to pass them.
Utilise the git-rev-list --stdin mode to allow unlimited numbers
of revision constraints. This allows us to move back to the much
simpler unordered revision selection code.
[jc: added some comments in the code to describe the pipe flow
a bit.]
Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-repack: create new packs inside $GIT_DIR, not cwd
Avoid failing when cwd is !writable by writing the
packfiles in $GIT_DIR, which is more in line with other commands.
Without this, git-repack was failing when run from crontab
by non-root user accounts. For large repositories, this
also makes the mv operation a lot cheaper, and avoids leaving
temp packfiles around the fs upon failure.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net>
Teach rev-list an option to read revs from the standard input.
When --stdin option is given, in addition to the <rev>s listed
on the command line, the command can read one rev parameter per
line from the standard input. The list of revs ends at the
first empty line or EOF.
Note that you still have to give all the flags from the command
line; only rev arguments (including A..B, A...B, and A^@ notations)
can be give from the standard input.
revision.c: allow injecting revision parameters after setup_revisions().
setup_revisions() wants to get all the parameters at once and
then postprocesses the resulting revs structure after it is done
with them. This code structure is a bit cumbersome to deal with
efficiently when we want to inject revision parameters from the
side (e.g. read from standard input).
Fortunately, the nature of this postprocessing is not affected by
revision parameters; they are affected only by flags. So it is
Ok to do add_object() after the it returns.
This splits out the code that deals with the revision parameter
out of the main loop of setup_revisions(), so that we can later
call it from elsewhere after it returns.
When build a pack for a push we query the remote copy for existant
heads. These are used to prune unnecessary objects from the pack.
As we receive the remote references in get_remote_heads() we validate
the reference names via check_ref() which includes a length check;
rejecting those >45 characters in size.
This is a miss converted change, it was originally designed to reject
messages which were less than 45 characters in length (a 40 character
sha1 and refs/) to prevent comparing unitialised memory. check_ref()
now gets the raw length so check for at least 5 characters.
Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
diff-index --cc shows a 3-way diff between HEAD, index and working tree.
This implements a 3-way diff between the HEAD commit, the state in the
index, and the working directory. This is like the n-way diff for a
merge, and uses much of the same code. It is invoked with the -c flag
to git-diff-index, which it already accepted and did nothing with.
Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/pack:
more lightweight revalidation while reusing deflated stream in packing
pack-objects: fix thinko in revalidate code
pack-objects: re-validate data we copy from elsewhere.
gitweb: Divide page path into directories -- path's "breadcrumbs"
Divide page path into directories, so that each part of path links to
the "tree" view of the $hash_base (or HEAD, if $hash_base is not set)
version of the directory.
If the entity is blob, final part (basename) links to $hash_base or
HEAD revision of the "raw" blob ("blob_plain" view). If the entity is
tree, link to the "tree" view.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
If you try to fsck a repository that isn't entirely empty, but that has no
inter-object references (ie all the objects are blobs, and don't refer to
anything else), git-fsck-objects currently fails.
This probably cannot happen in practice, but can be tested with something
like
where the fsck will die by a divide-by-zero when it tries to look up the
references from the one object it found (hash_obj() will do a modulus by
refs_hash_size).
On some other archiectures (ppc, sparc) the divide-by-zero will go
unnoticed, and we'll instead SIGSEGV when we hit the "refs_hash[j]"
access.
So move the test that should protect against this from mark_reachable()
into lookup_object_refs(), which incidentally in the process also fixes
mark_reachable() itself (it used to not mark the one object that _was_
reachable, because it decided that it had no refs too early).
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
unpack-objects desperately salvages objects from a corrupt pack
The command unpack-objects dies upon the first error. This is
probably considered a feature -- if a pack is corrupt, instead
of trying to extract from it and possibly risking to contaminate
a good repository with objects whose validity is dubious, we
should seek a good copy of the pack and retry. However, we may
not have any good copy anywhere. This implements the last
resort effort to extract what are salvageable from such a
corrupt pack.
This flag might have helped Sergio when recovering from a
corrupt pack. In my test, it managed to salvage 247 objects out
of a pack that had 251 objects but without it the command
stopped after extracting 73 objects.
more lightweight revalidation while reusing deflated stream in packing
When copying from an existing pack and when copying from a loose
object with new style header, the code makes sure that the piece
we are going to copy out inflates well and inflate() consumes
the data in full while doing so.
The check to see if the xdelta really apply is quite expensive
as you described, because you would need to have the image of
the base object which can be represented as a delta against
something else.
gitweb: Change the name of diff to parent link in "commit" view to "diff
Change the name of diff to parent (current commit to one of parents)
link in "commit" view (git_commit subroutine) from "commitdiff" to
"diff". Let's leave "commitdiff" for equivalent of git-show, or
git-diff-tree with one revision, i.e. diff for a given commit to its
parent (parents).
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
When revalidating an entry from an existing pack entry->size and
entry->type are not necessarily the size of the final object
when the entry is deltified, but for base objects they must
match.
* master:
Trace into a file or an open fd and refactor tracing code.
Replace uses of strdup with xstrdup.
consolidate two copies of new style object header parsing code.
Documentation: Fix howto/revert-branch-rebase.html generation
fmt-merge-msg: fix off-by-one bug
git-rev-list(1): group options; reformat; document more options
Constness tightening for move/link_temp_to_file()
gitweb: Fix git_blame
Include config.mak.autogen in the doc Makefile
Use xmalloc instead of malloc
git(7): move gitk(1) to the list of porcelain commands
gitk: Fix some bugs in the new cherry-picking code
gitk: Improve responsiveness while reading and layout out the graph
gitk: Update preceding/following tag info when creating a tag
gitk: Add a menu item for cherry-picking commits
gitk: Fix a couple of buglets in the branch head menu items
gitk: Add a context menu for heads
gitk: Add a row context-menu item for creating a new branch
gitk: Recompute ancestor/descendent heads/tags when rereading refs
gitk: Minor cleanups
pack-objects: re-validate data we copy from elsewhere.
When reusing data from an existing pack and from a new style
loose objects, we used to just copy it staight into the
resulting pack. Instead make sure they are not corrupt, but
do so only when we are not streaming to stdout, in which case
the receiving end will do the validation either by unpacking
the stream or by constructing the .idx file.
Like xmalloc and xrealloc xstrdup dies with a useful message if
the native strdup() implementation returns NULL rather than a
valid pointer.
I just tried to use xstrdup in new code and found it to be missing.
However I expected it to be present as xmalloc and xrealloc are
already commonly used throughout the code.
[jc: removed the part that deals with last_XXX, which I am
finding more and more dubious these days.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
consolidate two copies of new style object header parsing code.
Also while we are at it, remove redundant typename[] array from
unpack_sha1_header. The only reason it is different from the
type_names[] array in object.c module is that this code cares
about the subset of object types that are valid in a loose
object, so prepare a separate array of boolean that tells us
which types are valid, and share the name translation with the
others.
The rule for howto/*.html used "$?", which expands to the list of all
newer prerequisites, including asciidoc.conf added by another rule.
"$<" should be used instead.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Fix some bugs in the new cherry-picking code
gitk: Improve responsiveness while reading and layout out the graph
gitk: Update preceding/following tag info when creating a tag
gitk: Add a menu item for cherry-picking commits
gitk: Fix a couple of buglets in the branch head menu items
gitk: Add a context menu for heads
gitk: Add a row context-menu item for creating a new branch
gitk: Recompute ancestor/descendent heads/tags when rereading refs
gitk: Minor cleanups
Now if GIT_TRACE is set to an integer value greater than 1
and lower than 10, we interpret this as an open fd value
and we trace into it. Note that this behavior is not
compatible with the previous one.
We also trace whole messages using one write(2) call to
make sure messages from processes do net get mixed up in
the middle.
It's now possible to run the tests like this:
GIT_TRACE=9 make test 9>/var/tmp/trace.log
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
The intention of the test seems to be to build a long chain of
clones that locally borrow objects from their parents and see the
system give up dereferencing long chains. There were two problems:
(1) it did not test the right repository;
(2) it did not build a chain long enough to trigger the limitation.
I do not think it is a good test to make sure the limitation the
current implementation happens to have still exists, but that is
a topic at a totally different level.
gitweb: Extend parse_difftree_raw_line to save commit info
Extend parse_difftree_raw_line to save commit info from when
git-diff-tree is given only one <tree-ish>, for example when fed
from git-rev-list using --stdin option.
git-diff-tree outputs a line with the commit ID when applicable.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
use do() instead of require() to include configuration
When run under mod_perl, require() will read and execute the configuration
file on the first invocation only. On every subsequent invocation, all
configuration variables will be reset to their default values. do() reads
and executes the configuration file unconditionally.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
On Aug 27th, Jakub Narebski sent a patch which removed the git_to_hash()
function and this call to it. The patch did not apply cleanly and had to
be applied manually. Removing the last chunk has obviously been forgotten.
This patch clean up append_signoff() by moving specific code that
looks up for "^[-A-Za-z]+: [^@]+@" pattern into a function.
It also stops the primary search when the cursor oversteps
'buf + at' limit.
This patch changes slightly append_signoff() behaviour too. If we
detect any Signed-off-by pattern during the primary search, we
needn't to do a pattern research after.
Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-fsck-objects: lacking default references should not be fatal
The comment added says it all: if we have lost all references in a git
archive, git-fsck-objects should still work, so instead of dying it should
just notify the user about that condition.
This change was triggered by me just doing a "git-init-db" and then
populating that empty git archive with a pack/index file to look at it.
Having git-fsck-objects not work just because I didn't have any references
handy was rather irritating, since part of the reason for running
git-fsck-objects in the first place was to _find_ the missing references.
However, "--unreachable" really doesn't make sense in that situation, and
we want to turn it off to protect anybody who uses the old "git prune"
shell-script (rather than the modern built-in). The old pruning script
used to remove all objects that were reported as unreachable, and without
any refs, that obviously means everything - not worth it.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Add local time and timezone to git_print_authorship
Add local time (hours and minutes) and local timezone to the output of
git_print_authorship command, used by git_commitdiff. The code was
taken from git_commit subroutine.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Add diff tree, with links to patches, to commitdiff view
Added/uncommented git_difftree_body invocation in git_commitdiff.
Added anchors (via 'id' attribute) to patches in patchset.
git_difftree_body is modified to link to patch anchor when called from
git_commitdiff, instead of link to blobdiff.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Do not remove signoff lines in git_print_simplified_log
Remove '-remove_signoff => 1' option to git_print_log call in the
git_print_simplified_log subroutine. This means that in "log" and
"commitdiff" views (git_log and git_commitdiff subroutines) signoff
lines will be shown.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Make git_print_log generic; git_print_simplified_log uses it
Collapse git_print_log and git_print_simplified_log into one
subroutine git_print_log. git_print_simplified_log now simply calls
git_print_log with proper options.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>