The code forgot to convert the blob contents into work tree
representation before writing it out. Also fixes leaks -- earlier
the updated blobs were never freed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you work on a repo with core.autocrlf == true, you would expect
every text file to have CRLF EOLs. However, if you by some operation,
get a conflict, then the conflicted file has LF EOLs.
Now, of course you'd go about resolving the files conflict, and then 'git
add <file>'. When you do that, you'll get the warning saying that LF will
be replaced by CRLF. Then you commit. The end result is that you have a
workingdir with a mix of LF and CRLF files, which after some more
operations may trigger a "whole file changed" diff, due to the workingdir
file now having LF EOLs.
An LF only conflict file results in the resolved file being in LF,
the commit is in LF and a warning saying that LF will be replaced
by CRLF, and the working dir ends up with a mix of CRLF and LF files.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, cat-file --batch / --batch-check would silently exit if it
was passed a non-existent SHA1 on stdin. Now it prints "<SHA1>
missing" as in all other cases (and as advertised in the
documentation).
Note that cat-file --batch-check (but not --batch) will still output
"error: unable to find <SHA1>" on stderr if a non-existent SHA1 is
passed, but this does not affect parsing its stdout.
Also, type <= 0 was previously using the potentially uninitialized
type variable (relying on it being 0); it is now being initialized.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously timestamps were removed unconditionally (though this didn't
seem to break this test). Now they are only removed if $no_ts is
non-empty.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The <pattern> given "git describe --match" was used only to filter tag
objects, and not to filter lightweight tags. This fixes it.
[jc: made the log to clarify this is a bugfix, not an enhancement, with
additional test]
Signed-off-by: Michael Dressel <MichaelTiloDressel@t-online.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The double slashes "//" result from url./$TRASH/. expansion and the
current directory, which even in cygwin contains "/" as first
character. In cygwin such strings have special meaning: UNC path.
Accessing an UNC path built for test purpose usually fails.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
One particular test wants to check the behaviour of the command
when these variables are not set, but the later tests should have
the reliable committer identity for repeatable tests.
Move the "unset" of the variables inside a subshell in the test
that wants to unset them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The scripted version of git-commit internally used git-commit-tree which
omitted duplicated parents given from the command line. This prevented a
nonsensical octopus merge from getting created even when you said "git
merge A B" while you are already on branch A.
However, when git-commit was rewritten in C, this sanity check was lost.
This resurrects it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A remote may be configured to fetch into tracking branches that
do not match the remote name. For example a user may have created
extra remotes that will fetch to the same tracking branch namespace,
but from different URLs:
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = refs/heads/*:refs/remotes/origin/*
[remote "alt"]
url = git://repo.or.cz/alt-git.git
fetch = refs/heads/*:refs/remotes/origin/*
When running `git remote prune alt` we expect stale branches to
be removed from "refs/remotes/origin/*" and not from the unused
namespace of "refs/remotes/alt/*".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this, some tests will fail because they compare command output
of subprocesses (such as git) with $PWD -- but subprocesses have the
physical path as their working directory, whereas $PWD contains the
symlinked path. This fixes it.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch moves the am test cases in t4150-am.sh and the
am subdirectory test cases from t/t4150-am-subdir.sh into
t/4151-am.sh.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add t/t4151-am.sh that does basic testing of git-am functionality,
including:
* am applies patch correctly
* am changes committer and keeps author
* am --signoff adds Signed-off-by: line
* am stays in branch
* am --signoff does not add Signed-off-by: line if already there
* am without --keep removes Re: and [PATCH] stuff
* am --keep really keeps the subject
* am -3 falls back to 3-way merge
* am pauses on conflict
* am --skip works
* am --resolved works
* am takes patches from a Pine mailbox
* am fails on mail without patch
* am fails on empty patch
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Other signals are also common, for example SIGTERM and SIGHUP.
This patch modifies the lock file mechanism to catch more signals.
It also modifies http-push.c which was missing SIGTERM.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is unfortunate that "git init --bare" does not work and the only reason
why "init" did not learn its own "--bare" option is because "git --bare
init" already does the job (and as an option to the git 'potty', it is
more generic solution).
This teaches "git init" its own "--bare" option, so that both "git --bare init"
and "git init --bare" works mostly the same way.
[jc: rewrote the log message and added test]
Signed-off-by: Luciano Rocha <strange@nsk.pt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sync with builtin-fetch--tool.c where append_fetch_head()
honors update_local_ref() return value.
This fixes non fast forward fetch exit status,
http://bugzilla.altlinux.org/show_bug.cgi?id=15037
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are broken filesystems that cannot have a file whose name is "nul"
anywhere on it. Rename the test file to make ourselves more portable.
Noticed by Mark Levedahl.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit cfabd6eee1. I had
implemented it without understanding what --full-history does. Consider
this history:
C--M--N
/ / /
A--B /
\ /
D-/
where B and C modify a path, X, in the same way so that the result is
identical, and D does not modify it at all. With the path limiter X and
without --full-history this is simplified to
A--B
i.e. only one of the paths via B or C is chosen. I had assumed that
--full-history would keep both paths like this
C--M
/ /
A--B
removing the path via D; but in fact it keeps the entire history.
Currently, git does not have the capability to simplify to this
intermediary case. However, the other extreme to keep the entire history
is not wanted either in usual cases. I think we can expect that histories
like the above are rare, and in the usual cases we want a simplified
history. So let's remove --full-history again.
(Concerning t7003, subsequent tests depend on what the test case sets up,
so we can't just back out the entire test case.)
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function fgets() has a big problem with NUL characters: it reads
them, but nobody will know if the NUL comes from the file stream, or
was appended at the end of the line.
So implement a custom read_line_with_nul() function.
Noticed by Tommy Thorn.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even if "foo" and/or "bar" does not exist in index, "git diff foo bar"
should not change behaviour drastically from "git diff foo bar baz" or
"git diff foo". A feature that "sometimes works and is handy" is an
unreliable cute hack.
"git diff foo bar" outside a git repository continues to work as a more
colourful alternative to "diff -u" as before.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As a general principle, we should not use "git diff" to validate the
results of what git command that is being tested has done. We would not
know if we are testing the command in question, or locating a bug in the
cute hack of "git diff --no-index".
Rather use test_cmp for that purpose.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a more appropriate location according to t/README.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The first test in this series tests "git clone -l -s --reference B A C",
where repo B is a superset of repo A (A has one commit, B has the same
commit plus another). In this case, all objects to be cloned are already
present in B.
However, we should also test the case where the "--reference" repo is a
_subset_ of the source repo (e.g. "git clone -l -s --reference A B C"),
i.e. some objects are not available in the "--reference" repo, and will
have to be found in the source repo.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In this case, the reference repository has some useful loose objects,
but not all useful objects, and we make sure that we can find the
objects we fetch from the repository we're cloning in the new
repository, instead of potentially being distracted by the reference
repository.
Doing the wrong thing in a builtin-clone implementation would lead to
this looking for an object in the wrong place, not finding it (because
it's only in the right place), and crashing.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When rebasing fails during "pull --rebase", you cannot just clean up the
working directory and call "pull --rebase" again, since the remote branch
was already fetched.
Therefore, die early when the working directory is dirty.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git bisect" was first written, it was not possible to
checkout a detached HEAD. The detached feature appeared latter.
That's why before this patch the "git bisect" process used a
"bisect" branch to checkout new revisions to be tested (and also
a "new-bisect" one to check if the checkouts could work).
This patch makes "git bisect" checkout revisions to be tested on
a detached HEAD. This simplifies the code a bit.
The tests to check that "git bisect" does not start if a
"bisect" or a "new-bisect" branch exists are removed as they
are not relevant any more.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before this patch, when using "git bisect start" with mistaken revs
or when the checkout of the branch we want to test failed, we exited
after having written files like ".git/BISECT_START",
".git/BISECT_NAMES" and after having written "refs/bisect/bad" and
"refs/bisect/good-*" refs.
With this patch we trap all errors that can happen when writing the
new state and when we are in "bisect_next". So that we can try to
clean up everything in case of problems, using "bisect_clean_state".
This patch also contains a "bisect_write" cleanup to make it exit
on error and return 0 otherwise.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before this patch, when using for example:
$ git bisect start <stuff1> <stuff2>
with <stuff1> or <stuff2> that cannot be parsed as a revision, we
could leave a ".git/BISECT_START" file, from a previous
"git bisect start", alone.
This patch makes sure that it does not happen by removing the
"BISECT_START" file in "bisect_clean_state" and then always writing
it again at the end of "bisect_start".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch adds some test cases to check that "git bisect start"
doesn't leave us in a bad state, especially when it fails.
These test cases show that "git bisect start" is not atomic when it
fails and leave some files like .git/BISECT_START, and in some
cases some refs, over.
The test failures should be fixed in latter commits.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We always use 'utf-8' as the encoding, since we currently
have no way of getting the information from the user.
This also refactors the quoting of recipient names, since
both processes can share the rfc2047 quoting code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the compose message contains non-ascii characters, then
we assume it is in utf-8 and include the appropriate MIME
headers. If the user has already included a MIME-Version
header, then we assume they know what they are doing and
don't add any headers.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The point of the test is not really to test the ability of the
filesystem to keep the given x-bit, but to check is merge-recursive
correctly handles it.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Exit with error if cd into the "trash directory" failed (error
already reported, so just exit).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we see no context nor deleted line in the patch, we used to declare
that the patch creates a new file. But some people create an empty file
and then apply a patch to it. Similarly, a patch that delete everything
is not a deletion patch either.
This commit corrects these two issues. Together with the previous commit,
it allows a diff between an empty file and a line-ful file to be treated
as both creation patch and "add stuff to an existing empty file",
depending on the context. A new test t4126 demonstrates the fix.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On a case sensitive filesystem, "git reset --hard" might refuse to
overwrite a file whose name differs only by case, even if
core.ignorecase is set. It is not clear which circumstances cause this
behavior. This commit simply works around the problem by removing
the case changing file before running "git reset --hard".
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The in-place mode of sed used in t7502-commit is a non-POSIX extension.
That call of sed is replaced by a more portable version using a temporary file.
Signed-off-by: Marcel Koeppen <git-dev@marzelpan.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a submodule is not initialized and you do not want to change the
defaults from .gitmodules anyway, you can now say
$ git submodule update --init <name>
When "update" is called without --init on an uninitialized submodule,
a hint to use --init is printed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If "gitcvs.allbinary" is set to "guess", then any file that has
not been explicitly marked as binary or text using the "crlf" attribute
and the "gitcvs.usecrlfattr" config will guess binary based on the contents
of the file.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If gitcvs.usecrlfattr is set to true, git-cvsserver will consult
the "crlf" for each file to determine if it should mark the file
as binary (-kb).
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Johannes Schindelin