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>
make and make test both work when $GIT_DIR isn't .git, but make dist
included a bogus GIT-VERSION-FILE.
Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net>
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>
$ 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>
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>
b397ea4863 (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.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
The option parser for create unnecessarily checks "$1" inside a case
statement that matches "$1" in the first place.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git stash save' can take -p, the short form of --patch, as an option.
Document this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
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>
Replace instances of ! test -d with test_path_is_missing.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The following bug has been observed:
$ 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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
iQCVAwUAUbzwiGB90JXwhOSJAQKxtAP/TYTpKWzKiDwzu/2P6ecIWcS/4vaKlj1M
WSyvp4t4stTXhRXntId7psQO7nYTb+Pb3VlY+WPr9J3xL39IjU2qHLsrQJEqtsWI
FcE7SNxB0BvNreAqkdYNaKqSfGqQJPdV8K5WKaySZMpMkq/ZOT7WiOQq6wynDLuR
sDopx39hLDI=
=Az9M
-----END PGP SIGNATURE-----
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>
Some people often run 'git status -b'.
The config variable status.branch allows to set it by default.
Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr>
Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>
Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
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>
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>
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>
In apache 2.4, the "Auth*" and "Require" directives have
moved into the authn_core and authz_core modules,
respectively.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
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>
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>
Such a file allows to configure perlcritic.
Here, it is used to remove many unwanted rules and configure one to
remove unwanted warnings.
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>
@$var structures are re-written in the following way: @{$var}
It makes them more readable.
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>
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>
Empty strings are replaced by an $EMPTY constant.
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>
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
print STDERR $foo, $bar, $baz; #not ok
print {STDERR} $foo, $bar, $baz; #won't compile under 'strict'
print {*STDERR} $foo, $bar, $baz; #perfect!
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>
- 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>
Explicitly assign local variable $/ as undef and make a proper
one-instruction-by-line indentation
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>
