Unpacked objects should receive the timestamp of the pack they were
unpacked from. Check.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Once a clone is successful we no longer need to hold onto the
.keep file created by the transport. Delete the file so we
can later repack the complete repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the user specifies a ref by a reflog entry older than
one we have (e.g., "HEAD@{20 years ago"}), we issue a
warning and give them the "from" value of the oldest reflog
entry. That is, we say "we don't know what happened before
this entry, but before this we know we had some particular
SHA1".
However, the oldest reflog entry is often a creation event
such as clone or branch creation. In this case, the entry
claims that the ref went from "00000..." (the null sha1) to
the new value, and the reflog lookup returns the null sha1.
While this is technically correct (the entry tells us that
the ref didn't exist at the specified time) it is not
terribly useful to the end user. What they probably want
instead is "the oldest useful sha1 that this ref ever had".
This patch changes the behavior such that if the oldest ref
would return the null sha1, it instead returns the first
value the ref ever had.
We never discovered this problem in the test scripts because
we created "fake" reflogs that had only a specified segment
of history. This patch updates the tests with a creation
event at the beginning of history.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If git attempts to delete a ref, but the unlink of the ref
file fails, we print a message to stderr. This is usually a
good thing, but if the error is ENOENT, then it indicates
that the ref has _already_ been deleted. And since that's
our goal, it doesn't make sense to complain to the user.
This harmonizes the error reporting behavior for the
unpacked and packed cases; the packed case already printed
nothing on ENOENT, but the unpacked printed unconditionally.
Additionally, send-pack would, when deleting the tracking
ref corresponding to a remote delete, print "Failed to
delete" on any failure. This can be a misleading
message, since we actually _did_ delete at the remote side,
but we failed to delete locally. Rather than make the
message more precise, let's just eliminate it entirely; the
delete_ref routine already takes care of printing out a much
more specific message about what went wrong.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A root commit couldn't be cherry-picked. But its semantics can be
defined as simply merging two trees by overlaying disjoint parts
and merging overlapping files without any common ancestor. You
should be able to rebase originally independent branches on top of
another branch by using this.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* dr/ceiling:
Eliminate an unnecessary chdir("..")
Add support for GIT_CEILING_DIRECTORIES
Fold test-absolute-path into test-path-utils
Implement normalize_absolute_path
Conflicts:
cache.h
setup.c
Make sure that applying the stash to a new branch after a conflicting
change doesn't result in an error when you try to commit.
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Applying a patch in the directory that is different from what the patch
records is done with --directory option in GNU diff. The --root option we
introduced previously does the same, and we can call it the same way to
give users more familiar feel.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test failed on AIX (and likely other OS, such as apparently OSX)
where wc -l outputs whitespace.
Also, avoid unnecessary eval in conflict_count().
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There was no test for this before, so the testsuite passed, even in case
the merge summary was missing from the merge commit message.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a patch modifies the last line of a file that previously had no
terminating '\n', it looks like
-old text
\ No newline at end of file
+new text
Hence, a '\' line does not signal the end of the hunk. This modifies
'git apply --recount' to take this into account.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When left-right traversal counts the commits in a diverged history, it
leaves the flags in the commits smudged, and we need to clear them before
we return. Otherwise the caller cannot inspect other branches with this
function again.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we match a lightweight (non-annotated tag) as the name to
output and --long was requested we do not have a tag, nor do
we have a tagged object to display. Instead we must use the
object we were passed as input for the long format display.
Reported-by: Mark Burton <markb@ordern.com>
Backtraced-by: Mikael Magnusson <mikachu@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adds a new option 'e' to the 'add -p' command loop that lets you edit
the current hunk in your favourite editor.
If the resulting patch applies cleanly, the edited hunk will
immediately be marked for staging. If it does not apply cleanly, you
will be given an opportunity to edit again. If all lines of the hunk
are removed, then the edit is aborted and the hunk is left unchanged.
Applying the changed hunk(s) relies on Johannes Schindelin's new
--recount option for git-apply.
Note that the "real patch" test intentionally uses
(echo e; echo n; echo d) | git add -p
even though the 'n' and 'd' are superfluous at first sight. They
serve to get out of the interaction loop if git add -p wrongly
concludes the patch does not apply.
Many thanks to Jeff King <peff@peff.net> for lots of help and
suggestions.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The end of a string is string[length-1], not string[length+1].
I pointed it out during the review, but I forgot about it when applying the
patch. This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With "git apply --root=<root>", all file names in the patch are prepended
with <root>. If a "-p" value was given, the paths are stripped _before_
prepending <root>.
Wished for by HPA.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/checkdiff:
Fix t4017-diff-retval for white-space from wc
Update sample pre-commit hook to use "diff --check"
diff --check: detect leftover conflict markers
Teach "diff --check" about new blank lines at end
checkdiff: pass diff_options to the callback
check_and_emit_line(): rename and refactor
diff --check: explain why we do not care whether old side is binary
The old shell version used show-branch --independent to filter for the
ones that cannot be reached from any other reference.
The new C version uses reduce_heads() from commit.c for this, so
add test to ensure it works as expected.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old shell version handled only 25 refs but we no longer have this
limitation. Add a test to make sure this limitation will not be
introduced again in the future.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test if the given strategies are used and test the case when multiple
strategies are configured using a space separated list.
Also test if the best strategy is picked if none is specified. This is
done by adding a simple test case where recursive detects a rename, but
resolve does not, and verify that finally merge will pick up the
previous.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We don't need test results to be committed if we're fixing a test.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sometimes, the easiest way to fix up a patch is to edit it directly, even
adding or deleting lines. Now, many people are not as divine as certain
benevolent dictators as to update the hunk headers correctly at the first
try.
So teach the tool to do it for us.
[jc: with tests]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When working with a lot of people who backport patches all day long, every
once in a while I get a patch that modifies the same file more than once
inside the same patch. git-apply either fails if the second change relies
on the first change or silently drops the first change if the second change
is independent.
The silent part is the scary scenario for us. Also this behaviour is
different from the patch-utils.
I have modified git-apply to create a table of the filenames of files it
modifies such that if a later patch chunk modifies a file in the table it
will buffer the previously changed file instead of reading the original file
from disk.
Logic has been put in to handle creations/deletions/renames/copies. All the
relevant tests of git-apply succeed.
A new test has been added to cover the cases I addressed.
The fix is relatively straight-forward.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches "diff --check" to detect and complain if the change
adds lines that look like leftover conflict markers.
We should be able to remove the old Perl script used in the sample
pre-commit hook and modernize the script with this facility.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a patch adds new blank lines at the end, "git apply --whitespace"
warns. This teaches "diff --check" to do the same.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git diff --check" should return non-zero when there was any whitespace
error but the code only paid attention to the error status of the last
new line in the patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, we did a sanity check by doing for-each-ref
using each possible format atom. However, we never checked
the actual output produced by that atom, which recently let
an obvious bug go undetected for some time.
While we're at it, also clean up a few '!' into
test_must_fail.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Resetting a selected set of index entries is done with
"git reset -- paths" syntax, but we did not allow -- to be omitted
even when the command is unambiguous.
This updates the command to follow the general rule:
* When -- appears, revs come before it, and paths come after it;
* When there is no --, earlier ones are revs and the rest are paths, and
we need to guess. When lack of -- marker forces us to guess, we
protect from user errors and typoes by making sure what we treat as
revs do not appear as filenames in the work tree, and what we treat as
paths do appear as filenames in the work tree, and by erroring out if
that is not the case. We tell the user to disambiguate by using -- in
such a case.
which is employed elsewhere in the system.
When this rule is applied to "reset", because we can have only zero or one
rev to the command, the check can be slightly simpler than other programs.
We have to check only the first one or two tokens after the command name
and options, and when they are:
-- A:
no explicit rev given; "A" and whatever follows it are paths.
A --:
explicit rev "A" given and whatever follows the "--" are paths.
A B:
"A" could be rev or path and we need to guess. "B" could
be missing but if exists that (and everything that follows) would
be paths.
So we apply the guess only in the last case and only to "A" (not "B" and
what comes after it).
* As long as "A" is unambiguously a path, index entries for "A", "B" (and
everything that follows) are reset to the HEAD revision.
* If "A" is unambiguously a rev, on the other hand, the index entries for
"B" (and everything that follows) are reset to the "A" revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The perldiag(1) has following to say about this:
"Can't do inplace edit without backup"
(F) You're on a system such as MS-DOS that gets confused if
you try reading from a deleted (but still opened) file. You
have to say -i.bak, or some such.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sr/tests:
Hook up the result aggregation in the test makefile.
A simple script to parse the results from the testcases
Modify test-lib.sh to output stats to t/test-results/*
Conflicts:
t/test-lib.sh
* jh/clone-packed-refs:
Teach "git clone" to pack refs
Prepare testsuite for a "git clone" that packs refs
Move pack_refs() and friends into libgit
Incorporate fetched packs in future object traversal
The shell version used to use "mkdir -p" to create the repo
path, but the C version just calls "mkdir". Let's replicate
the old behavior. We have to create the git and worktree
leading dirs separately; while most of the time, the
worktree dir contains the git dir (as .git), the user can
override this using GIT_WORK_TREE.
We can reuse safe_create_leading_directories, but we need to
make a copy of our const buffer to do so. Since
merge-recursive uses the same pattern, we can factor this
out into a global function. This has two other cleanup
advantages for merge-recursive:
1. mkdir_p wasn't a very good name. "mkdir -p foo/bar" actually
creates bar, but this function just creates the leading
directories.
2. mkdir_p took a mode argument, but it was completely
ignored.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The shell version used to use "mkdir -p" to create the repo
path, but the C version just calls "mkdir". Let's replicate
the old behavior. We have to create the git and worktree
leading dirs separately; while most of the time, the
worktree dir contains the git dir (as .git), the user can
override this using GIT_WORK_TREE.
We can reuse safe_create_leading_directories, but we need to
make a copy of our const buffer to do so. Since
merge-recursive uses the same pattern, we can factor this
out into a global function. This has two other cleanup
advantages for merge-recursive:
1. mkdir_p wasn't a very good name. "mkdir -p foo/bar" actually
creates bar, but this function just creates the leading
directories.
2. mkdir_p took a mode argument, but it was completely
ignored.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Suppose someone fetches git-svn-ified commits from another repo and then
attempts to use 'git-svn init --rewrite-root=foo bar'. Using git svn rebase
after that will fail badly:
* For each commit tried by working_head_info, rebuild is called indirectly.
* rebuild will iterate over all commits and skip all of them because the
URL does not match. Because of that no rev_map file is generated at all.
* Thus, rebuild will run once for every commit. This takes ages.
* In the end there still isn't any rev_map file and thus working_head_info
fails.
Addressing this behaviour fixes an apparently not too uncommon problem with
providing git-svn mirrors of Subversion repositories. Some repositories are
accessed using different URLs depending on whether the user has push
privileges or not. In the latter case, an anonymous URL is often used that
differs from the push URL. Providing a mirror that is usable in both cases
becomes a lot more possible with this change.
Signed-off-by: Jan Krüger <jk@jk.gs>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Extend parse-options test suite
api-parse-options.txt: Introduce documentation for parse options API
parse-options.c: fix documentation syntax of optional arguments
api-builtin.txt: update and fix typo
This patch serves two purposes:
1. test-parse-option.c should be a more complete
example for the parse-options API, and
2. there have been no tests for OPT_CALLBACK,
OPT_DATE, OPT_BIT, OPT_SET_INT and OPT_SET_PTR
before.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When an argument for an option is optional, short options don't need a
space between the option and the argument, and long options need a "=".
Otherwise, arguments are misinterpreted.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/test:
enable whitespace checking of test scripts
avoid trailing whitespace in zero-change diffstat lines
avoid whitespace on empty line in automatic usage message
mask necessary whitespace policy violations in test scripts
fix whitespace violations in test scripts
The test used "diff-files -q" which is not about reporting if there is
a difference at all. Instead, make sure that the path remains as
conflicting in the index after rerere autoresolves it, as we will be
adding rerere.autoupdate configuration with the next patch.
Add description of GIT_SKIP_TESTS variable, taken almost verbatim
(adjusting for conventions in t/README) from the commit message in
04ece59 (GIT_SKIP_TESTS: allow users to omit tests that are known to break)
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the arguments to test_must_fail() begin with a variable assignment,
test_must_fail() attempts to execute the variable assignment as a command.
This fails, and so test_must_fail returns with a successful status value
without running the command it was intended to test.
For example, the following script:
#!/bin/sh
test_must_fail () {
"$@"
test $? -gt 0 -a $? -le 129
}
foo='wo adrian'
test_must_fail foo='yo adrian' sh -c 'echo foo: $foo'
always exits zero and prints the message:
test.sh: line 3: foo=yo adrian: command not found
Test 16 calls test_must_fail in such a way and therefore has not been
testing whether git 'do[es] not fire editor in the presence of conflicts'.
A workaround is to set and export the variable in a normal way, not
using one-shot notation. Because this would affect the remainder of
the process, the test is done inside a subshell.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5515-fetch-merge-logic removes many, but not all, refs between each test.
This is done by removing the corresponding refs/foo/* files in the .git/refs
hierarchy. However, once "git clone" starts producing packed refs, these refs
will no longer be in the .git/refs hierarchy, but rather listed in
.git/packed-refs. This patch teaches t5515-fetch-merge-logic to remove the
refs using "git update-ref -d" which properly handles packed refs.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds the --import-marks and --export-marks to fast-export. These import
and export the marks used to for all revisions exported in a similar fashion
to what fast-import does. The format is the same as fast-import, so you can
create a bidirectional importer / exporter by using the same marks file on
both sides.
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a shell script (t/t9700-perl-git.sh) that sets up a git repository
and a perl script (t/t9700/test.pl) that runs the actual tests.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is for running external test scripts in other programming
languages that provide continuous output about their tests. Using
test_expect_success (like "test_expect_success 'description' 'perl
test-script.pl'") doesn't suffice here because test_expect_success
eats stdout in non-verbose mode, which is not fixable without major
file descriptor trickery.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a --long-tests option to test-lib.sh, which enables tests to
selectively run more exhaustive (longer running, potentially
brute-force) tests. Such exhaustive tests would only be useful if one
works on the specific module that is being tested -- for a general "cd
t/; make" to check whether everything is OK, such exhaustive tests
shouldn't be run by default since the longer it takes to run the
tests, the less often they are actually run.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
match_explicit is called for each push refspec to try to
fully resolve the source and destination sides of the
refspec. Currently, we look at each refspec and report
errors on both the source and the dest side before aborting.
It makes sense to report errors for each refspec, since an
error in one is independent of an error in the other.
However, reporting errors on the 'dst' side of a refspec if
there has been an error on the 'src' side does not
necessarily make sense, since the interpretation of the
'dst' side depends on the 'src' side (for example, when
creating a new unqualified remote ref, we use the same type
as the src ref).
This patch lets match_explicit return early when the src
side of the refspec is bogus. We still look at all of the
refspecs before aborting the push, though.
At the same time, we clean up the call signature, which
previously took an extra "errs" flag. This was pointless, as
we didn't act on that flag, but rather just passed it back
to the caller. Instead, we now use the more traditional
"return -1" to signal an error, and the caller aggregates
the error count.
This change fixes two bugs, as well:
- the early return avoids a segfault when passing a NULL
matched_src to guess_ref()
- the check for multiple sources pointing to a single dest
aborted if the "err" flag was set. Presumably the intent
was not to bother with the check if we had no
matched_src. However, since the err flag was passed in
from the caller, we might abort the check just because a
previous refspec had a problem, which doesn't make
sense.
In practice, this didn't matter, since due to the error
flag we end up aborting the push anyway.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Improve the git-svn-author test to check that extra newlines aren't inserted
into commit messages as they take a round trip from git to svn and back.
We test both with and without the --add-author-from option to git-svn.
git-svn: test that svn repo doesn't have extra newlines.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that all of the policy violations have been cleaned up,
we can turn this on and start checking incoming patches.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In some cases, we produce a diffstat line even though no
lines have changed (e.g., because of an exact rename). In
this case, there is no +/- "graph" after the number of
changed lines. However, we output the space separator
unconditionally, meaning that these lines contained a
trailing space character.
This isn't a huge problem, but in cleaning up the output we
are able to eliminate some trailing whitespace from a test
vector.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When outputting a usage message with a blank line in the
header, we would output a line with four spaces. Make this
truly a blank line.
This helps us remove trailing whitespace from a test vector.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All of these violations are necessary parts of the tests
(which are generally checking the behavior of trailing
whitespace, or contain diff fragments with empty lines).
Our solution is two-fold:
1. Process input with whitespace problems using tr. This
has the added bonus that it becomes very obvious where
the bogus whitespace is intended to go.
2. Move large diff fragments into their own supplemental
files. This gets rid of the whitespace problem, since
supplemental files are not checked, and it also makes
the test script a bit easier to read.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These violations are simply wrong, but were never caught
because whitespace policy checking is turned off in the test
scripts.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test did "reset --hard" (where the HEAD commit has an empty
blob at path "empty") followed by "> empty", expecting that
the index does not notice the file _changed_ since git wrote
it out upon "reset" if the redirection is done quickly enough.
There was no need to do the emptying, and it gave a wrong result
if "reset --hard" happened on time T and then ">empty" happened on
the next second T+1. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* om/remote-fix:
"remote prune": be quiet when there is nothing to prune
remote show: list tracked remote branches with -n
remote prune: print the list of pruned branches
builtin-remote: split show_or_prune() in two separate functions
remote show: fix the -n option
Only ignore whitespace errors in t/tNNNN-*.sh and the t/tNNNN
subdirectories. Other files (like test libraries) should still be
checked.
Also fix a whitespace error in t/test-lib.sh.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This command is really too quiet which make it unconfortable to use.
Also implement a --dry-run option, in place of the original -n one, to
list stale tracking branches that will be pruned, but do not actually
prune them.
Add a test case for --dry-run.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The perl version accepted a -n flag, to show local informations only
without querying remote heads, that seems to have been lost in the C
revrite.
This restores the older behaviour and add a test case.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
This new argument teaches Git to not look for any untracked files,
saving cycles on slow file systems, or large repos.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
This lets you specify how you want untracked files to be listed.
The possible options are:
normal - Show untracked files and directories
all - Show all untracked files
The 'all' mode is used, if the mode is not specified.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.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>
Attributes can be specified at three different places: the internal
table of default values, the file $GIT_DIR/info/attributes and files
named .gitattributes in the work tree. Since bare repositories don't
have a work tree, git should ignore any .gitattributes files there.
This patch makes git do that, so the only way left for a user to specify
attributes in a bare repository is the file info/attributes (in addition
to changing the defaults and recompiling).
In addition, git-check-attr is now allowed to run without a work tree.
Like any user of the code in attr.c, it ignores the .gitattributes files
when run in a bare repository. It can still read from info/attributes.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Paths marked with this attribute are not output to git-archive
output.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
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>
This patch makes 'make' output the aggregated results at the end of each build.
The 'git-test-result' file is removed both before and after each build.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
