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>
This outputs the current branch on which a commit was created, just for
reference. For example:
Created commit 6d42875 on master: Fix submodule invalid command error
This also reminds the committer when he is on a detached HEAD:
Created commit 02a7172 on detached HEAD: Also do this for 'git commit --amend'
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reorganize header generation so that all header text related to each
block is in one place.
This adds a function, but makes it easier to see what is generated in
each case. It also allows for easy tweaking of individual headers.
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>
Once we committed the locked index, we should release the lockfile. In
most cases this is done automatically when the process ends, but this is
not true in this case.
[jc: with additional tests from Eric Raible]
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
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>
This allows --include=pathspec, similar to --exclude=pathspec.
The rule when one or both of these are used is that the include/exclude
patterns are examined in the order they are given on the command line, and
the first match determines if a patch to each path is used or not. Hence:
$ git apply --include='specific.h' --exclude='*.h' <diff
would apply the patch to specific.h header file, but all other patches in
the input file to other header files are ignored. A patch to a path that
does not match any include/exclude pattern is used by default if there is
no include pattern on the command line, and ignored if there is any
include pattern.
This originally came from Joe Perches, but both the design of the
semantics and the implementation have been redone complately.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
This new option --dirstat-by-file is the same as --dirstat, but it
counts "impacted files" instead of "impacted lines" (lines that are
added or removed).
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We now just leave the object->sha1 field of virtual commits 0{40} as it
is initialized, as a unique hash is not necessary in case of virtual
commits.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
