gitweb: fix problem causing erroneous project list
The bug is manifest when running gitweb in a persistent process (e.g.
FastCGI, PSGI), and it's easy to reproduce. If a gitweb request
includes the searchtext parameter (i.e. s), subsequent requests using
the project_list action--which is the default action--and without
a searchtext parameter will be filtered by the searchtext value of the
first request. This is because the value of the $search_regexp global
(the value of which is based on the searchtext parameter) is currently
being persisted between requests.
Instead, clear $search_regexp before dispatching each request.
Signed-off-by: Charles McGarvey <redacted> Signed-off-by: Junio C Hamano <redacted>
Junio C Hamano [Fri, 7 Jun 2013 15:09:51 +0000 (08:09 -0700)]
fetch-options.txt: prevent a wildcard refspec from getting misformatted
When explaining the "--tags" option as an equivalent to giving an
explicit "refs/tags/*:refs/tags/*" refspec, the two asterisks were
misinterpreted by AsciiDoc as a request to typeset the string
segment between them in bold.
We could fix it in two ways. We can replace them with {asterisk}s
while keeping the string as body text, or we can mark it as a
literal string with backquotes around it.
Let's do the latter, as it is teaching the user an "exactly as
typed" alternative.
Noticed-by: Ramkumar Ramachandra <redacted> Signed-off-by: Junio C Hamano <redacted>
Junio C Hamano [Fri, 7 Jun 2013 14:38:37 +0000 (07:38 -0700)]
Merge tag 'post183-for-junio' of http://github.com/msysgit/git
Collected msysgit build patches for upstream
This set of patches collects a number of build fixes that have been
used on the msysgit port for a while and merging upstream should
simplify future maintenance.
* tag 'post183-for-junio' of http://github.com/msysgit/git:
Set the default help format to html for msys builds.
Ensure the resource file is rebuilt when the version changes.
Windows resource: handle dashes in the Git version gracefully
Provide a Windows version resource for the git executables.
msysgit: Add the --large-address-aware linker directive to the makefile.
Define NO_GETTEXT for Git for Windows
Makefile: Do not use OLD_ICONV on MINGW anymore
Stefan Haller [Thu, 6 Jun 2013 08:17:47 +0000 (10:17 +0200)]
git-gui: bring wish process to front on Mac
On Mac OS X, any application that is started from the Terminal will open
behind all running applications; as a work-around, manually bring ourselves
to the front. (Stolen from gitk, commit 76bf6ff93e.)
We do this as the very first thing, so that any message boxes that might pop
up during the rest of the startup sequence are actually seen by the user.
[PT: added catch and moved down to ensure Tk has been loaded]
Signed-off-by: Stefan Haller <redacted> Signed-off-by: Pat Thoyts <redacted>
Junio C Hamano [Thu, 6 Jun 2013 19:19:00 +0000 (12:19 -0700)]
Merge branch 'rr/push-head'
"git push $there HEAD:branch" did not resolve HEAD early enough, so
it was easy to flip it around while push is still going on and push
out a branch that the user did not originally intended when the
command was started.
* rr/push-head:
push: make push.default = current use resolved HEAD
push: fail early with detached HEAD and current
push: factor out the detached HEAD error message
Junio C Hamano [Thu, 6 Jun 2013 19:18:41 +0000 (12:18 -0700)]
Merge branch 'fc/show-branch-in-rebase-am'
The bash prompt code (in contrib/) displayed the name of the branch
being rebased when "rebase -i/-m/-p" modes are in use, but not the
plain vanilla "rebase".
* fc/show-branch-in-rebase-am:
prompt: fix for simple rebase
Junio C Hamano [Thu, 6 Jun 2013 19:17:55 +0000 (12:17 -0700)]
Merge branch 'nd/clone-connectivity-shortcut'
Special case "git clone" and use lighter-weight implementation to
check the completeness of the history behind refs.
* nd/clone-connectivity-shortcut:
clone: open a shortcut for connectivity check
index-pack: remove dead code (it should never happen)
fetch-pack: prepare updated shallow file before fetching the pack
clone: let the user know when check_everything_connected is run
Jeff King [Wed, 5 Jun 2013 22:37:39 +0000 (18:37 -0400)]
clear parsed flag when we free tree buffers
Many code paths will free a tree object's buffer and set it
to NULL after finishing with it in order to keep memory
usage down during a traversal. However, out of 8 sites that
do this, only one actually unsets the "parsed" flag back.
Those sites that don't are setting a trap for later users of
the tree object; even after calling parse_tree, the buffer
will remain NULL, causing potential segfaults.
It is not known whether this is triggerable in the current
code. Most commands do not do an in-memory traversal
followed by actually using the objects again. However, it
does not hurt to be safe for future callers.
In most cases, we can abstract this out to a
"free_tree_buffer" helper. However, there are two
exceptions:
1. The fsck code relies on the parsed flag to know that we
were able to parse the object at one point. We can
switch this to using a flag in the "flags" field.
2. The index-pack code sets the buffer to NULL but does
not free it (it is freed by a caller). We should still
unset the parsed flag here, but we cannot use our
helper, as we do not want to free the buffer.
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Johannes Sixt [Thu, 6 Jun 2013 06:34:41 +0000 (08:34 +0200)]
t0005: skip signal death exit code test on Windows
The test case depends on that test-sigchain can commit suicide by a
call to raise(SIGTERM) in a way that run-command.c::wait_or_whine()
can detect as death through a signal. There are no POSIX signals on
Windows, and a sufficiently close emulation is not available in the
Microsoft C runtime (and probably not even possible).
The particular deficiency is that when a signal is raise()d whose
SIG_DFL action will cause process death (SIGTERM in this case), the
implementation of raise() in msvcrt just calls exit(3).
We could check for exit code 3 in addition to 143, but that would
miss the point of the test entirely. Hence, just skip it on Windows.
Signed-off-by: Johannes Sixt <redacted> Acked-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
send-email: make --suppress-cc=self sanitize input
--suppress-cc=self fails to filter sender address in many cases where it
needs to be sanitized in some way, for example quoted:
"A U. Thor" <redacted>
To fix, make send-email sanitize both sender and the address it is
compared against.
Signed-off-by: Michael S. Tsirkin <redacted> Signed-off-by: Junio C Hamano <redacted>
Benoit Person [Wed, 5 Jun 2013 10:58:00 +0000 (12:58 +0200)]
git-remote-mediawiki: use Git.pm functions for credentials
In 52dce6d, a new credential function was added to Git.pm, based on
git-remote-mediawiki's functions. The logical follow-up is to use
those functions in git-remote-mediawiki.
Signed-off-by: Benoit Person <redacted> Signed-off-by: Matthieu Moy <redacted> Signed-off-by: Junio C Hamano <redacted>
Junio C Hamano [Tue, 4 Jun 2013 16:50:12 +0000 (09:50 -0700)]
t/README: test_must_fail is for testing Git
When a test wants to make sure there is no <string> in an output
file, we should just say "! grep string output".
"test_must_fail" is there only to test Git command and catch unusual
deaths we know about (e.g. segv) as an error, not as an expected
failure. "test_must_fail grep string output" is unnecessary, as
we are not making sure the system binaries do not dump core or
anything like that.
Pat Thoyts [Thu, 21 Jun 2012 11:24:14 +0000 (12:24 +0100)]
Set the default help format to html for msys builds.
This resolves issue #19 by setting the compiled default to html in msys
builds following the changes introduced by commit 1cc8af0 "help: use HTML as the default help format on Windows"
Pierre le Riche [Mon, 28 May 2012 07:46:54 +0000 (09:46 +0200)]
msysgit: Add the --large-address-aware linker directive to the makefile.
This has the effect of increasing the address space from 2GB to 4GB under
64-bit Windows, reducing the likelihood of an "out of memory" error when
e.g. repacking a large repository. The test suite passes with this
patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc
calls. While this is no guarantee that there are no issues with large
memory support (it could break Git on other setups than mine, for
example), it at least increases the chance that nothing obvious goes wrong
(such as errors introduced by faulty sign extension, say, with ssize_t).
[PT: Resolves github issue #12]
Signed-off-by: Pierre le Riche <redacted> Signed-off-by: Pat Thoyts <redacted>
The dreaded "your vnsprintf is broken (returned -1)" error is back. At
least with the libintl version we have. So for the moment, just work
around the issue by _not_ using gettext.
Ah, I wish that my attempt at implementing a custom strbuf_vaddf() would
not have been brushed aside so rashly. Oh well. Time saved on maintaining
that thing, I guess (although more time went into working around coping
with existing implementations).
We are building libiconv now the same way as upstream MinGW does, so we do
not need OLD_ICONV anymore when compiling Git either in msysGit or
mingwGitDevEnv.
Thomas Rast [Thu, 30 May 2013 20:00:22 +0000 (22:00 +0200)]
sha1_file: silence sha1_loose_object_info
sha1_object_info() returns -1 (OBJ_BAD) if it cannot find the object
for some reason, which suggests that it wants the _caller_ to report
this error. However, part of its work happens in
sha1_loose_object_info, which _does_ report errors itself. This is
doubly strange because:
* packed_object_info(), which is the other half of the duo, does _not_
report this.
* In the event that an object is packed and pruned while
sha1_object_info_extended() goes looking for it, we would
erroneously show the error -- even though the code of the latter
function purports to handle this case gracefully.
* A caller might invoke sha1_object_info() to find the type of an
object even if that object is not known to exist.
Silence this error. The others remain untouched as a corrupt object
is a much more grave error than it merely being absent.
Signed-off-by: Thomas Rast <redacted> Signed-off-by: Junio C Hamano <redacted>
The documentation of -S and -G is very sketchy. Completely rewrite the
sections in Documentation/diff-options.txt and
Documentation/gitdiffcore.txt.
References: 52e9578 ([PATCH] Introducing software archaeologist's tool "pickaxe".) f506b8e (git log/diff: add -G<regexp> that greps in the patch text)
Inputs-from: Phil Hord <redacted> Co-authored-by: Junio C Hamano <redacted> Signed-off-by: Ramkumar Ramachandra <redacted> Signed-off-by: Junio C Hamano <redacted>
'git difftool' is clearly a frontend to 'git diff' and is used in
exactly the same way, but it uses a misleadingly named completion
function __git_complete_file. It happens to work only because it
calls __git_complete_revlist_file that completes both revs and
paths.
Change it to use __git_complete_revlist_file, just like 'git diff'.
Signed-off-by: Ramkumar Ramachandra <redacted> Signed-off-by: Junio C Hamano <redacted>
Chris Rorvick [Fri, 31 May 2013 01:11:41 +0000 (20:11 -0500)]
git.txt: remove stale comment regarding GIT_WORK_TREE
Official support for specifying --work-tree/GIT_WORK_TREE without
--git-dir/GIT_DIR was added with v1.7.4-rc3~2^2~2. Update description
of GIT_WORK_TREE to reflect this.
Signed-off-by: Chris Rorvick <redacted> Signed-off-by: Junio C Hamano <redacted>
Johannes Sixt [Sat, 1 Jun 2013 09:34:20 +0000 (11:34 +0200)]
test-chmtime: Fix exit code on Windows
MinGW's bash does not recognize an exit code -1 as failure. See also 47e3de0e (MinGW: truncate exit()'s argument to lowest 8 bits) and 2488df84
(builtin run_command: do not exit with -1). Exit code 1 is good enough.
Signed-off-by: Johannes Sixt <redacted> Signed-off-by: Junio C Hamano <redacted>
Felipe Contreras [Wed, 29 May 2013 03:20:48 +0000 (22:20 -0500)]
completion: avoid ls-remote in certain scenarios
It's _very_ slow in many cases, and there's really no point in fetching
*everything* from the remote just for completion. In many cases it might
be faster for the user to type the whole thing.
If the user manually specifies 'refs/*', then the full ls-remote
completion is triggered.
Signed-off-by: Felipe Contreras <redacted> Signed-off-by: Junio C Hamano <redacted>
Junio C Hamano [Sun, 2 Jun 2013 23:00:44 +0000 (16:00 -0700)]
Merge branch 'tr/line-log'
* tr/line-log:
git-log(1): remove --full-line-diff description
line-log: fix documentation formatting
log -L: improve comments in process_all_files()
log -L: store the path instead of a diff_filespec
log -L: test merge of parallel modify/rename
t4211: pass -M to 'git log -M -L...' test
log -L: fix overlapping input ranges
log -L: check range set invariants when we look it up
Speed up log -L... -M
log -L: :pattern:file syntax to find by funcname
Implement line-history search (git log -L)
Export rewrite_parents() for 'log -L'
Refactor parse_loc
Junio C Hamano [Sun, 2 Jun 2013 22:59:46 +0000 (15:59 -0700)]
Merge branch 'rs/tar-tests'
* rs/tar-tests:
t5000: test long filenames
t5000: simplify tar-tree tests
t5000: use check_tar for prefix test
t5000: factor out check_tar
t5000, t5003: create directories for extracted files lazily
t5000: integrate export-subst tests into regular tests
Junio C Hamano [Sun, 2 Jun 2013 22:58:53 +0000 (15:58 -0700)]
Merge branch 'jc/strbuf-branchname-fix'
"git merge @{-1}~22" was rewritten to "git merge frotz@{1}~22"
incorrectly when your previous branch was "frotz" (it should be
rewritten to "git merge frotz~22" instead).
* jc/strbuf-branchname-fix:
strbuf_branchname(): do not double-expand @{-1}~22
Junio C Hamano [Sun, 2 Jun 2013 22:57:26 +0000 (15:57 -0700)]
Merge branch 'jk/fetch-always-update-tracking'
"git fetch origin master" unlike "git fetch origin" or "git fetch"
did not update "refs/remotes/origin/master"; this was an early
design decision to keep the update of remote tracking branches
predictable, but in practice it turns out that people find it more
convenient to opportunisticly update them whenever we have a chance,
and we have been updating them when we run "git push" which already
breaks the original "predictability" anyway.
Now such a fetch does update refs/remotes/origin/master.
* jk/fetch-always-update-tracking:
fetch: don't try to update unfetched tracking refs
fetch: opportunistically update tracking refs
refactor "ref->merge" flag
fetch/pull doc: untangle meaning of bare <ref>
t5510: start tracking-ref tests from a known state
Junio C Hamano [Sun, 2 Jun 2013 22:57:18 +0000 (15:57 -0700)]
Merge branch 'tr/coverage'
Update the test coverage support that was left to bitrot for some
time.
* tr/coverage:
coverage: build coverage-untested-functions by default
coverage: set DEFAULT_TEST_TARGET to avoid using prove
coverage: do not delete .gcno files before building
coverage: split build target into compile and test
Junio C Hamano [Sun, 2 Jun 2013 22:56:11 +0000 (15:56 -0700)]
Merge branch 'kb/ancestry-path-threedots'
"git log --ancestry-path A...B" did not work as expected, as it did
not pay attention to the fact that the merge base between A and B
was the bottom of the range being specified.
* kb/ancestry-path-threedots:
revision.c: treat A...B merge bases as if manually specified
t6019: demonstrate --ancestry-path A...B breakage
Junio C Hamano [Sun, 2 Jun 2013 22:55:48 +0000 (15:55 -0700)]
Merge branch 'da/darwin'
Newer MacOS X encourages the programs to compile and link with
their CommonCrypto, not with OpenSSL.
* da/darwin:
imap-send: eliminate HMAC deprecation warnings on Mac OS X
cache.h: eliminate SHA-1 deprecation warnings on Mac OS X
Makefile: add support for Apple CommonCrypto facility
Makefile: fix default regex settings on Darwin
Junio C Hamano [Sun, 2 Jun 2013 22:54:06 +0000 (15:54 -0700)]
Merge branch 'vv/help-unknown-ref'
Detect "git merge foo" that might have meant "git merge origin/foo"
and give an error message that is more specific than "foo is not
something we can merge".
* vv/help-unknown-ref:
merge: use help_unknown_ref()
help: add help_unknown_ref()
Junio C Hamano [Sun, 2 Jun 2013 22:52:22 +0000 (15:52 -0700)]
Merge branch 'nd/clone-local-with-colon'
"git clone foo/bar:baz" cannot be a request to clone from a remote
over git-over-ssh specified in the scp style. Detect this case and
clone from a local repository at "foo/bar:baz".
* nd/clone-local-with-colon:
clone: allow cloning local paths with colons in them
Junio C Hamano [Sun, 2 Jun 2013 22:48:28 +0000 (15:48 -0700)]
Merge branch 'fc/fast-export-persistent-marks'
Optimization for fast-export by avoiding unnecessarily resolving
arbitrary object name and parsing object when only presence and
type information is necessary, etc.
* fc/fast-export-persistent-marks:
fast-{import,export}: use get_sha1_hex() to read from marks file
fast-export: don't parse commits while reading marks file
fast-export: do not parse non-commit objects while reading marks file
René Scharfe [Sun, 2 Jun 2013 15:46:57 +0000 (17:46 +0200)]
unpack-trees: free cache_entry array members for merges
The merge functions duplicate entries as needed and they don't free
them. Release them in unpack_nondirectories, the same function
where they were allocated, after we're done.
As suggested by Felipe, use the same loop style (zero-based for loop)
for freeing as for allocating.
Improved-by: Felipe Contreras <redacted> Signed-off-by: René Scharfe <redacted> Signed-off-by: Junio C Hamano <redacted>
René Scharfe [Sun, 2 Jun 2013 15:46:56 +0000 (17:46 +0200)]
diff-lib, read-tree, unpack-trees: mark cache_entry array paramters const
Change the type merge_fn_t to accept the array of cache_entry pointers
as const pointers to const pointers. This documents the fact that the
merge functions don't modify the cache_entry contents or replace any of
the pointers in the array.
Only a single cast is necessary in unpack_nondirectories because adding
two const modifiers at once is not allowed in C. The cast is safe in
that it doesn't mask any modfication; call_unpack_fn only needs the
array for reading.
Signed-off-by: René Scharfe <redacted> Signed-off-by: Junio C Hamano <redacted>
René Scharfe [Sun, 2 Jun 2013 15:46:54 +0000 (17:46 +0200)]
unpack-trees: create working copy of merge entry in merged_entry
Duplicate the merge entry right away and work with that instead of
modifying the entry we got and duplicating it only at the end of
the function. Then mark that pointer const to document that we
don't modify the referenced cache_entry.
This change is safe because all existing merge functions call
merged_entry just before returning (or not at all), i.e. they don't
care about changes to the referenced cache_entry after the call.
unpack_nondirectories and unpack_index_entry, which call the merge
functions through call_unpack_fn, aren't interested in such changes
neither.
The change complicates merged_entry a bit because we have to free the
copy if we error out, but allows callers to pass a const pointer.
Signed-off-by: René Scharfe <redacted> Signed-off-by: Junio C Hamano <redacted>
René Scharfe [Sun, 2 Jun 2013 15:46:53 +0000 (17:46 +0200)]
unpack-trees: factor out dup_entry
While we're add it, mark the struct cache_entry pointer of add_entry
const because we only read from it and this allows callers to pass in
const pointers.
Signed-off-by: René Scharfe <redacted> Signed-off-by: Junio C Hamano <redacted>
René Scharfe [Sun, 2 Jun 2013 15:46:52 +0000 (17:46 +0200)]
read-cache: mark cache_entry pointers const
ie_match_stat and ie_modified only derefence their struct cache_entry
pointers for reading. Add const to the parameter declaration here and
do the same for the static helper function used by them, as it's the
same there as well. This allows callers to pass in const pointers.
Signed-off-by: René Scharfe <redacted> Signed-off-by: Junio C Hamano <redacted>
René Scharfe [Sun, 2 Jun 2013 15:46:51 +0000 (17:46 +0200)]
cache: mark cache_entry pointers const
Add const for pointers that are only dereferenced for reading by the
inline functions copy_cache_entry and ce_mode_from_stat. This allows
callers to pass in const pointers.
Signed-off-by: René Scharfe <redacted> Signed-off-by: Junio C Hamano <redacted>
Michael Haggerty [Sat, 25 May 2013 09:08:24 +0000 (11:08 +0200)]
refs: document the lifetime of the args passed to each_ref_fn
The lifetime of the memory pointed to by the refname and sha1
arguments to each_ref_fn was never documented, but some callers used
to assume that it was essentially permanent. In fact the API does
*not* guarantee that these objects live beyond a single callback
invocation.
In the current code, the lifetimes are bound together with the
lifetimes of the ref_caches. Since these are usually long, the
callers usually got away with their sloppiness. But even today, if a
ref_cache is invalidated the memory can be freed. And planned changes
to reference caching, needed to eliminate race conditions, will
probably need to shorten the lifetimes of these objects.
The commits leading up to this have (hopefully) fixed all of the
callers of the for_each_ref()-like functions. This commit does the
last step: documents what each_ref_fn callbacks can assume about
object lifetimes.
Signed-off-by: Michael Haggerty <redacted> Signed-off-by: Junio C Hamano <redacted>
Michael Haggerty [Sat, 25 May 2013 09:08:22 +0000 (11:08 +0200)]
exclude_existing(): set existing_refs.strdup_strings
The each_ref_fn add_existing() adds refnames to the existing_refs
list. But the lifetimes of these refnames is not guaranteed by the
refs API, so configure the string_list to make copies as it adds them.
Signed-off-by: Michael Haggerty <redacted> Signed-off-by: Junio C Hamano <redacted>
Michael Haggerty [Sat, 25 May 2013 09:08:21 +0000 (11:08 +0200)]
string_list_add_refs_by_glob(): add a comment about memory management
Since string_list_add_one_ref() adds refname to the string list, but
the lifetime of refname is limited, it is important that the
string_list passed to string_list_add_one_ref() has strdup_strings
set. Document this fact.
All current callers do the right thing.
Signed-off-by: Michael Haggerty <redacted> Signed-off-by: Junio C Hamano <redacted>
git.99rst.org / git.git / log