Decode file names from system encoding in all diff hunk header lines, not
just the first (i.e. print nice file names in 'rename from' / 'rename to' /
'Binary files' lines, too).
Signed-off-by: Karsten Blees <blees@dcon.de>
Assume git tree objects (i.e. output of git-ls-tree) are encoded in system
encoding, for display in the git-gui file browser.
Signed-off-by: Karsten Blees <blees@dcon.de>
Make use of the new environment variable GIT_ASK_YESNO to support the
recently implemented fallback in case unlink, rename or rmdir fail for
files in use on Windows. The added dialog will present a yes/no question
to the the user which will currently be used by the windows compat layer
to let the user retry a failed file operation.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
This fixes a rebase in the presence of dirty submodules. This is
orthogonal to the application of patches changing submodules.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Commit a31e626 (completion: optimize refs completion) introduced a
regression for ZSH users: ref names were completed with a quoted trailing
space (i.e. "git checkout ma" completes to "git checkout master\ "). The
space is convenient for bash users since we use "-o nospace", but a
quoted space is worse than nothing. The absence of trailing space for ZSH
is a long-standing issue, that this patch is not fixing. We just fix the
regression by not appending a space when the shell is ZSH.
Original-patch-by: SZEDER Gábor <szeder@ira.uka.de>
Reported-by: Stefan Haller <lists@haller-berlin.de>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With msysGit the .git directory is supposed to be hidden, unless it is
a bare git repository. Test this.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
As reported in msysGit issue 450 the recent change to set the windows
hidden attribute on the .git directory is being applied to bare git
directories. This patch excludes bare repositories.
Tested-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
At least for cross-platform projects, it makes sense to hide the
files starting with a dot, as this is the behavior on Unix/MacOSX.
However, at least Eclipse has problems interpreting the hidden flag
correctly, so the default is to hide only the .git/ directory.
The config setting core.hideDotFiles therefore supports not only
'true' and 'false', but also 'dotGitOnly'.
[jes: clarified the commit message, made git init respect the setting
by marking the .git/ directory only after reading the config, and added
documentation, and rebased on top of current junio/next]
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
This is a gcc-ism, but as we use gcc exclusively, we can use them.
Taken from one of Junio's mails. (Reminded to cherry-pick this patch
by one of Karsten Blees' mails.)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Apparently the signal handling is not quite correct in the fsckobject
handling (most likely we rely on a side effect that lets us still output
some message after receiving a signal 13 but in the BuildHive setup this
fails intermittently).
As a consequence, the push in t5504 does fail as expected, but fails to
output anything (unexpected). Since this is good enough for now, let's
handle an empty output as success, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Move this just before the commit "Win32: simplify internal mingw_spawn*
APIs" and give it a *much* better commit message.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This just reverts the previous commit (the one with the horrible commit
message). So just kill both commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Use this commit message, rewrapped to 76 columns:
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 <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
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 <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
By Junio C Hamano (2) and others
* master:
Git 1.7.11-rc0
Git 1.7.10.3
fmt-merge-message: add empty line between tag and signature verification
config doc: remove confusion about relative GIT_DIR from FILES section
Simplification for the codepath to read directories recursively.
By René Scharfe
* rs/dir-strbuf-read-recursive-fix:
dir: simplify fill_directory()
dir: respect string length argument of read_directory_recursive()
"git grep -e '$pattern'", unlike the case where the patterns are read from
a file, did not treat individual lines in the given pattern argument as
separate regular expressions as it should.
When a submodule repository uses alternate object store mechanism, some
commands that were started from the superproject did not notice it and
failed with "No such object" errors. The subcommands of "git submodule"
command that recursed into the submodule in a separate process were OK;
only the ones that cheated and peeked directly into the submodule's
repository from the primary process were affected.
By Heiko Voigt
* hv/submodule-alt-odb:
teach add_submodule_odb() to look for alternates
The directory path used in "git diff --no-index", when it recurses
down, was broken with a recent update after v1.7.10.1 release.
By Bobby Powers
* bp/diff-no-index-strbuf-fix:
diff --no-index: don't leak buffers in queue_diff
diff --no-index: reset temporary buffer lengths on directory iteration
When adding the information from a tag, put an empty line between the
message of the tag and the commented-out signature verification
information.
At least for the kernel workflow, I often end up re-formatting the message
that people send me in the tag data. In that situation, putting the tag
message and the tag signature verification back-to-back then means that
normal editor "reflow parapgraph" command will get confused and think that
the signature is a continuation of the last message paragraph.
So I always end up having to first add an empty line, and then go back and
reflow the last paragraph. Let's just do it in git directly.
The extra vertical space also makes the verification visually stand out
more from the user-supplied message, so it looks a bit more readable to me
too, but that may be just an odd personal preference.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
From the FILES section of the git-config(1) manual:
$GIT_DIR/config::
Repository specific configuration file. (The filename is
of course relative to the repository root, not the working
directory.)
That's confusing because $GIT_DIR really is relative to the working
directory.
$ GIT_DIR=.git GIT_EDITOR='pwd; echo editing'
$ export GIT_DIR GIT_EDITOR
$ git config --edit --local
/home/jrn/src/git/Documentation
editing .git/config
It turns out that the comment is a remnant from older days when the
heading said ".git/config" (which is indeed relative to the top of the
worktree).
It was only when the heading was changed to refer more precisely to
<git dir>/config (see v1.5.3.2~18, AsciiDoc tweak to avoid leading
dot, 2007-09-14) that the parenthesis stopped making sense. Remove
it.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The way "fetch-pack" that is given multiple references to fetch tried to
remove duplicates was very inefficient.
Will merge to master.
By Jeff King
* jk/fetch-pack-remove-dups-optim:
fetch-pack: sort incoming heads list earlier
Fixes quite a lot of brokenness when ident information needs to be taken
from the system and cleans up the code.
Will merge to master.
By Jeff King
* jk/ident-gecos-strbuf:
format-patch: do not use bogus email addresses in message ids
ident: reject bogus email addresses with IDENT_STRICT
ident: rename IDENT_ERROR_ON_NO_NAME to IDENT_STRICT
format-patch: use GIT_COMMITTER_EMAIL in message ids
ident: let callers omit name with fmt_indent
ident: refactor NO_DATE flag in fmt_ident
ident: reword empty ident error message
We can ask git_committer_info to be strict about coming up
with an email, which will die automatically on a poorly
configured machine. This is better than letting invalid
message-ids into the wild.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we come up with a hostname like "foo.(none)" because the
user's machine is not fully qualified, we should reject this
in strict mode (e.g., when we are making a commit object),
just as we reject an empty gecos username.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
