The copyfrom_data instruction copies a few bytes verbatim from the
novel text section of a window to the postimage.
[jn: with memory leak fix from David]
Improved-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Ramkumar Ramachandra <artagnon@gmail.com>
Buffer the instruction section upon encountering it for later
interpretation.
An alternative design would involve parsing the instructions
at this point and buffering them in some processed form. Using
the unprocessed form is simpler.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Ramkumar Ramachandra <artagnon@gmail.com>
Each window of an svndiff0-format delta includes a section for novel
text to be copied to the postimage (in the order it appears in the
window, possibly interspersed with other data).
Slurp in this data when encountering it. It is not actually necessary
to do so --- it would be just as easy to copy from delta to output
as part of interpreting the relevant instructions --- but this way,
the code that interprets svndiff0 instructions can proceed very
quickly because it does not require I/O.
Subversion's svndiff0 parser rejects deltas that do not consume all
the novel text that was provided. Omit that check for now so we can
test the new functionality right away, rather than waiting to learn
instructions that consume data.
Do check for truncated data sections. Subversion's parser rejects
deltas that end in the middle of a declared novel-text section, so it
should be safe for us to reject them, too.
Improved-by: Ramkumar Ramachandra <artagnon@gmail.com>
Improved-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Ramkumar Ramachandra <artagnon@gmail.com>
The source view offset heading each svndiff0 window represents a
number of bytes past the beginning of the preimage. Together with the
source view length, it dictates to the delta applier what portion of
the preimage instructions will refer to. Read that portion right away
using the sliding window code.
Maybe some day we will use mmap to read data more lazily.
Subversion's implementation tolerates source view offsets pointing
past the end of the preimage file but we do not, for simplicity.
This does not teach the delta applier to read instructions or copy
data from the source view. Deltas that could produce nonempty output
will still be rejected.
Improved-by: Ramkumar Ramachandra <artagnon@gmail.com>
Improved-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Ramkumar Ramachandra <artagnon@gmail.com>
Each window in a subversion delta (svndiff0-format file) starts with a
window header, consisting of five integers with variable-length
representation:
source view offset
source view length
output length
instructions length
auxiliary data length
Parse it. The result is not usable for deltas with nonempty postimage
yet; in fact, this only adds support for deltas without any
instructions or auxiliary data. This is a good place to stop, though,
since that little support lets us add some simple passing tests
concerning error handling to the test suite.
Improved-by: Ramkumar Ramachandra <artagnon@gmail.com>
Improved-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
A delta in the subversion delta (svndiff0) format consists of the
magic bytes SVN\0 followed by a sequence of windows of a certain well
specified format (starting with five integers).
Add an svndiff0_apply function and test-svn-fe -d commandline tool to
parse such a delta in the special case of not including any windows.
Later patches will add features to turn this into a fully functional
delta applier for svn-fe to use to parse the streams produced by
"svnrdump dump" and "svnadmin dump --deltas".
The content of symlinks starts with the word "link " in Subversion's
worldview, so we need to be able to prepend that text to input for the
sake of delta application. So initialization of the input state of
the delta preimage is left to the calling program, giving callers a
chance to seed the buffer with text of their choice.
Improved-by: Ramkumar Ramachandra <artagnon@gmail.com>
Improved-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
* mg/rev-list-n-parents:
tests: avoid nonportable {foo,bar} glob
rev-list --min-parents,--max-parents: doc, test and completion
revision.c: introduce --min-parents and --max-parents options
t6009: use test_commit() from test-lib.sh
* 'svn-fe' of git://repo.or.cz/git/jrn:
vcs-svn: handle log message with embedded NUL
vcs-svn: avoid unnecessary copying of log message and author
vcs-svn: remove buffer_read_string
vcs-svn: make reading of properties binary-safe
Pass the log message by strbuf instead of as a C-style string and use
fwrite instead of printf to write it to fast-import so embedded '\0'
bytes can be preserved.
Currently "git log" doesn't show the embedded NULs but "git cat-file
commit" can.
While at it, stop including system headers from repo_tree.h. git
source files need to include git-compat-util.h (or cache.h or
builtin.h) sooner to ensure the appropriate feature test macros are
defined.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
All previous users of buffer_read_string have already been converted
to use the more intuitive buffer_read_binary, so remove the old API to
avoid some confusion.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
svn-fe errors out on revision 59151 of the ASF repository:
fatal: invalid dump: unexpected end of file
The proximate cause is a property with an embedded NUL character.
Previously such anomalies were ignored but commit c9d1c8ba
(2010-12-28) introduced a check strlen(val) == len to avoid reading
uninitialized data when a property list ends early and unfortunately
this test does not distinguish between "foo" followed by EOF and the
string "foo\0bar\0baz".
Fix it by using buffer_read_binary to read to a strbuf and checking
the actual length read. Most consumers of properties still use
C-style strings, so in practice an author or log message with embedded
NULs will be truncated, but a least this way svn-fe won't error out
(fixing the regression).
Reported-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
For a pull into an unborn branch, we do not use "git merge"
at all. Instead, we call read-tree directly. However, we
used the --reset parameter instead of "-m", which turns off
the safety features.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we merge into an unborn branch, there are basically two
steps:
1. Write the sha1 of the new commit into the ref pointed
to by HEAD.
2. Update the index with the new content, and check it out
to the working tree.
We currently do them in this order. However, (2) is the step
that is much more likely to fail, since it can be blocked by
things like untracked working tree files. When it does, the
merge fails and we are left with an empty index but an
updated HEAD.
This patch switches the order, so that a failure in updating
the index leaves us unchanged. Of course, a failure in
updating the ref now leaves us with an updated index and
mis-matched HEAD. That is arguably not much better, but it
is probably less likely to actually happen.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This file ends up conflicting with the test just after it
(causing the "git merge" to fail). Neither test is to blame
for the bug, though. It looks like the merge in 1a9fe45
(Merge branch 'tr/merge-unborn-clobber', 2011-02-09) is what
caused the conflict.
We didn't notice because the follow-on test is already
marked as expect_failure (even though it has since been
fixed, and now succeeds once the untracked file is moved out
of the way).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This was fixed by 1d718a51 (do not overwrite untracked
symlinks, 2011-02-20).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch changes behavior of the two functions. Previously it does
prefix matching only. Now it can also do wildcard matching.
All callers are updated. Some gain wildcard matching (archive,
checkout), others reset pathspec_item.has_wildcard to retain old
behavior (ls-files, ls-tree as they are plumbing).
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unlike bash and ksh, dash and busybox ash do not support brace
expansion (as in 'echo {hello,world}'). So when dash is sh,
t6009.13 (set up dodecapus) ends up pass a string beginning with
"root{1,2," to "git merge" verbatim and the test fails.
Fix it by introducing a variable to hold the list of parents for
the dodecapus and populating it in a more low-tech way.
While at it, simplify a little by combining this setup code with the
test it sets up for.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since e9c8409 (diff-index --cached --raw: show tree entry on the LHS for
unmerged entries., 2007-01-05), an unmerged entry should be detected by
using DIFF_PAIR_UNMERGED(p), not by noticing both one and two sides of
the filepair records mode=0 entries. However, it forgot to update some
parts of the rename detection logic.
This only makes difference in the "diff --cached" codepath where an
unmerged filepair carries information on the entries that came from the
tree. It probably hasn't been noticed for a long time because nobody
would run "diff -M" during a conflict resolution, but "git status" uses
rename detection when it internally runs "diff-index" and "diff-files"
and gives nonsense results.
In an unmerged pair, "one" side can have a valid filespec to record the
tree entry (e.g. what's in HEAD) when running "diff --cached". This can
be used as a rename source to other paths in the index that are not
unmerged. The path that is unmerged by definition does not have the
final content yet (i.e. "two" side cannot have a valid filespec), so it
can never be a rename destination.
Use the DIFF_PAIR_UNMERGED() to detect unmerged filepair correctly, and
allow the valid "one" side of an unmerged filepair to be considered a
potential rename source, but never to be considered a rename destination.
Commit message and first two test cases by Junio, the rest by Martin.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-new-workdir script in contrib/ makes a new work tree by sharing
many subdirectories of the .git directory with the original repository.
When rerere.enabled is set in the original repository, but the user has
not encountered any conflicts yet, the original repository may not yet
have .git/rr-cache directory.
When rerere wants to run in a new work tree created from such a young
original repository, it fails to mkdir(2) .git/rr-cache that is a symlink
to a yet-to-be-created directory.
There are three possible approaches to this:
- A naive solution is not to create a symlink in the git-new-workdir
script to a directory the original does not have (yet). This is not a
solution, as we tend to lazily create subdirectories of .git/, and
having rerere.enabled configuration set is a strong indication that the
user _wants_ to have this lazy creation to happen;
- We could always create .git/rr-cache upon repository creation. This is
tempting but will not help people with existing repositories.
- Detect this case by seeing that mkdir(2) failed with EEXIST, checking
that the path is a symlink, and try running mkdir(2) on the link
target.
This patch solves the issue by doing the third one.
Strictly speaking, this is incomplete. It does not attempt to handle
relative symbolic link that points into the original repository, but this
is good enough to help people who use contrib/workdir/git-new-workdir
script.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This also adds test for "--merges" and "--no-merges" which we did not
have so far.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mg/rev-list-one-side-only:
git-log: put space after commit mark
t6007: test rev-list --cherry
log --cherry: a synonym
rev-list: documentation and test for --cherry-mark
revision.c: introduce --cherry-mark
rev-list/log: factor out revision mark generation
rev-list: --left/right-only are mutually exclusive
rev-list: documentation and test for --left/right-only
t6007: Make sure we test --cherry-pick
revlist.c: introduce --left/right-only for unsymmetric picking
* jn/test-sanitize-git-env:
tests: scrub environment of GIT_* variables
config: drop support for GIT_CONFIG_NOGLOBAL
gitattributes: drop support for GIT_ATTR_NOGLOBAL
tests: suppress system gitattributes
tests: stop worrying about obsolete environment variables
* jc/maint-fetch-alt:
fetch-pack: objects in our alternates are available to us
refs_from_alternate: helper to use refs from alternates
Conflicts:
builtin/receive-pack.c
This reverts commit 951f316470
(Add treap implementation, 2010-08-09). The string_pool was
trp.h's last user.
Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
This reverts commit 1d73b52f5b
(Add string-specific memory pool, 2010-08-09). Now that svn-fe
does not need to maintain a growing collection of strings (paths)
over a long period of time, the string_pool is not needed.
Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
When there are too many paths in the project, the number of rename source
candidates "git diff -C -C" finds will exceed the rename detection limit,
and no inexact rename detection is performed. We however could fall back
to "git diff -C" if the number of modified paths is sufficiently small.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Update draft release notes to 1.7.4.2
Work around broken ln on solaris as used in t8006
t/README: Add a note about running commands under valgrind
* so/submodule-no-update-first-time:
t7406: "git submodule update {--merge|--rebase]" with new submodules
submodule: no [--merge|--rebase] when newly cloned
The test setup in t8006-blame-textconv.sh uses "ln -sf" to
overwrite an existing symlink. Unfortunately, both /usr/bin/ln
and /usr/xpg4/bin/ln on solaris 9 don't properly handle -f and -s
used at the same time. This caused the test setup and subsequent
checks to fail.
Instead, remove the symlink and then create a new one in the
setup code.
The upstream Solaris bug (fixed in 10, but not 9) is documented
here:
http://bugs.opensolaris.org/view_bug.do?bug_id=4372462
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
[jc: moved "cd subdir" inside subshell and fixed comparison with expected]
Signed-off-by: Piotr Krukowiecki <piotr.krukowiecki@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test suite runs valgrind with certain options activated. Add a
note saying how to run commands under the same conditions as the test
suite does.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When leaving a detached HEAD, we do a revision walk to make
sure the commit we are leaving isn't being orphaned.
However, this leaves crufty marks in the commit objects
which can confuse later walkers, like the one in
stat_tracking_info.
Let's clean up after ourselves to prevent this conflict.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 8e2dc6ac added a warning when we leave a detached
HEAD whose commit is not reachable from any ref tip. Let's
add a few basic tests to make sure it works.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ab/i18n-basic:
i18n: "make distclean" should clean up after "make pot"
i18n: Makefile: "pot" target to extract messages marked for translation
i18n: add stub Q_() wrapper for ngettext
i18n: do not poison translations unless GIT_GETTEXT_POISON envvar is set
i18n: add GETTEXT_POISON to simulate unfriendly translator
i18n: add no-op _() and N_() wrappers
commit, status: use status_printf{,_ln,_more} helpers
commit: refer to commit template as s->fp
wt-status: add helpers for printing wt-status lines
Conflicts:
builtin/commit.c
* jk/trace-sifter:
trace: give repo_setup trace its own key
add packet tracing debug code
trace: add trace_strbuf
trace: factor out "do we want to trace" logic
trace: refactor to support multiple env variables
trace: add trace_vprintf
* jk/format-patch-multiline-header:
format-patch: rfc2047-encode newlines in headers
format-patch: wrap long header lines
strbuf: add fixed-length version of add_wrapped_text
--separate-git-dir tells git to create git dir at the specified
location, instead of where it is supposed to be. A .git file that
points to that location will be put in place so that it appears normal
to repo discovery process.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Support the well-know convention of reading standard input instead of a
named file if "-" (dash) is specified. GNU grep does the same.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the helper function split from the receiving end of "git push" to
allow the same optimization on the receiving end of "git fetch".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
