* 'js/diff-ni' (early part):
diff --no-index: also imitate the exit status of diff(1)
Fix typo: do not show name1 when name2 fails
Teach git-diff-files the new option `--no-index`
run_diff_{files,index}(): update calling convention.
update-index: do not die too early in a read-only repository.
git-status: do not be totally useless in a read-only repository.
* maint:
builtin-fmt-merge-msg: fix bugs in --file option
index-pack: Loop over pread until data loading is complete.
blameview: Fix the browse behavior in blameview
Fix minor typos/grammar in user-manual.txt
Correct ordering in git-cvsimport's option documentation
git-show: Reject native ref
Fix git-show man page formatting in the EXAMPLES section
A filesystem might not be able to completely supply our pread
request in one system call, such as if we are reading data from a
network file system and the requested length is just simply huge.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A pair of commits on January 8th added option documentation (for -a,
-S and -L) in the middle of the documentation for the -A option. This
makes -A's documentation contiguous again.
Signed-off-by: Michael Poole <mdpoole@troilus.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
So when we do
git show v1.4.4..v1.5.0
that's an illogical thing to do, since "git show" is defined to be a
non-revision-walking action, which means the range operator be pointless
and wrong. The fact that we happily accept it (and then _only_ show
v1.5.0, which is the positive end of the range) is quite arguably not very
logical.
We should complain, and say that you can only do "no_walk" with positive
refs. Negative object refs really don't make any sense unless you walk
the obejct list (or you're "git diff" and know about ranges explicitly).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The config option gitcvs.allbinary may be set to force all entries to
get the -kb flag.
In the future the gitattributes system will probably be a more
appropriate way of doing this, but that will easily slot in as the
entries lines sent to the CVS client now have their kopts set via the
function kopts_from_path().
In the interim it might be better to not just have a all-or-nothing
approach, but rather detect based on file extension (or file contents?).
That would slot in easily here as well. However, I personally prefer
everything to be binary-safe, so I just switch the switch.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The commithash for updating the ref is obtained from a call to
git-commit-tree. However, it was returned (and stored) with the
trailing newline. This meant that the later call to git-update-ref that
was trying to update to $commithash was including the newline in the
parameter - obviously that hash would never exist, and so git-update-ref
would always fail.
The solution is to chomp() the commithash as soon as it is returned by
git-commit-tree.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes "ci" codepath lockless by following the usual
"remember the tip, do your thing, then compare and swap at the
end" update pattern using update-ref. Incidentally, by updating
the code that reads where the tip of the head is to use
show-ref, it makes it safe to use in a repository whose refs are
pack-pruned.
I noticed that other parts of the program are not yet pack-refs
safe, but tried to keep the changes to the minimum.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix asciidoc markup so that the man page is properly formatted in the
EXAMPLES section.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
git-apply: do not fix whitespaces on context lines.
diff --cc: integer overflow given a 2GB-or-larger file
mailinfo: do not get confused with logical lines that are too long.
Internal function apply_line() is called to copy both context lines
and added lines to the output buffer, while possibly fixing the
whitespace breakages depending on --whitespace=strip settings.
However, it did its fix-up on both context lines and added lines.
This resulted in two symptoms:
(1) The number of lines reported to have been fixed up included
these context lines.
(2) However, the lines actually shown were limited to the added
lines that had whitespace breakages.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Few of us use git to compare or even version-control 2GB files,
but when we do, we'll want it to work.
Reading a recent patch, I noticed two lines like this:
int len = st.st_size;
Instead of "int", that should be "size_t". Otherwise, in the
non-symlink case, with 64-bit size_t, if the file's size is 2GB,
the following xmalloc will fail:
result = xmalloc(len + 1);
trying to allocate 2^64 - 2^31 + 1 bytes (assuming sign-extension
in the int-to-size_t promotion). And even if it didn't fail, the
subsequent "result[len] = 0;" would be equivalent to an unpleasant
"result[-2147483648] = 0;"
The other nearby "int"-declared size variable, sz, should also be of
type size_t, for the same reason. If sz ever wraps around and becomes
negative, xread will corrupt memory _before_ the "result" buffer.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It basically considers all the continuation lines to be lines of their
own, and if the total line is bigger than what we can fit in it, we just
truncate the result rather than stop in the middle and then get confused
when we try to parse the "next" line (which is just the remainder of the
first line).
[jc: added test, and tightened boundary a bit per list discussion.]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
diff sets the exit status to 0 when no changes were found, to 1
when changes were found, and 2 means error.
We imitate this to be able to use "git diff" in the test scripts.
(Actually, keeping in line with the rest of git, -1 is returned
on error, which corresponds to an exit status 255).
To find out if the diff is not empty, a member called
"found_changes" was introduced in struct diff_options, which is
set in builtin_diff() and fn_out_consume().
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* master: (201 commits)
Documentation: link in 1.5.0.2 material to the top documentation page.
Documentation: document remote.<name>.tagopt
GIT 1.5.0.2
git-remote: support remotes with a dot in the name
Documentation: describe "-f/-t/-m" options to "git-remote add"
diff --cc: fix display of symlink conflicts during a merge.
merge-recursive: fix longstanding bug in merging symlinks
merge-index: fix longstanding bug in merging symlinks
diff --cached: give more sensible error message when HEAD is yet to be created.
Update tests to use test-chmtime
Add test-chmtime: a utility to change mtime on files
Add Release Notes to prepare for 1.5.0.2
Allow arbitrary number of arguments to git-pack-objects
rerere: do not deal with symlinks.
rerere: do not skip two conflicted paths next to each other.
Don't modify CREDITS-FILE if it hasn't changed.
diff-patch: Avoid emitting double-slashes in textual patch.
Reword git-am 3-way fallback failure message.
Limit filename for format-patch
core.legacyheaders: Use the description used in RelNotes-1.5.0
...
Update config.txt with info regarding tagopt option
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
GIT 1.5.0.2
git-remote: support remotes with a dot in the name
Documentation: describe "-f/-t/-m" options to "git-remote add"
diff --cc: fix display of symlink conflicts during a merge.
[jc: the original from Pavel was limiting the variable names to only
fetch and url, but I loosened it to take valid variable names.]
[jc: cherry-picked from 'master', since people seem to be reinventing
this many times.]
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
"git-diff-files --cc" to show conflicts during merge did not pass
the correct mode information for the working tree down, and showed
bogus combined diff.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit 3af244ca added unlink(2) before running symlink(2) to
update the working tree with the merge result, but it was
unlinking a wrong path. This resulted in loss of the path
pointed by a symlink.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Ancient commit e2b6a9d0 added code to pass "file modes" from
merge-index to merge-one-file, and then later commit 54dd99a1
wanted to make sure we do not end up creating a nonsense symlink
that points at a path whose name contains conflict markers.
However, nobody noticed that the code in merge-index added by
e2b6a9d0 were stripping the S_IFMT bits and the code in 54dd99a1
was meaningless. This fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is not like the user said 'diff --cached HEAD', so complaining about
HEAD not being a valid commit, while technically might be correct, is
not very helpful.
Signed-off-by: Junio C Hamano <junkio@cox.net>
test-lib:
Make sure test-chmtime has been built before starting.
t4200-rerere:
Removed non-portable date dependency and avoid touch
Avoid "test -a" which isn't portable, either
lib-git-svn:
Use test-chmtime instead of Perl one-liner to poke
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is intended to be a portable replacement for our usage
of date(1), touch(1), and Perl one-liners in tests.
Usage: test-chtime (+|=|-|=+|=-)<seconds> <file>..."
'+' increments the mtime on the files by <seconds>
'-' decrements the mtime on the files by <seconds>
'=' sets the mtime on the file to exactly <seconds>
'=+' and '=-' sets the mtime on the file to <seconds> after or
before the current time.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Add Release Notes to prepare for 1.5.0.2
Allow arbitrary number of arguments to git-pack-objects
rerere: do not deal with symlinks.
rerere: do not skip two conflicted paths next to each other.
Don't modify CREDITS-FILE if it hasn't changed.
If a repository ever gets in a situation where there are too many
packs (more than 60 or so), perhaps because of frequent use of
git-fetch -k or incremental git-repack, then it becomes impossible to
fully repack the repository with git-repack -a. That command just
dies with the cryptic message
fatal: too many internal rev-list options
This message comes from git-pack-objects, which is passed one command
line option like --unpacked=pack-<SHA1>.pack for each pack file to be
repacked. However, the current code has a static limit of 64 command
line arguments and just aborts if more arguments are passed to it.
Fix this by dynamically allocating the array of command line
arguments, and doubling the size each time it overflows.
Signed-off-by: Roland Dreier <roland@digitalvampire.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We should always avoid rewriting a built file during `make install`
if nothing has changed since `make all`. This is to help support
the typical installation process of compiling a package as yourself,
then installing it as root.
Forcing CREDITS-FILE to be always be rebuilt in the Makefile means
that CREDITS-GEN needs to check for a change and only update
CREDITS-FILE if the file content actually differs. After all,
content is king in Git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* 'jc/status' (early part):
run_diff_{files,index}(): update calling convention.
update-index: do not die too early in a read-only repository.
git-status: do not be totally useless in a read-only repository.
This is to resolve semantic conflict (which is not textual) that
changes the calling convention of run_diff_files() early.
* maint:
diff-patch: Avoid emitting double-slashes in textual patch.
Reword git-am 3-way fallback failure message.
Limit filename for format-patch
core.legacyheaders: Use the description used in RelNotes-1.5.0
git-show-ref --verify: Fail if called without a reference
Conflicts:
builtin-show-ref.c
diff.c
When the blobs recorded on the index lines in the patch as pre-image
blobs are not found in the repository, "git-am" punted saying
that the index line does not record anything useful. This was not
clear enough -- the index line does have something useful but the
problem was that it was not useful in _that_ repository.
Reword the message as Francis Moreau suggests.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Badly formatted commits may have very long comments. This causes
git-format-patch to fail. To avoid that, truncate the filename
to a value we believe will always work.
Err out if the patch file cannot be created.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
