If git rebase interactive is stopped by "edit" command and then the user
said "git rebase --continue" while having some stage changes, git rebase
interactive is trying to amend the last commit by doing:
git --soft reset && git commit
However, the user can abort commit for some reason by providing an empty
log message, and that would leave the last commit undone, while the user
being completely unaware about what happened. Now if the user tries to
continue, by issuing "git rebase --continue" that squashes two previous
commits.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing in-code comment was misleading. An access that is not
"reading" may often be "writing", but it does not have to be.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
OS X sed doesn't understand '\n' on the right side of a substitution.
Use a valid substitution character instead and use 'tr' to convert
those to a newline.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The non-verbose output was not changed in fdb2a2a (compat: introduce
on_disk_bytes(), 2008-08-18) which caused git-count-objects to claim 512
times too much space used for loose objects.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The reason that git-shell was excluded from the Windows build was that
our compatibility layer needed stuff that was removed when we tried to
link less of the git library into git-shell. Since 4cfc24a (shell: do
not play duplicated definition games to shrink the executable,
2008-08-19) the complete library is linked again, so we can build
git-shell on Windows as well. (This fixes 'make install', which depends
on that git-shell is always built.)
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This replaces 'git-svn' with 'git svn' in the tests.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Subversion tests use too many "git-foo" form, so I am converting them
in two steps.
This first step replaces literal strings "remotes/git-svn" and "git-svn-id"
by introducing $remotes_git_svn and $git_svn_id constants defined as shell
variables. This will reduce the number of false hits from "git grep".
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise it will always print the class-name rather
than the name of the function inside that class.
While we're at it, reorder the gitattributes manpage to
list the built-in funcname pattern names in alphabetical
order.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Originally from Mike Hommey; earlier we were disabling SSL_VERIFYPEER
but SSL_VERIFYHOST was in effect even when the user asked not to with
the environment variable.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Apparently do_switch() tolerates the lack of escaping in less
funky branch names. For the really strange and scary ones, we
need to escape them properly. It strangely maintains compatible
with the existing handling of branch names with spaces and
exclamation marks.
Reported-by: m.skoric@web.de ($gmane/94677)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This function is outside POSIX (Linux and recent BSD have it). Replace it
with setvbuf() which is POSIX.
I am not sure about the value this patch passes as size argument to
setvbuf(), though. I know the call this patch makes is equivalent to
calling setlinebuf() with GNU libc, but POSIX itself leaves what happens
to the size argument quite vague, saying only "otherwise [i.e. when buf is
a null pointer], size _may_ determine the size of a buffer allocated by
the setvbuf() function." If passing size=0 causes stdio to allocate very
small buffer, and while stdio tries to line buffer the output, it might
make it to fail to buffer an entire line, causing early flushing of the
stream.
Even if that turns out to be a problem on minorority platforms, we won't
know it until the issue actually hurts them, so let's push this change out
and see what happens.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://git.bogomips.org/git-svn:
git-svn: set auto_props when renaming files
t9124: clean up chdir usage
git-svn: fix 'info' tests for unknown items
git-svn: match SVN 1.5 behaviour of info' on unknown item
git svn info: always quote URLs in 'info' output
git svn info: make info relative to the current directory
git svn info: tests: fix ptouch argument order in setup
git svn info: tests: use test_cmp instead of git-diff
git svn info: tests: do not use set -e
git svn info: tests: let 'init' test run with SVN 1.5
git svn: catch lack of upstream info for dcommit earlier
git-svn: check error code of send_txstream
git-svn: Send deltas during commits
git-svn: Introduce SVN::Git::Editor::_chg_file_get_blob
git-svn: extract base blob in generate_diff
The point of --quiet was to return the status as early as possible without
doing any extra processing. Well behaved scripts, when they expect to run
many diff operations inside, are supposed to run "update-index --refresh"
upfront; we do not want them to pay the price of iterating over the index
and comparing the contents to fix the stat dirtiness, and we avoided most
of the processing in diffcore_std() when --quiet is in effect.
But scripts that adhere to the good practice won't have to pay any more
price than the necessary lstat(2) that will report stat cleanliness, as
long as only -q is given without any fancier diff options.
More importantly, users who do ask for "--quiet -M --filter=D" (in order
to notice only the deletion, not paths that disappeared only because they
have been renamed away) deserve to get the result they asked for, even it
means they have to pay the extra price; the alternative is to get a cheap
early return that gives a result they did not ask for, which is much
worse.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we enabled the automatic refreshing of the index to "diff" Porcelain,
we disabled it when --find-copies-harder was asked, but there is no good
reason to do so. In the following command sequence, the first "diff"
shows an "empty" diff exposing stat dirtyness, while the second one does
not.
$ >foo
$ git add foo
$ touch foo
$ git diff -C -C
$ git diff -C
This fixes the inconsistency.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Patch-by: Paul Talacko <gnuruandstuff@yahoo.co.uk>:
<http://article.gmane.org/gmane.comp.version-control.git/95006>
> Hello,
>
> There's an issue in git-svn as autoprops are not applied to
> renamed files, only to added files.
>
> This patch fixes the bug.
[ew: added test case]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Spawn subshells when running things in subdirectories instead of
chdir-ing to the path of an undefined variable, which is
confusing.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Merge git://repo.or.cz/git-gui and git://git.kernel.org/pub/scm/gitk/gitk
* git://repo.or.cz/git-gui:
git-gui: Show special diffs for complex conflict cases.
git-gui: Make F5 reselect a diff, if an untracked file is selected.
git-gui: Reimplement and enhance auto-selection of diffs.
git-gui: Support conflict states _U & UT.
git-gui: Support more merge tools.
git-gui: Don't allow staging files with conflicts.
git-gui: Support calling merge tools.
git-gui: Support resolving conflicts via the diff context menu.
git-gui: Mark forgotten strings for translation.
git-gui: Allow specifying an initial line for git gui blame.
git-gui: Better positioning in Blame Parent Commit
git-gui: Support passing blame to a parent commit.
git-gui: Support starting gitk from Gui Blame
git-gui: Teach git gui about file type changes
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Add menu item for calling git gui blame
gitk: Add option to specify the default commit on command line
* maint:
Update draft release notes for 1.6.0.2
stash: refresh the index before deciding if the work tree is dirty
Mention the fact that 'git annotate' is only for backward compatibility.
"blame -c" should be compatible with "annotate"
git-gui: Fix diff parsing for lines starting with "--" or "++"
git-gui: Fix string escaping in po2msg.sh
git gui: show diffs with a minimum of 1 context line
git-gui: update all remaining translations to French.
git-gui: Update french translation
Unlike the case where the user does have a real change in the work tree,
refusing to work because of unclean stat information is not very helpful.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Nanako Shiraishi <nanako3@lavabit.com>
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Fix diff parsing for lines starting with "--" or "++"
git-gui: Fix string escaping in po2msg.sh
git gui: show diffs with a minimum of 1 context line
git-gui: update all remaining translations to French.
git-gui: Update french translation
Tries to shorten the refname to a non-ambiguous name.
Szeder Gábor noticed that the git bash completion takes a
tremendous amount of time to strip leading components from
heads and tags refs (i.e. refs/heads, refs/tags, ...). He
proposed a new atom called 'refbasename' which removes at
most two leading components from the ref name.
I myself, proposed a more dynamic solution, which strips off
common leading components with the matched pattern.
But the current bash solution and both proposals suffer from
one mayor problem: ambiguous refs.
A ref is ambiguous, if it resolves to more than one full refs.
I.e. given the refs refs/heads/xyzzy and refs/tags/xyzzy. The
(short) ref xyzzy can point to both refs.
( Note: Its irrelevant whether the referenced objects are the
same or not. )
This proposal solves this by checking for ambiguity of the
shorten ref name.
The shortening is done with the same rules for resolving refs
but in the reverse order. The short name is checked if it
resolves to a different ref.
To continue the above example, the output would be like this:
heads/xyzzy
xyzzy
So, if you want just tags, xyzzy is not ambiguous, because it
will resolve to a tag. If you need the heads you get a also
a non-ambiguous short form of the ref.
To integrate this new format into the bash completion to get
only non-ambiguous refs is beyond the scope of this patch.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using return values from the following functions:
- check_merge_bases
- check_good_are_ancestors_of_bad
seems simpler.
While at it, let's add some comments to better document the above
functions.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous tests all expected the results from SVN and Git to be
identical, and expected both to return success. This cannot be
guaranteed: SVN changed the message style between 1.4 and 1.5, and
in 1.5, sets a failure exit code.
Change the tests to verify that 'git svn info <item>' sets a failure
exit code, and that its output contains the file name. This should
hopefully catch all other errors.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
Previously 'git svn info unknown-file' only announced its failure (in
the SVN 1.4 style, "not a versioned resource"), and exited
successfully.
It is desirable to actually exit with failure, so change the code to
exit(1) under this condition. Since that is already halfway SVN 1.5
compatibility, also change the error output to match 1.5.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
Changes 'git svn info' to always URL-escape the 'URL' and 'Repository'
fields and --url output, like SVN (at least 1.5) does.
Note that reusing the escape_url() further down in Git::SVN::Ra is not
possible because it only triggers for http(s) URLs. I did not know
whether extending it to all schemes would break SVN access anywhere,
so I made a new one that quotes in all schemes.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
Previously 'git svn info <path>' would always treat the <path> as
relative to the working directory root, with a default of ".". This
does not match the behaviour of 'svn info'. Prepend $(git rev-parse
--show-prefix) to the path used inside cmd_info to make it relative to
the current working directory.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
The arguments must be <gitwc-path> <svnwc-path>, otherwise it fails to
update the timestamps (without setting a failure exit code) and
results in bad test output later on.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
git-diff does not appear to return the correct exit values, and gives
a false success for more than half (!) of the tests due to the space
in "trash directory" which git-svn fails to encode.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
Exiting in the middle of a test confuses the test suite, which will
just say "FATAL: Unexpected exit with code 1" in response to a failed
test, instead of actually diagnosing failure and continuing with the
next test.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
Since 711521e 'git svn dcommit' attempts to use the upstream
information to determine the SVN URL, before it verifies that it even
found an upstream. Move up the corresponding check.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
Not checking the error code of a function used to transform and
send data makes me nervous. It currently returns "undef" on
success; so die if we get any result other than "undef" because
it's likely something went wrong somewhere. I really wish this
function returned an MD5 like send_stream (or better yet, SHA1)
for verification.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We need the base blob to compute a delta to be sent to the server.
Signed-off-by: Florian Weimer <fw@deneb.enyo.de>
Acked-by: Eric Wong <normalperson@yhbt.net>
When somebody is reading git-blame.txt (or git-annotate.txt) for the first
time, the message we would like to send is:
(1) Here is why you would want to use this command, what it can do
(perhaps more than what you would have expected from "$scm blame"),
and how you tell it to do what it does.
This is obvious.
(2) You might have heard of the command with the other name. There is no
difference between the two, except they differ in their default
output formats.
This is essential to answer: "git has both? how are they different?"
(3) We tend to encourage blame over annotate for new scripts and new
people, but there is no reason to choose one over the other.
This is not as important as (2), but would be useful to avoid
repeated questions about "when will we start deprecating this?"
As long as we describe (2) on git-annotate page clearly enough, people who
read git-blame page first and get curious can refer to git-annotate page.
While at it, subtly hint (3) without being overly explicit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is no reason to have a separate variable cmd_is_annotate;
OUTPUT_ANNOTATE_COMPAT option is supposed to produce the compatibility
output, and we should produce the same output even when the command was
not invoked as "annotate" but as "blame -c".
Noticed by Pasky.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/maint-log-grep:
log --author/--committer: really match only with name part
diff --cumulative is a sub-option of --dirstat
bash completion: Hide more plumbing commands
When we tried to find commits done by AUTHOR, the first implementation
tried to pattern match a line with "^author .*AUTHOR", which later was
enhanced to strip leading caret and look for "^author AUTHOR" when the
search pattern was anchored at the left end (i.e. --author="^AUTHOR").
This had a few problems:
* When looking for fixed strings (e.g. "git log -F --author=x --grep=y"),
the regexp internally used "^author .*x" would never match anything;
* To match at the end (e.g. "git log --author='google.com>$'"), the
generated regexp has to also match the trailing timestamp part the
commit header lines have. Also, in order to determine if the '$' at
the end means "match at the end of the line" or just a literal dollar
sign (probably backslash-quoted), we would need to parse the regexp
ourselves.
An earlier alternative tried to make sure that a line matches "^author "
(to limit by field name) and the user supplied pattern at the same time.
While it solved the -F problem by introducing a special override for
matching the "^author ", it did not solve the trailing timestamp nor tail
match problem. It also would have matched every commit if --author=author
was asked for, not because the author's email part had this string, but
because every commit header line that talks about the author begins with
that field name, regardleses of who wrote it.
Instead of piling more hacks on top of hacks, this rethinks the grep
machinery that is used to look for strings in the commit header, and makes
sure that (1) field name matches literally at the beginning of the line,
followed by a SP, and (2) the user supplied pattern is matched against the
remainder of the line, excluding the trailing timestamp data.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Languages like Lua and SQL use "--" to mark a line as commented out.
If this appears at column 0 and is part of the pre-image we may see
"--- foo" in the diff, indicating that the line whose content is
"-- foo" has been removed from the new version.
git-gui was incorrectly parsing "--- foo" as the old file name
in the file header, causing it to generate a bad patch file when
the user tried to stage or unstage a hunk or the selected line.
We need to keep track of where we are in the parsing so that we do
not misread a deletion or addition record as part of the header.
Reported-by: Alexander Gladysh <agladysh@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Add special handling for displaying diffs of modified/deleted,
and symlink/mode conflicts. Currently the display is completely
unusable for deciding how to resolve the conflict.
New display modes:
1) Deleted/Modified conflict: e.g.
LOCAL: deleted
REMOTE:
[diff :1:$path :3:$path]
2) Conflict involving symlinks:
LOCAL:
[diff :1:$path :2:$path]
REMOTE:
[diff :1:$path :3:$path]
In order to be able to display multiple diffs, this
patch adds a queue of commands to call.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If an untracked file is selected, F5 and other manual rescan synonyms
would try to select a tracked file instead. Also, clicking on an icon
in the unstaged changes list skips over untracked files, unless the
file clicked is untracked itself.
The objective is to make it easier to ignore untracked files showing
up in the Unstaged Changes list, and ensure that no modifications
to tracked objects are left unstaged.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
