gitweb: Remove extra "/" in path names for git_get_project_list
Without this change we get a wrong $pfxlen value and the check_export_ok()
checks with with a wrong directory name. Without this patch the below
$projects_list fails with gitweb
$projects_list = "/tmp/a/b/";
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
remove .keep pack lock files when done with refs update
This makes both git-fetch and git-push (fetch-pack and receive-pack)
safe against a possible race with aparallel git-repack -a -d that could
prune the new pack while it is not yet referenced, and remove the .keep
file after refs have been updated.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
If by chance we receive a pack which content (list of objects) matches
another pack that we already have, and if that pack is marked with a
.keep file, then we should not overwrite it.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Since functions in fetch-clone.c were only used from fetch-pack.c,
its content has been merged with fetch-pack.c. This allows for better
coupling of features with much simpler implementations.
One new thing is that the (abscence of) --thin also enforce it on
index-pack now, such that index-pack will abort if a thin pack was
_not_ asked for.
The -k or --keep, when provided twice, now causes the fetched pack
to be left as a kept pack just like receive-pack currently does.
Eventually this will be used to close a race against concurrent
repacking.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Teach receive-pack how to keep pack files based on object count.
Since keeping a pushed pack or exploding it into loose objects
should be a local repository decision this teaches receive-pack
to decide if it should call unpack-objects or index-pack --stdin
--fix-thin based on the setting of receive.unpackLimit and the
number of objects contained in the received pack.
If the number of objects (hdr_entries) in the received pack is
below the value of receive.unpackLimit (which is 5000 by default)
then we unpack-objects as we have in the past.
If the hdr_entries >= receive.unpackLimit then we call index-pack and
ask it to include our pid and hostname in the .keep file to make it
easier to identify why a given pack has been kept in the repository.
Currently this leaves every received pack as a kept pack. We really
don't want that as received packs will tend to be small. Instead we
want to delete the .keep file automatically after all refs have
been updated. That is being left as room for future improvement.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow pack header preprocessing before unpack-objects/index-pack.
Some applications which invoke unpack-objects or index-pack --stdin
may want to examine the pack header to determine the number of
objects contained in the pack and use that value to determine which
executable to invoke to handle the rest of the pack stream.
However if the caller consumes the pack header from the input stream
then its no longer available for unpack-objects or index-pack --stdin,
both of which need the version and object count to process the stream.
This change introduces --pack_header=ver,cnt as a command line option
that the caller can supply to indicate it has already consumed the
pack header and what version and object count were found in that
header. As this option is only meant for low level applications
such as receive-pack we are not documenting it at this time.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* master: (90 commits)
gitweb: Better support for non-CSS aware web browsers
gitweb: Output also empty patches in "commitdiff" view
gitweb: Use git-for-each-ref to generate list of heads and/or tags
for-each-ref: "creator" and "creatordate" fields
Add --global option to git-repo-config.
pack-refs: Store the full name of the ref even when packing only tags.
git-clone documentation didn't mention --origin as equivalent of -o
Minor grammar fixes for git-diff-index.txt
link_temp_to_file: call adjust_shared_perm() only when we created the directory
Remove uneccessarily similar printf() from print_ref_list() in builtin-branch
pack-objects doesn't create random pack names
branch: work in subdirectories.
gitweb: Use 's' regexp modifier to secure against filenames with LF
gitweb: Secure against commit-ish/tree-ish with the same name as path
gitweb: esc_html() author in blame
git-svnimport: support for partial imports
link_temp_to_file: don't leave the path truncated on adjust_shared_perm failure
Move deny_non_fast_forwards handling completely into receive-pack.
revision traversal: --unpacked does not limit commit list anymore.
Continue traversal when rev-list --unpacked finds a packed commit.
...
gitweb: Better support for non-CSS aware web browsers
Add option to replace SPC (' ') with hard (non-breakable) space HTML
entity ' ' in esc_html subroutine.
Replace ' ' with ' ' for the code/diff display part in git_blob
and git_patchset_body; this is to be able to view code and diffs in
web browsers which doesn't understand "white-space: pre;" CSS
declaration.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Output also empty patches in "commitdiff" view
Remove skipping over empty patches (i.e. patches which consist solely
of extended headers) in git_patchset_body, and add links to those
header-only patches in git_difftree_body (but not generate blobdiff
links when there were no change in file contents).
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* sp/keep-pack: (29 commits)
Remove unused variable in receive-pack.
Teach git-index-pack how to keep a pack file.
Only repack active packs by skipping over kept packs.
Allow short pack names to git-pack-objects --unpacked=.
git-send-email: Read the default SMTP server from the GIT config file
git-send-email: Document support for local sendmail instead of SMTP server
Swap the porcelain and plumbing commands in the git man page
Mention that pull can work locally in the synopsis
gitweb: Add "next" link to commitdiff view
gitweb: Move git_get_last_activity subroutine earlier
Documentation: fix git-format-patch mark-up and link it from git.txt
Documentation: Update information about <format> in git-for-each-ref
Bash completion support for aliases
gitweb: Fix up bogus $stylesheet declarations
tests: merge-recursive is usable without Python
gitweb: Check git base URLs before generating URL from it
Documentation: add git in /etc/services.
Documentation: add upload-archive service to git-daemon.
git-cherry: document limit and add diagram
diff-format.txt: Correct information about pathnames quoting in patch format
...
* maint:
git-clone documentation didn't mention --origin as equivalent of -o
Minor grammar fixes for git-diff-index.txt
link_temp_to_file: call adjust_shared_perm() only when we created the directory
gitweb: Use git-for-each-ref to generate list of heads and/or tags
Add two subroutines: git_get_heads_list and git_get_refs_list, which
fill out needed parts of refs info (heads and tags respectively) info
using single call to git-for-each-ref, instead of using
git-peek-remote to get list of references and using parse_ref for each
ref to get ref info, which in turn uses at least one call of git
command.
Replace call to git_get_refs_list in git_summary by call to
git_get_references, git_get_heads_list and git_get_tags_list
(simplifying this subroutine a bit). Use git_get_heads_list in
git_heads and git_get_tags_list in git_tags. Modify git_tags_body
slightly to accept output from git_get_tags_list.
Remove no longer used, and a bit hackish, git_get_refs_list.
parse_ref is no longer used, but is left for now.
Generating "summary" and "tags" views should be much faster for
projects which have large number of tags.
CHANGES IN OUTPUT: Before, if ref in refs/tags was tag pointing to
commit we used committer epoch as epoch for ref, and used tagger epoch
as epoch only for tag pointing to object of other type. If ref in
refs/tags was commit, we used committer epoch as epoch for ref (see
parse_ref; we sorted in gitweb by 'epoch' field).
Currently we use committer epoch for refs pointing to commit objects,
and tagger epoch for refs pointing to tag object, even if tag points
to commit.
Simple ab benchmark before and after this patch for my git.git
repository (git/jnareb-git.git) with some heads and tags added
as compared to git.git repository, shows around 2.4-3.0 times speedup
for "summary" and "tags" views:
summary 3134 +/- 24.2 ms --> 1081 +/- 30.2 ms
tags 2886 +/- 18.9 ms --> 1196 +/- 15.6 ms
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds "creator" (which is parallel to "tagger" or "committer")
and "creatordate" (corresponds to "taggerdate" and
"committerdate").
As other "date" fields, "creatordate" sorts numerically
and displays human readably. This allows for example for
sorting together heavyweigth and lightweight tags.
Signed-off-by: Junio C Hamano <junkio@cox.net> Acked-by: Jakub Narebski <jnareb@gmail.com>
pack-refs: Store the full name of the ref even when packing only tags.
Using for_each_tag_ref() to enumerate tags is wrong since it removes
the refs/tags/ prefix, we need to always use for_each_ref() and filter
out non-tag references in the callback.
Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently git-push displays progress status for the local packing of
objects to send, but nothing once it starts to push it over the
connection. Having progress status in that later case is especially
nice when pushing lots of objects over a slow network link.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Use 's' regexp modifier to secure against filenames with LF
Use 's' (treat string as single line) regexp modifier in
git_get_hash_by_path (against future changes, probably unnecessary)
and in parse_ls_tree_line (when called with '-z'=>1 option) to secure
against filenames containing newline.
[jc: the hunk on git_get_hash_by_path was unneeded, and I noticed the
regexp was doing unnecessary capture, so fixed it up while I was at it.]
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Secure against commit-ish/tree-ish with the same name as path
Add "--" after <commit-ish> or <tree-ish> argument to clearly mark it
as <commit-ish> or <tree-ish> and not pathspec, securing against refs
with the same names as files or directories in [live] repository.
Some wrapping to reduce line length as well.
[jc: with "oops, ls-tree does not want --" fix-up manually applied.]
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* lj/refs: (63 commits)
Fix show-ref usagestring
t3200: git-branch testsuite update
sha1_name.c: avoid compilation warnings.
Make git-branch a builtin
ref-log: fix D/F conflict coming from deleted refs.
git-revert with conflicts to behave as git-merge with conflicts
core.logallrefupdates thinko-fix
git-pack-refs --all
core.logallrefupdates create new log file only for branch heads.
Remove bashism from t3210-pack-refs.sh
ref-log: allow ref@{count} syntax.
pack-refs: call fflush before fsync.
pack-refs: use lockfile as everybody else does.
git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
lock_ref_sha1_basic does not remove empty directories on BSD
Do not create tag leading directories since git update-ref does it.
Check that a tag exists using show-ref instead of looking for the ref file.
Use git-update-ref to delete a tag instead of rm()ing the ref file.
Fix refs.c;:repack_without_ref() clean-up path
Clean up "git-branch.sh" and add remove recursive dir test cases.
...
, and we would like to import only tree under this specific
'path/to/our/project' and not whole tree under $trunk, $branches, etc..
Now we will be be able to do it by using '-P path/to/our/project' option
with git-svnimport.
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a shorthand for "<rev> --not <rev>^@", i.e. "include
this commit but exclude any of its parents".
When a new file $F is introduced by revision $R, this notation
can be used to find a copy-and-paste from existing file in the
parents of that revision without annotating the ancestry of the
lines that were copied from:
git-pickaxe: cache one already found path per commit.
Depending on how bushy the commit DAG is, this saves calls to
the internal diff-tree for fork-point commits. For example,
annotating Makefile in the kernel repository saves about a third
of such diff-tree calls.
git push: add verbose flag and allow overriding of default target repository
This adds a command line flag "-v" to enable a more verbose mode, and
"--repo=" to override the default target repository for "git push" (which
otherwise always defaults to "origin").
This, together with the patch to allow dashes in config variable names,
allows me to do
[alias]
push-all = push -v --repo=all
in my user-global config file, and then I can (for any project I maintain)
add to the project-local config file
* maint:
revision traversal: --unpacked does not limit commit list anymore.
Continue traversal when rev-list --unpacked finds a packed commit.
Use memmove instead of memcpy for overlapping areas
quote.c: ensure the same quoting across platforms.
Surround "#define DEBUG 0" with "#ifndef DEBUG..#endif"
Move deny_non_fast_forwards handling completely into receive-pack.
The 'receive.denynonfastforwards' option has nothing to do with
the repository format version. Since receive-pack already uses
git_config to initialize itself before executing any updates we
can use the normal configuration strategy and isolate the receive
specific variables away from the core variables.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Continue traversal when rev-list --unpacked finds a packed commit.
When getting the list of all unpacked objects by walking the commit history,
we would stop traversal whenever we hit a packed commit. However the fact
that we found a packed commit does not guarantee that all previous commits
are also packed. As a result the commit walkers did not show all reachable
unpacked objects.
Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-pickaxe: split find_origin() into find_rename() and find_origin().
When a merge adds a new file from the second parent, the
earlier code tried to find renames in the first parent before
noticing that the vertion from the second parent was added
without modification.
quote.c: ensure the same quoting across platforms.
We read a byte from "char *" and compared it with ' ' to decide
if it needs quoting to protect textual output. With a platform
where char is unsigned char that would give different result.
The origin structure is allocated for each commit and path while
the code traverse down it is copied into different blame entries.
To avoid leaks, try refcounting them.
This still seems to leak, which I haven't tracked down fully yet.
To prevent a race condition between `index-pack --stdin` and
`repack -a -d` where the repack deletes the newly created pack
file before any refs are updated to reference objects contained
within it we mark the pack file as one that should be kept. This
removes it from the list of packs that `repack -a -d` will consider
for removal.
Callers such as `receive-pack` which want to invoke `index-pack`
should use this new --keep option to prevent the newly created pack
and index file pair from being deleted before they have finished any
related ref updates. Only after all ref updates have been finished
should the associated .keep file be removed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Only repack active packs by skipping over kept packs.
During `git repack -a -d` only repack objects which are loose or
which reside in an active (a non-kept) pack. This allows the user
to keep large packs as-is without continuous repacking and can be
very helpful on large repositories. It should also help us resolve
a race condition between `git repack -a -d` and the new pack store
functionality in `git-receive-pack`.
Kept packs are those which have a corresponding .keep file in
$GIT_OBJECT_DIRECTORY/pack. That is pack-X.pack will be kept
(not repacked and not deleted) if pack-X.keep exists in the same
directory when `git repack -a -d` starts.
Currently this feature is not documented and there is no user
interface to keep an existing pack.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow short pack names to git-pack-objects --unpacked=.
This allows us to pass just the file name of a pack rather than
the complete path when we want pack-objects to consider its
contents as though they were loose objects. This can be helpful
if $GIT_OBJECT_DIRECTORY contains shell metacharacters which make
it cumbersome to pass complete paths safely in a shell script.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
send-pack --keep: do not explode into loose objects on the receiving end.
This adds "keep-pack" extension to send-pack vs receive pack protocol,
and makes the receiver invoke "index-pack --stdin --fix-thin".
With this, you can ask send-pack not to explode the result into
loose objects on the receiving end.
I've patched has_sha1_file() to re-check for added packs just
like is done in read_sha1_file() for now, but I think the static
"re-prepare" interface for packs was a mistake. Creation of a
new pack inside a process that needs to read objects in them
back ought to be a rare event, so we are better off making the
callers (such as receive-pack that calls "index-pack --stdin
--fix-thin") explicitly call re-prepare. That way we do not
have to penalize ordinary users of read_sha1_file() and
has_sha1_file().
Add a kind of "next" view in the bottom part of navigation bar for
"commitdiff" view.
For commitdiff between two commits:
(from: _commit_)
For commitdiff for one single parent commit:
(parent: _commit_)
For commitdiff for one merge commit
(merge: _commit_ _commit_ ...)
For commitdiff for root (parentless) commit
(initial)
where _link_ denotes hyperlink. SHA1 is shortened to 7 characters on
display, everything is perhaps unnecessary esc_html on display.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
merge-recursive: adjust to loosened "working file clobbered" check
The three-way merge by git-read-tree does not complain about
presense of the file in the working tree that is involved in a
merge when the merge result needs to be determined by the
caller. Adjust merge-recursive so that it makes sure that an
untracked file is not touched when the merge decides the path
should not be included in the final result.
merge: loosen overcautious "working file will be lost" check.
The three-way merge complained unconditionally when a path that
does not exist in the index is involved in a merge when it
existed in the working tree. If we are merging an old version
that had that path tracked, but the path is not tracked anymore,
and if we are merging that old version in, the result will be
that the path is not tracked. In that case we should not
complain.
This seems to be a pre-++ residual declaration and it wasn't good for
anything at all besides flooding the webserver errorlog with "omg, our in
the same scope!!" warnings.
[jc: the patch was bogus by defining the variable which defeated a
later test that checked it with "defined", which I fixed up.]
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that index-pack can be streamed with a pack, it is probably a good
idea to use it directly instead of creating a temporary file and running
index-pack afterwards. This way index-pack can abort early whenever a
corruption is encountered even if the pack has not been fully
downloaded, it can display a progress percentage as it knows how much to
expects, and it is a bit faster since the pack indexing is partially
done as data is received. Using fetch -k doesn't need to disable thin
pack generation on the remote end either.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
gitweb: Check git base URLs before generating URL from it
Documentation: add git in /etc/services.
Documentation: add upload-archive service to git-daemon.
git-cherry: document limit and add diagram
diff-format.txt: Correct information about pathnames quoting in patch format
gitweb: Check git base URLs before generating URL from it
Check if each of git base URLs in @git_base_url_list is true before
appending "/$project" to it to generate project URL.
This fixes the error that for default configuration for gitweb in
Makefile, with GITWEB_BASE_URL empty (and "++GITWEB_BASE_URL++" being
"" in gitweb.cgi), we had URL of "/$project" in the summary view.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch adds the diagram from the long usage string of git-cherry to
its documentation, and documents the third option. I changed some of
the + to - in order to save the reader from wondering where they might
fit into the picture.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch on top of 'next' makes built-in git-cherry handle root
commits.
It moves the static function log-tree.c::diff_root_tree() to
tree-diff.c and makes it more similar to diff_tree_sha1() by
shuffling around arguments and factoring out the call to
log_tree_diff_flush(). Consequently the name is changed to
diff_root_tree_sha1(). It is a version of diff_tree_sha1() that
compares the empty tree (= root tree) against a single 'real' tree.
This function is then used in get_patch_id() to compute patch IDs
for initial commits instead of SEGFAULTing, as the current code
does if confronted with parentless commits.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
mimic unpack-objects when --stdin is used with index-pack
It appears that git-unpack-objects writes the last part of the input
buffer to stdout after the pack has been parsed. This looks a bit
suspicious since the last fill() might have filled the buffer up to
the 4096 byte limit and more data might still be pending on stdin,
but since this is about being a drop-in replacement for unpack-objects
let's simply duplicate the same behavior for now.
[jc: with fix-up appeared in Nico's sleep]
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Use --no-commit-id in git_commit and git_commitdiff
Use --no-commit-id option to git-diff-tree command in git_commit and
git_commitdiff to filter out commit ID output that git-diff-tree adds
when called with only one <tree-ish> (not only for --stdin). Remove
filtering commit IDs from git-diff-tree output.
This option is in git since at least v1.0.0, so make use of it.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
"new file" and "deleted file" were already reported in the
original code, but the logic was not as transparent as it could
have. This uses a few variables and more comments to clarify
the flow. The rule is: (1) if a path exists in the merge result
when no parent had it, we report "new" (otherwise it came from
the parents, as opposed to have added by the evil merge). (2) if
the path does not exist in the merge result, it is "deleted".
Since we can say "new" and "deleted", there is no reason not to
follow the /dev/null convention. This fixes it.
Appending function name after @@@ ... @@@ is trivial, so
implement it.
Nobody should create ambiguous refs (i.e. have tag "foobar" and branch
"foobar" at the same time) that need to be disambiguated with these
rules to keep sanity, but the rules are there so document them.