It can sometimes be useful to know whether a path in the
filesystem has been updated without going to the work of
opening and re-reading its content. We trust the stat()
information on disk already to handle index updates, and we
can use the same trick here.
This patch introduces a "stat_validity" struct which
encapsulates the concept of checking the stat-freshness of a
file. It is implemented on top of "struct stat_data" to
reuse the logic about which stat entries to trust for a
particular platform, but hides the complexity behind two
simple functions: check and update.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add public functions fill_stat_data() and match_stat_data() to work
with it. This infrastructure will later be used to check the validity
of other types of file.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
do_for_each_entry(): increment the packed refs cache refcount
This function calls a user-supplied callback function which could do
something that causes the packed refs cache to be invalidated. So
acquire a reference count on the data structure to prevent our copy
from being freed while we are iterating over it.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
refs: manage lifetime of packed refs cache via reference counting
In struct packed_ref_cache, keep a count of the number of users of the
data structure. Only free the packed ref cache when the reference
count goes to zero rather than when the packed ref cache is cleared.
This mechanism will be used to prevent the cache data structure from
being freed while it is being iterated over.
So far, only the reference in struct ref_cache::packed is counted;
other users will be adjusted in separate commits.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
refs: implement simple transactions for the packed-refs file
Handle simple transactions for the packed-refs file at the
packed_ref_cache level via new functions lock_packed_refs(),
commit_packed_refs(), and rollback_packed_refs().
Only allow the packed ref cache to be modified (via add_packed_ref())
while the packed refs file is locked.
Change clone to add the new references within a transaction.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
refs: wrap the packed refs cache in a level of indirection
As we know, we can solve any problem in this manner. In this case,
the problem is to avoid freeing a packed refs cache while somebody is
using it. So add a level of indirection as a prelude to
reference-counting the packed refs cache.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
repack_without_ref(): split list curation and entry writing
The repack_without_ref() function first removes the deleted ref from
the internal packed-refs list, then writes the packed-refs list to
disk, omitting any broken or stale entries. This patch splits that
second step into multiple passes:
* collect the list of refnames that should be deleted from packed_refs
* delete those refnames from the cache
* write the remainder to the packed-refs file
The purpose of this change is to make the "write the remainder" part
reusable.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-email: sanitize author when writing From line
sender is now sanitized, but we didn't sanitize author when checking
whether From: line is needed in the message body.
As a result git started writing duplicate From: lines when author
matched sender and has utf8 characters.
Reported-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Verify that author name is not duplicated if it matches sender, even
if it is in utf8 (the test expects a failure that will be fixed in
the next patch).
Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The goal of the patch is to introduce the GNU diff
-B/--ignore-blank-lines as closely as possible. The short option is not
available because it's already used for "break-rewrites".
When this option is used, git-diff will not create hunks that simply
add or remove empty lines, but will still show empty lines
addition/suppression if they are close enough to "valuable" changes.
There are two differences between this option and GNU diff -B option:
- GNU diff doesn't have "--inter-hunk-context", so this must be handled
- The following sequence looks like a bug (context is displayed twice):
So here is a more thorough description of the option:
- real changes are interesting
- blank lines that are close enough (less than context size) to
interesting changes are considered interesting (recursive definition)
- "context" lines are used around each hunk of interesting changes
- If two hunks are separated by less than "inter-hunk-context", they
will be merged into one.
The implementation does the "interesting changes selection" in a single
pass.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
resolve_ref_unsafe(): close race condition reading loose refs
We read loose references in two steps. The code is roughly:
lstat()
if error ENOENT:
loose ref is missing; look for corresponding packed ref
else if S_ISLNK:
readlink()
if error:
report failure
else if S_ISDIR:
report failure
else
open()
if error:
report failure
read()
The problem is that the first filesystem call, to lstat(), is not
atomic with the second filesystem call, to readlink() or open().
Therefore it is possible for another process to change the file
between our two calls, for example:
* If the other process deletes the file, our second call will fail
with ENOENT, which we *should* interpret as "loose ref is missing;
look for corresponding packed ref". This can arise if the other
process is pack-refs; it might have just written a new packed-refs
file containing the old contents of the reference then deleted the
loose ref.
* If the other process changes a symlink into a plain file, our call
to readlink() will fail with EINVAL, which we *should* respond to by
trying to open() and read() the file.
The old code treats the reference as missing in both of these cases,
which is incorrect.
So instead, handle errors more selectively: if the result of
readline()/open() is a failure that is inconsistent with the result of
the previous lstat(), then something is fishy. In this case jump back
and start over again with a fresh call to lstat().
One race is still possible and undetected: another process could
change the file from a regular file into a symlink between the call to
lstat and the call to open(). The open() call would silently follow
the symlink and not know that something is wrong. This situation
could be detected in two ways:
* On systems that support O_NOFOLLOW, pass that option to the open().
* On other systems, call fstat() on the fd returned by open() and make
sure that it agrees with the stat info from the original lstat().
However, we don't use symlinks anymore, so this situation is unlikely.
Moreover, it doesn't appear that treating a symlink as a regular file
would have grave consequences; after all, this is exactly how the code
handles non-relative symlinks. So this commit leaves that race
unaddressed.
Note that this solves only the part of the race within
resolve_ref_unsafe. In the situation described above, we may still be
depending on a cached view of the packed-refs file; that race will be
dealt with in a future patch.
This problem was reported and diagnosed by Jeff King <peff@peff.net>,
and this solution is derived from his patch.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
resolve_ref_unsafe(): handle the case of an SHA-1 within loop
There is only one "break" statement within the loop, which jumps to
the code after the loop that handles the case of a file that holds a
SHA-1. So move that code from below the loop into the if statement
where the break was previously located. This makes the logic flow
more local.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
http.c: don't rewrite the user:passwd string multiple times
Curl older than 7.17 (RHEL 4.X provides 7.12 and RHEL 5.X provides
7.15) requires that we manage any strings that we pass to it as
pointers. So, we really shouldn't be modifying this strbuf after we
have passed it to curl.
Our interaction with curl is currently safe (before or after this
patch) since the pointer that is passed to curl is never invalidated;
it is repeatedly rewritten with the same sequence of characters but
the strbuf functions never need to allocate a larger string, so the
same memory buffer is reused.
This "guarantee" of safety is somewhat subtle and could be overlooked
by someone who may want to add a more complex handling of the username
and password. So, let's stop modifying this strbuf after we have
passed it to curl, but also leave a note to describe the assumptions
that have been made about username/password lifetime and to draw
attention to the code.
Signed-off-by: Brandon Casey <drafnel@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
name-rev: allow to specify a subpath for --refs option
When an user wants to filter specific ref using the --refs option,
the pattern needs to match the full ref, e.g. --refs=refs/tags/v1.*.
It'd be convenient to specify a subpath of ref pattern. For
example, --refs=origin/* can find refs/remotes/origin/master by
searching the pattern against its substrings in turn:
Documentation and some comments still refer to files in builtin/
as 'builtin-*.[cho]'. Update these to show the correct location.
Signed-off-by: Phil Hord <hordp@cisco.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Assisted-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The section describing "git diff <blob> <blob>" had been placed in a
position that disrupted the statement "This is synonymous to the
previous form".
Reorder to place this form after all the <commit>-using forms, and the
note applying to them. Also mention this form in the initial description
paragraph.
Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-merge.txt: weaken warning about uncommited changes
Commit 35d2fffd introduced 'git merge --abort' as a synonym to 'git reset
--merge', and added some failing tests in t7611-merge-abort.sh (search
'###' in this file) showing that 'git merge --abort' could not always
recover the pre-merge state.
Still, in many cases, 'git merge --abort' just works, and it is usually
considered that the ability to start a merge with uncommited changes is
an important property of Git.
Weaken the warning by discouraging only merge with /non-trivial/
uncommited changes.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t9802: explicitly name the upstream branch to use as a base
Prior to commit fa83a33b, the 'git checkout' DWIMery would create a
new local branch if the specified branch name did not exist and it
matched exactly one ref in the "remotes" namespace. It searched
the "remotes" namespace for matching refs using a simple comparison
of the trailing portion of the remote ref names. This approach
could sometimes produce false positives or negatives.
Since fa83a33b, the DWIMery more strictly excludes the remote name
from the ref comparison by iterating through the remotes that are
configured in the .gitconfig file. This has the side-effect that
any refs that exist in the "remotes" namespace, but do not match
the destination side of any remote refspec, will not be used by
the DWIMery.
This change in behavior breaks the tests in t9802 which relied on
the old behavior of searching all refs in the remotes namespace,
since the git-p4 script does not configure any remotes in the
.gitconfig. Let's work around this in these tests by explicitly
naming the upstream branch to base the new local branch on when
calling 'git checkout'.
Signed-off-by: Brandon Casey <drafnel@gmail.com> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase topology tests: fix commit names on case-insensitive file systems
The recently introduced tests used uppercase letters to denote
cherry-picks of commits having the corresponding lowercase letter names.
The helper functions also set up tags with the names of the commits.
But this constellation fails on case-insensitive file systems because
there cannot be distinct tags with names that differ only in case.
Use a less subtle convention for the names of cherry-picked commits.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-push.txt: explain better cases where --force is dangerous
The behavior of "git push --force" is rather clear when it updates only
one remote ref, but running it when pushing several branches can really
be dangerous. Warn the users a bit more and give them the alternative to
push only one branch.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/checkout.c: don't leak memory in check_tracking_name
remote_find_tracking() populates the query struct with an allocated
string in the dst member. So, we do not need to xstrdup() the string,
since we can transfer ownership from the query struct (which will go
out of scope at the end of this function) to our callback struct, but
we must free the string if it will not be used so we will not leak
memory.
Let's do so.
Signed-off-by: Brandon Casey <drafnel@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the new rev-parse --prefix option to process all paths given to the
submodule command, dropping the requirement that it be run from the
top-level of the repository.
Since the interpretation of a relative submodule URL depends on whether
or not "remote.origin.url" is configured, explicitly block relative URLs
in "git submodule add" when not at the top level of the working tree.
Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes 'git rev-parse' behave as if it were invoked from the
specified subdirectory of a repository, with the difference that any
file paths which it prints are prefixed with the full path from the top
of the working tree.
This is useful for shell scripts where we may want to cd to the top of
the working tree but need to handle relative paths given by the user on
the command line.
Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When --recursive was added to "submodule foreach" in commit 15fc56a (git
submodule foreach: Add --recursive to recurse into nested submodules,
2009-08-19), the error message when the script returns a non-zero status
was not updated to contain $prefix to show the full path. Fix this.
Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
1b3185f (MALLOC_CHECK: various clean-ups, 2012-09-14) moved around the
MALLOC_CHECK_ and MALLOC_PERTURB_ assignments, intending to limit
their effect to only the test runs. However, they were actually
enabled only during test cleanup. Call setup/teardown_malloc_check
also around the evaluation of the actual test snippet.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of needing a wrapper to call the diff/merge command, simply
provide the diff_cmd and merge_cmd functions for user-specified tools in
the same way as we do for built-in tools.
Signed-off-by: John Keeping <john@keeping.me.uk> Acked-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running 'make test' from a path such as
.../daily-build/master@bdff0e3a374617dce784f801b97500d9ba2e4705, the
logic in fuzz.sed as generated by t5105-request-pull.sh was backwards,
replacing object names before replacing urls, making the test fail.
Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase has no reason to know about the implementation of the stash. In
the case when applying the autostash results in conflicts, replace the
relevant code in finish_rebase () to simply call 'git stash store'.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
save_stash() contains the logic for doing two potentially independent
operations; the first is preparing the stash merge commit, and the
second is updating the stash ref/ reflog accordingly. While the first
operation is abstracted out into a create_stash() for callers to access
via 'git stash create', the second one is not. Fix this by factoring
out the logic for storing the stash into a store_stash() that callers
can access via 'git stash store'.
Like create, store is not intended for end user interactive use, but for
callers in other scripts. We can simplify the logic in the
rebase.autostash feature using this new subcommand.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
GIT_REFLOG_ACTION is an environment variable specifying the reflog
message to write after an action is completed. Several other commands
including merge, reset, and commit respect it.
Fix the failing tests in t/checkout-last by making checkout respect it
too. You can now expect
$ git checkout -
to work as expected after any operation that internally uses "checkout"
as its implementation detail, e.g. "rebase".
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
b397ea4 (status: show more info than "currently not on any branch",
2013-03-13) attempted to make the output of 'git status' richer in
the case of a detached HEAD. Before this patch, with a detached
HEAD, we saw:
$ git status
# Not currently on any branch.
But after the patch, we see:
$ git checkout v1.8.2
$ git status
# HEAD detached at v1.8.2.
It works by digging the reflog for the most recent message of the
form "checkout: moving from xxxx to yyyy". It then asserts that
HEAD and "yyyy" are the same, and displays this message. When they
aren't equal, it displays:
$ git status
# HEAD detached from fe11db.
so that the user can see where the HEAD was first detached.
In case of a rebase [-i] operation in progress, this message depends
on the implementation of rebase writing "checkout: " messages to the
reflog, but that is an implementation detail of "rebase". To remove
this dependency so that rebase can be updated to write better reflog
messages, replace this "HEAD detached from" message with:
# rebase in progress; onto $ONTO
Changes to the commit object name in the expected output for some of
the tests shows that what the test expected "status" to show during
"rebase -i" was not consistent with the output during a vanilla
"rebase", which showed on top of what commit the series is being
replayed. Now we consistently expect something meaningful to the
end user.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t2021-checkout-last: "checkout -" should work after a rebase finishes
$ git checkout -
does not work as expected after a rebase. This is because the
reflog records "checkout" made by "rebase" as its implementation
detail the same way as end-user initiated "checkout", and makes it
count as the branch that was previously checked out.
Add four failing tests documenting this bug: two for a normal rebase,
and another two for an interactive rebase.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
wt-status: remove unused field in grab_1st_switch_cbdata
The struct grab_1st_switch_cbdata has the field "found", which is
set in grab_1st_switch() when a match is found. This information is
redundant and unused by any code. The return value of the function
serves to communicate this information anyway.
Remove the field.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
b397ea4863a1 (status: show more info than "currently not on any
branch", 2013-03-13) wanted to make sure that after a checkout to
detach HEAD, the user can see where the HEAD was originally detached
from. The last test added by that commit to t7512 shows one
example, immediately after HEAD is detached. Enhance that test to
show "detached HEAD from" form that should be shown when the user
further resetted to another commit.
unpack-trees: don't shift conflicts left and right
If o->merge is set, the struct traverse_info member conflicts is shifted
left in unpack_callback, then passed through traverse_trees_recursive
to unpack_nondirectories, where it is shifted right before use. Stop
the shifting and just pass the conflict bit mask as is. Rename the
member to df_conflicts to prove that it isn't used anywhere else.
Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a note saying that the user probably wants "save" in the create
description. While at it, document that it can optionally take a
message in the synopsis.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
$ git am # no input file
^C
$ git am --abort
Resolve operation not in progress, we are not resuming.
This happens because the following test fails:
test -d "$dotest" && test -f "$dotest/last" && test -f "$dotest/next"
and the codepath for an "am in-progress" is not executed. It falls back
to the codepath that treats this as a "fresh execution". Before
rr/rebase-autostash, this condition was
test -d "$dotest"
It would incorrectly execute the "normal" am --abort codepath:
git read-tree --reset -u HEAD ORIG_HEAD
git reset ORIG_HEAD
by incorrectly assuming that an am is "in progress" (i.e. ORIG_HEAD
etc. was written during the previous execution).
Notice that
$ git am
^C
executes nothing of significance, is equivalent to
$ mkdir .git/rebase-apply
Therefore, the correct solution is to treat .git/rebase-apply as a
"stray directory" and remove it on --abort in the fresh-execution
codepath. Also ensure that we're not called with --rebasing from
git-rebase--am.sh; in that case, it is the responsibility of the caller
to handle and stray directories.
While at it, tell the user to run "git am --abort" to get rid of the
stray $dotest directory, if she attempts anything else.
Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge tag 'gitgui-0.18.0' of git://repo.or.cz/git-gui
git-gui 0.18.0
* tag 'gitgui-0.18.0' of git://repo.or.cz/git-gui:
git-gui 0.18
git-gui: avoid an error message when removing the last remote
git-gui: fix file name handling with non-empty prefix
git-gui: bring wish process to front on Mac
git-gui: change dialog button positions for Windows to suit platform.
git-gui: allow "\ No newline at end of file" for linewise staging
git-gui: fix the mergetool launcher for the Beyond Compare tool.
Makefile: replace "echo 1>..." with "echo >..."
French translation: copy -> copie.
git-gui: Fix parsing of <rev> <path-which-not-present-in-worktree>
git-gui: avoid an error message when removing the last remote
When the last remote is removed on a system that has tearoff menu items
the code that adjusts the fetch and prune menus may raise an error when
probing the menu entry for a non-existing -label option.
Check the entry type to avoid this fault.
Reported-by: Vedran Miletić <rivanvx@gmail.com> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
unpack_entry: do not die when we fail to apply a delta
When we try to load an object from disk and fail, our
general strategy is to see if we can get it from somewhere
else (e.g., a loose object). That lets users fix corruption
problems by copying known-good versions of objects into the
object database.
We already handle the case where we were not able to read
the delta from disk. However, when we find that the delta we
read does not apply, we simply die. This case is harder to
trigger, as corruption in the delta data itself would
trigger a crc error from zlib. However, a corruption that
pointed us at the wrong delta base might cause it.
We can do the same "fail and try to find the object
elsewhere" trick instead of dying. This not only gives us a
chance to recover, but also puts us on code paths that will
alert the user to the problem (with the current message,
they do not even know which sha1 caused the problem).
Note that unlike some other pack corruptions, we do not
recover automatically from this case when doing a repack.
There is nothing apparently wrong with the delta, as it
points to a valid, accessible object, and we realize the
error only when the resulting size does not match up. And in
theory, one could even have a case where the corrupted size
is the same, and the problem would only be noticed by
recomputing the sha1.
We can get around this by recomputing the deltas with
--no-reuse-delta, which our test does (and this is probably
good advice for anyone recovering from pack corruption).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test corrupts pack objects by using "dd" with a seek
command. It passes "count=1 bs=1" to munge just a single
byte. However, the test added in commit b3118bdc wants to
munge two bytes, and the second byte of corruption is
silently ignored.
This turned out not to impact the test, however. The idea
was to reduce the "size of this entry" part of the header so
that zlib runs out of input bytes while inflating the entry.
That header is two bytes long, and the test reduced the
value of both bytes; since we experience the problem if we
are off by even 1 byte, it is sufficient to munge only the
first one.
Even though the test would have worked with only a single
byte munged, and we could simply tweak the test to use a
single byte, it makes sense to lift this 1-byte restriction
from do_corrupt_object. It will allow future tests that do
need to change multiple bytes to do so.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote-mediawiki: remove hardcoded version number in the test suite
Updates the code to make it more easy to switch mediawiki version when
testing. Before that, the version number was partly hardcoded, partly
in a var.
Signed-off-by: Benoit Person <benoit.person@ensimag.fr> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/lib-httpd/apache.conf: configure an MPM module for apache 2.4
Versions of Apache before 2.4 always had a "MultiProcessing
Module" (MPM) statically built in, which manages the worker
threads/processes. We do not care which one, as it is
largely a performance issue, and we put only a light load on
the server during our testing.
As of Apache 2.4, the MPM module is loadable just like any
other module, but exactly one such module must be loaded. On
a system where the MPMs are compiled dynamically (e.g.,
Debian unstable), this means that our test Apache server
will not start unless we provide the appropriate
configuration.
Unfortunately, we do not actually know which MPM modules are
available or appropriate for the system on which the tests
are running. This patch picks the "prefork" module, as it
is likely to be available on all Unix-like systems.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/lib-httpd/apache.conf: load compat access module in apache 2.4
In apache 2.4, the "Order" directive has gone away in favor
of a new system in mod_authz_host. However, since we want
our config file to remain compatible across multiple Apache
versions, we can use mod_access_compat to keep using the
older style.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/lib-httpd/apache.conf: do not use LockFile in apache >= 2.4
The LockFile directive from earlier versions of apache has
been replaced by the Mutex directive. The latter seems to
give sane defaults and does not need any specific
customization, so we can get away with just adding a version
check to the use of LockFile.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The revisions specified on the command-line as <onto> and <upstream>
arguments could be of the form :/quuxery; so, use peel_committish() to
resolve them. The failing tests in t/rebase and t/rebase-interactive
now pass.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The normal way to check whether a certain revision resolves to a valid
commit is:
$ git rev-parse --verify $REV^0
Unfortunately, this does not work when $REV is of the type :/quuxery.
Write a helper to work around this limitation.
Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/rebase: add failing tests for a peculiar revision
The following commands fail, even if :/quuxery and :/foomery resolve to
perfectly valid commits:
$ git rebase [-i] --onto :/quuxery :/foomery
This is because rebase [-i] attempts to rev-parse ${REV}^0 to verify
that the given revision resolves to a commit. Add tests to document
these failures.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote-mediawiki: make error message more precise
In subroutine parse_command, error messages were not correct. For the "import"
function, having too much or incorrect arguments displayed both
"invalid arguments", while it displayed "too many arguments" for the "option"
functions under the same conditions.
Separate the two error messages in both cases.
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote-mediawiki: add a perlcritic rule in Makefile
Option "-2" launches perlcritic with level 2. Levels go from 5 (most pertinent)
to 1. Rules of level 1 are mostly a question of style, and are therefore
ignored.
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote-mediawiki: put non-trivial numeric values in constants.
Non-trivial numeric values (e.g., different from 0, 1 and 2) are placed in
constants at the top of the code to be easily modifiable and to make more sense
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote-mediawiki: brace file handles for print for more clarity
This follows the following rule:
InputOutput::RequireBracedFileHandleWithPrint (Severity: 1)
The `print' and `printf' functions have a unique syntax that supports an
optional file handle argument. Conway suggests wrapping this argument in
braces to make it visually stand out from the other arguments. When you
put braces around any of the special package-level file handles like
`STDOUT', `STDERR', and `DATA', you must the `'*'' sigil or else it
won't compile under `use strict 'subs''.
print $FH "Mary had a little lamb\n"; #not ok
print {$FH} "Mary had a little lamb\n"; #ok
git-remote-mediawiki: modify strings for a better coding-style
- strings which don't need interpolation are single-quoted for more clarity and
slight gain of performance
- interpolation is preferred over concatenation in many cases, for more clarity
- variables are always used with the ${} operator inside strings
- strings including double-quotes are written with qq() so that the quotes do
not have to be escaped
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote-mediawiki: change the behaviour of a split
A "split ' '" is turned into a "split / /", which changes its behaviour: the
old method matched a run of whitespaces (/\s*/), while the new one will match a
single space, which is what we want here. Indeed, in other contexts,
changing split(' ') to split(/ /) could potentially be a regression, however,
here, when parsing the output of "rev-list --parents", whose output SHA-1's are
each separated by a single space, splitting on a single space is perfectly
correct.
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote-mediawiki: rewrite unclear line of instructions
Subroutines' parameters should be assigned to variable before doing anything
else
Besides, existing instruction affected a variable inside a "if", which break
Git's coding style
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>