Git has difficulties on file systems that do not properly
distinguish case or modify filenames in unexpected ways. The two
major examples are Windows and Mac OS X. Both systems preserve
case of file names but do not distinguish between filenames that
differ only by case. Simple operations such as "git mv" or
"git merge" can fail unexpectedly. In addition, Mac OS X normalizes
unicode, which make git's life even harder.
This commit adds tests that currently fail but should pass if
file system as decribed above are fully supported. The test need
to be run on Windows and Mac X as they already pass on Linux.
Mitch Tishmack is the original author of the tests for unicode
normalization.
[jc: fixed-up so that it will use test_expect_success to test
on sanely behaving filesystems.]
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is just a basic sanity check that --compose works at
all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, the fake.sendmail test harness would write its
output to a hardcoded file, allowing only a single message
to be tested. Instead, let's have it save the messages for
all of its invocations so that we can see which messages
were sent, and in which order.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We do not account binary nor unmerged files when --shortstat is
asked for (or the summary stat at the end of --stat).
The new option --dirstat should work the same way as it is about
summarizing the changes of multiple files by adding them up.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/apply-whitespace:
ws_fix_copy(): move the whitespace fixing function to ws.c
apply: do not barf on patch with too large an offset
core.whitespace: cr-at-eol
git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run
builtin-apply.c: pass ws_rule down to match_fragment()
builtin-apply.c: move copy_wsfix() function a bit higher.
builtin-apply.c: do not feed copy_wsfix() leading '+'
builtin-apply.c: simplify calling site to apply_line()
builtin-apply.c: clean-up apply_one_fragment()
builtin-apply.c: mark common context lines in lineinfo structure.
builtin-apply.c: optimize match_beginning/end processing a bit.
builtin-apply.c: make it more line oriented
builtin-apply.c: push match-beginning/end logic down
builtin-apply.c: restructure "offset" matching
builtin-apply.c: refactor small part that matches context
So I find it irritating when git thinks for a long time without telling me
what's taking so long. And by "long time" I definitely mean less than two
seconds, which is already way too long for me.
This hits me when doing a large pull and the checkout takes a long time,
or when just switching to another branch that is old and again checkout
takes a while.
Now, git read-tree already had support for the "-v" flag that does nice
updates about what's going on, but it was delayed by two seconds, and if
the thing had already done more than half by then it would be quiet even
after that, so in practice it meant that we migth be quiet for up to four
seconds. Much too long.
So this patch changes the timeout to just one second, which makes it much
more palatable to me.
The other thing this patch does is that "git checkout" now doesn't disable
the "-v" flag when doing its thing, and only disables the output when
given the -q flag. When allowing "checkout -m" to fall back to a 3-way
merge, the users will see the error message from straight "checkout",
so we will tell them that we do fall back to make them look less scary.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the SHA-1 we are requesting the object for does not exist in
the object database we get a NULL back. Accessing the type from
that is not likely to succeed on any system.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Cygwin we have to use git-archive.exe as the target, otherwise
running 'make dist' does not compile git-archive in the current
directory. That may cause 'make dist' to fail on a clean source
tree that has never been built before.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use int(<expr>/2) to get integer value for a substring length.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Focus insertion point at end of strings in repository chooser
git-gui: Avoid hardcoded Windows paths in Cygwin package files
git-gui: Default TCL_PATH to same location as TCLTK_PATH
git-gui: Paper bag fix error dialogs opening over the main window
git-gui: Ensure error dialogs always appear over all other windows
git-gui: relax "dirty" version detection
git-gui: support Git Gui.app under OS X 10.5
rebase supports --strategy, so pull should pass the option along to it.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to just memcpy() the index entry when we copied the stat() and
SHA1 hash information, which worked well enough back when the index
entry was just an exact bit-for-bit representation of the information on
disk.
However, these days we actually have various management information in
the cache entry too, and we should be careful to not overwrite it when
we copy the stat information from another index entry.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes the name hash removal function (which really just sets the
bit that disables lookups of it) available to external routines, and
makes read_cache_unmerged() use it when it drops an unmerged entry from
the index.
It's renamed to remove_index_entry(), and we drop the (unused) 'istate'
argument.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We handled the case of removing and re-inserting cache entries badly,
which is something that merging commonly needs to do (removing the
different stages, and then re-inserting one of them as the merged
state).
We even had a rather ugly special case for this failure case, where
replace_index_entry() basically turned itself into a no-op if the new
and the old entries were the same, exactly because the hash routines
didn't handle it on their own.
So what this patch does is to not just have the UNHASHED bit, but a
HASHED bit too, and when you insert an entry into the name hash, that
involves:
- clear the UNHASHED bit, because now it's valid again for lookup
(which is really all that UNHASHED meant)
- if we're being lazy, we're done here (but we still want to clear the
UNHASHED bit regardless of lazy mode, since we can become unlazy
later, and so we need the UNHASHED bit to always be set correctly,
even if we never actually insert the entry into the hash list)
- if it was already hashed, we just leave it on the list
- otherwise mark it HASHED and insert it into the list
this all means that unhashing and rehashing a name all just works
automatically. Obviously, you cannot change the name of an entry (that
would be a serious bug), but nothing can validly do that anyway (you'd
have to allocate a new struct cache_entry anyway since the name length
could change), so that's not a new limitation.
The code actually gets simpler in many ways, although the lazy hashing
does mean that there are a few odd cases (ie something can be marked
unhashed even though it was never on the hash in the first place, and
isn't actually marked hashed!).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We were returning the _address of_ the stored item (or NULL)
instead of the item itself. While this sort of indirection
is useful for insertion (since you can lookup and then
modify), it is unnecessary for read-only lookup. Since the
hash code splits these functions between the internal
lookup_hash_entry function and the public lookup_hash
function, it makes sense for the latter to provide what
users of the library expect.
The result of this was that the index caching returned bogus
results on lookup. We unfortunately didn't catch this
because we were returning a "struct cache_entry **" as a
"void *", and accidentally assigning it to a "struct
cache_entry *".
As it happens, this actually _worked_ most of the time,
because the entries were defined as:
struct cache_entry {
struct cache_entry *next;
...
};
meaning that interpreting a "struct cache_entry **" as a
"struct cache_entry *" would yield an entry where all fields
were totally bogus _except_ for the next pointer, which
pointed to the actual cache entry. When walking the list, we
would look at the bogus "name" field, which was unlikely to
match our lookup, and then proceed to the "real" entry.
The reading of bogus data was silently ignored most of the
time, but could cause a segfault for some data (which seems
to be more common on OS X).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When searching commit messages (commit search), if matched string is
too long, the generated HTML was munged leading to an ill-formed XHTML
document.
Now gitweb chop leading, trailing and matched parts, HTML escapes
those parts, then composes and marks up match info. HTML output is
never chopped. Limiting matched info to 80 columns (with slop) is now
done by dividing remaining characters after chopping match equally to
leading and trailing part, not by chopping composed and HTML marked
output.
Noticed-by: Jean-Baptiste Quenot <jbq@caraldi.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After changing builtin-tag.c to use strbuf in fd17f5b (Replace all
read_fd use with strbuf_read, and get rid of it.), the last condition
in do_sign() will always be false, as it's checked already right
above. So let's remove the cruft.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The options following <merge-program> are not -a, --, or <file>...,
but either -a, or -- <file>..., while -- is optional.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When selecting a local working directory for a new repository or a
location to clone an existing repository into we now set the insert
point at the end of the selected path, allowing the user to type in
any additional parts of the path if they so desire.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we are being built by the Cygwin package maintainers we need to
embed the POSIX path to our library files and not the Windows path.
Embedding the Windows path means all end-users who install our Cygwin
package would be required to install Cygwin at the same Windows path
as the package maintainer had Cygwin installed to. This requirement
is simply not user-friendly and may be infeasible for a large number
of our users.
We now try to auto-detect if the Tcl/Tk binary we will use at runtime
is capable of translating POSIX paths into Windows paths the same way
that cygpath does the translations. If the Tcl/Tk binary gives us the
same results then it understands the Cygwin path translation process
and should be able to read our library files from a POSIX path name.
If it does not give us the same answer as cygpath then the Tcl/Tk
binary might actually be a native Win32 build (one that is not
linked against Cygwin) and thus requires the native Windows path
to our library files. We can assume this is not a Cygwin package
as the Cygwin maintainers do not currently ship a pure Win32 build
of Tcl/Tk.
Reported on the git mailing list by Jurko Gospodnetić.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most users set TCLTK_PATH to tell git-gui where to find wish, but they
fail to set TCL_PATH to the same Tcl installation. We use the non-GUI
tclsh during builds so headless systems are still able to create an
index file and create message files without GNU msgfmt. So it matters
to us that we find a working TCL_PATH at build time.
If TCL_PATH hasn't been set yet we can take a better guess about what
tclsh executable to use by replacing 'wish' in the executable path with
'tclsh'. We only do this replacement on the filename part of the path,
just in case the string "wish" appears in the directory paths. Most of
the time the tclsh will be installed alongside wish so this replacement
is a sensible and safe default.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the main window is the only toplevel we have open then we
don't have a valid grab right now, so we need to assume the
best toplevel to use for the parent is ".".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Fix a regression introduced by
1ca3d6e (send-email: squelch warning due to comparing undefined $_ to "")
where if the user was prompted for an initial In-Reply-To and didn't
provide one, messages would be sent out with an invalid In-Reply-To of
"<>"
Also add test cases for the regression and the fix. A small modification
was needed to allow send-email to take its replies from stdin if the
environment variable GIT_SEND_EMAIL_NOTTY is set.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When invalidating unmerged entries in the index, we used to set
their ce_mode to 0 to note the fact that they do not matter
anymore which also made sure that later unpack_trees() call
would not reuse them. Instead just remove them from the index.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we are opening an error dialog we want it to appear above all of
the other windows, even those that we may have opened with a grab
to make the window modal. Failure to do so may allow an error
dialog to open up (and grab focus!) under an existing toplevel,
making the user think git-gui has frozen up and is unresponsive,
as they cannot get to the dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I expected git grep --name-only to give me only the file names,
much as git diff --name-only only generates filenames. Alas the
option is -l, which matches common external greps but doesn't match
other parts of the git UI.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The Solaris regex library doesn't like having the '$' anchor
inside capture parentheses. It rejects the match, causing
t4018 to fail.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fake-editor shell script invoked /bin/sh; normally this
is fine, unless the /bin/sh doesn't meet our compatibility
requirements, as is the case with Solaris. Specifically, the
$() syntax used by fake-editor is not understood.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These functions get called by other code, including parsing
config options from the command line. In that case,
config_file_name is NULL, leading to an ugly message or even
a segfault on some implementations of printf.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-clean simply ignored errors if removing a file or directory failed. This
patch makes it raise a warning and the exit code also greater than zero if
there are remaining files.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/setup:
builtin-mv: minimum fix to avoid losing files
git-add: adjust to the get_pathspec() changes.
Make blame accept absolute paths
setup: sanitize absolute and funny paths in get_pathspec()
* maint:
Clarified the meaning of git-add -u in the documentation
git-clone.sh: properly configure remote even if remote's head is dangling
Documentation/git-stash: document options for git stash list
send-email: squelch warning due to comparing undefined $_ to ""
The git-add documentation did not state clearly that the -u switch
updates only the tracked files that are in the current directory and
its subdirectories.
Signed-off-by: Pekka Kaitaniemi <kaitanie@cc.helsinki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When cloning a remote repository which's HEAD refers to a nonexistent
ref, git-clone cloned all existing refs, but failed to write the
configuration for 'remote'. Now it detects the dangling remote HEAD,
refuses to checkout any local branch since HEAD refers to nowhere, but
properly writes the configuration for 'remote', so that subsequent
'git fetch's don't fail.
The problem was reported by Daniel Jacobowitz through
http://bugs.debian.org/466581
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
