SVN 1.7 will truncate "not-a%40{0}" to just "not-a".
Rather than guess what SVN is going to do for each version, make the test use
the branch name that was actually created.
[ew: commit title]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This canonicalizes paths and urls as early as possible so we don't
have to remember to do it at the point of use. It will fix a swath
of SVN 1.7 problems in one go.
Its ok to double canonicalize things.
SVN 1.7 still fails, still not worrying about that.
[ew: commit title]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Otherwise you might wind up with things like...
my $path1 = undef;
my $path2 = 'foo';
my $path = $path1 . '/' . $path2;
creating '/foo'. Or this...
my $path1 = 'foo/';
my $path2 = 'bar';
my $path = $path1 . '/' . $path2;
creating 'foo//bar'.
Could have used File::Spec, but I'm shying away from it due to SVN
1.7's pickiness about paths. Felt it would be better to have our own
we can control completely.
[ew: commit title]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The SVN API functions will not accept ../foo but their canonicalization
functions will not collapse it. So we'll have to do it ourselves.
_collapse_dotdot() works better than the existing regex did.
This will be used shortly when canonicalize_path() starts using the
SVN API.
[ew: commit title]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
No change on SVN 1.6. The tests all pass with SVN 1.6 if
canonicalize_url() does nothing, so tests passing doesn't have
much meaning.
The tests are so messed up right now with SVN 1.7 it isn't really
useful to check. They will be useful later.
[ew: commit title]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
So they can be used by others.
I'd like to test them, but they're going to become SVN API wrappers shortly
and those aren't predictable.
No functional change.
[ew: commit title]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Note: The structure returned from Git::SVN->read_all_remotes() does not
appear to contain objects, so I'm leaving them alone.
That's everything converted over to the url and path accessors.
No functional change.
[ew: commit title]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Later it can canonicalize automatically.
A later change will make other things use the accessor.
No functional change.
[ew: commit title, reformatted accessor to match existing style]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
So later it can do automatic canonicalization.
A later patch will make other things use the accessor.
No functional change here.
[ew: commit title]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Then later it can be canonicalized automatically rather than everywhere
its used.
Later patch will make other things use it.
[ew: commit title, reformatted accessor to match existing style]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Generate po/git.pot from v1.7.12-rc1-16-g05a20, and there are 76 new,
4 removed l10n messages.
* 76 new messages are added at lines:
230, 337-580, 4972, 4984, 4998, 5017, 5280-5378, 5654
* 4 old messages are deleted from the previous version at lines:
230, 4729, 4764, 5295
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Fix a typo in the error messages which is shown if it seems that a
rebase is already in progress.
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The RFC2047 unquoting, used to parse email addresses in From and Cc
headers, is broken in several ways:
* It erroneously substitutes ' ' for '_' in *the whole* header, even
outside the quoted field. [Noticed by Christoph.]
* It is too liberal in its matching, and happily matches the start
of one quoted chunk against the end of another, or even just
something that looks like such an end. [Noticed by Junio.]
* It fundamentally cannot cope with encodings that are not a
superset of ASCII, nor several (incompatible) encodings in the
same header.
This patch fixes the first two by doing a more careful decoding of
the outer quoting (e.g. "=AB" to represent an octet whose value is
0xAB). Fixing the fundamental issues is left for a future, more
intrusive, patch.
Noticed-by: Christoph Miebach <christoph.miebach@web.de>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you have a non-directory on your PATH, a funny thing happens:
$ PATH=$PATH:/bin/sh git foo
fatal: cannot exec 'git-foo': Not a directory?
Worse yet, as real commands always take precedence over aliases,
this behaviour interacts rather badly with them:
$ PATH=$PATH:/bin/sh git -c alias.foo=show git foo -s
fatal: cannot exec 'git-foo': Not a directory?
This is because an ENOTDIR error from the underlying execvp(2) is
reported back to the caller of our sane_execvp() wrapper as-is.
Translating it to ENOENT, just like the case where we _might_ have
the command in an unreadable directory, fixes it. Without an alias,
we would get
git: 'foo' is not a git command. See 'git --help'.
and we use the 'foo' alias when it is available, of course.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add i18n support for scripted Porcelains, and mark strings in
merge(-recursive), am, and rebase for i18n.
* jx/i18n-1.7.11:
i18n: merge-recursive: mark strings for translation
Remove dead code which contains bad gettext block
i18n: am: mark more strings for translation
rebase: remove obsolete and unused LONG_USAGE which breaks xgettext
i18n: Rewrite gettext messages start with dash
i18n: rebase: mark messages for translation
i18n: New keywords for xgettext extraction from sh
"$GIT_DIR/COMMIT_EDITMSG" file that is used to hold the commit log
message user edits was not documented.
* jk/maint-commit-document-editmsg:
commit: document the temporary commit message file
The advise() function did not use varargs correctly to format
its message.
* jk/maint-advise-vaddf:
advice: pass varargs to strbuf_vaddf, not strbuf_addf
"git commit-tree" learned a more natural "-p <parent> <tree>" order
of arguments long time ago, but recently forgot it by mistake.
* kk/maint-commit-tree:
Revert "git-commit-tree(1): update synopsis"
commit-tree: resurrect command line parsing updates
"git diff --no-ext-diff" did not output anything for a typechange
filepair when GIT_EXTERNAL_DIFF is in effect.
* jv/maint-no-ext-diff:
diff: test precedence of external diff drivers
diff: correctly disable external_diff with --no-ext-diff
When "git am" failed, old timers knew to check .git/rebase-apply/patch
to see what went wrong, but we never told the users about it.
* pg/maint-1.7.9-am-where-is-patch:
am: indicate where a failed patch is to be found
When "git submodule add" clones a submodule repository, it can get
confused where to store the resulting submodule repository in the
superproject's .git/ directory when there is a symbolic link in the
path to the current directory.
* jl/maint-1.7.10-recurse-submodules-with-symlink:
submodules: don't stumble over symbolic links when cloning recursively
In 1.7.9 era, we taught "git rebase" about the raw timestamp format
but we did not teach the same trick to "filter-branch", which rolled
a similar logic on its own.
* jc/maint-filter-branch-epoch-date:
t7003: add test to filter a branch with a commit at epoch
date.c: Fix off by one error in object-header date parsing
filter-branch: do not forget the '@' prefix to force git-timestamp
"git grep" stopped spawning an external "grep" long time ago, but a
duplicated test to check internal and external "grep" was left
behind.
* rj/maint-grep-remove-redundant-test:
t7810-*.sh: Remove redundant test
Finishing touches to the new test script.
* dg/submodule-in-dismembered-working-tree:
t7409: make sure submodule is initialized and updated in more detail
The earlier test did not even make sure that the correct commit is
checked out in the submodule directory. Inspect the result in a bit
more detail.
Signed-off-by: Daniel Graña <dangra@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code to avoid mistaken attempt to add the object directory
itself as its own alternate could read beyond end of a string while
comparison.
* hv/link-alt-odb-entry:
link_alt_odb_entry: fix read over array bounds reported by valgrind
The patch below adds a comment to fetch_with_import() explaining the
loop that saves the fetched commit names after 'git fast-import' has
done its work. It avoids some confusion about which refs the
fast-import stream is supposed to use to write its result.
Signed-off-by: Florian Achleitner <florian.achleitner.2.6.31@gmail.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test happened to use "rev-parse --max-count=1 HEAD" consistently
to prepare the expected output and the actual output, so the
comparison between them gave us a correct success/failure because
both output had irrelevant "--max-count=1" in it.
But that is not an excuse to keep it broken. Replace it a more
meaningful construct "rev-parse --verify HEAD".
Noticed by Daniel Graña while working on his submodule tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We instead failed with an undocumented exit status 255.
Also define a "catch-all" status and document it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Generate po/git.pot from v1.7.12-rc0-54-g9e211, and there are 4 new,
3 removed l10n messages.
* 4 new messages are added at lines:
1254, 1264, 1459, 1523
* 3 old messages are deleted from the previous version at lines:
1254, 1273, 2854
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Since commit bbc09c22 ("grep: rip out support for external grep",
12-01-2010), test number 60 ("grep -C1 hunk mark between files") is
essentially the same as test number 59.
Test 59 was intended to verify the behaviour of git-grep resulting
from multiple invocations of an external grep. As part of the test,
it creates and adds 1024 files to the index, which is now wasted
effort.
Remove test 59, since it is now redundant.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, the final test ('flags and then non flags') fails
intermittently, depending on how much time elapsed between the
invocations of "git commit-tree" when creating the commits which
later have their commit id's compared. For example, if the commits
for childid-3 and childid-4 are created 1 or more seconds apart,
then the commits, which would otherwise be identical, will have
different commit id's.
In order to make the test reproducible, we remove the variability
by setting the author and committer times to a well defined state.
We accomplish this with a single call to 'test_tick' at the start
of the test.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pfxlen can be longer than the path in objdir when relative_base
contains the path to gits object directory. Here we are interested
in checking if ent->base[] (the part that corresponds to .git/objects)
is the same string as objdir, and the code NUL-terminated ent->base[]
to
LEADING PATH\0XX/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\0
in preparation for these "duplicate check" step (before we return
from the function, the first NUL is turned into '/' so that we can
fill XX when probing for loose objects). All we need to do is to
compare the string with the path to our object directory.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While walking the revision list in get_patch_ids and cmd_cherry, we
check for each commit if there is more than one parent and ignore
the commit if that is the case. Instead, set rev_info.max_parents to
1 and let the revision traversal code handle it for us.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ever since cherry was built-in in e827633 (Built-in cherry,
2006-10-24), it has set a bunch of options on the the rev_info that
are only used while outputting a patch. But since the built-in cherry
command never needs to output any patch (it uses add_commit_patch_id
and has_commit_patch_id instead), these options are just distractions,
so remove them.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Short of somebody happening to beat the 1 in 2^160 odds of
actually generating content that hashes to the null sha1, we
should never see this value in a tree entry. So let's have
fsck warn if it it seen.
As in the previous commit, we test both blob and submodule
entries to future-proof the test suite against the
implementation depending on connectivity to notice the
error.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We should never need to write the null sha1 into an index
entry (short of the 1 in 2^160 chance that somebody actually
has content that hashes to it). If we attempt to do so, it
is much more likely that it is a bug, since we use the null
sha1 as a sentinel value to mean "not valid".
The presence of null sha1s in the index (which can come
from, among other things, "update-index --cacheinfo", or by
reading a corrupted tree) can cause problems for later
readers, because they cannot distinguish the literal null
sha1 from its use a sentinel value. For example, "git
diff-files" on such an entry would make it appear as if it
is stat-dirty, and until recently, the diff code assumed
such an entry meant that we should be diffing a working tree
file rather than a blob.
Ideally, we would stop such entries from entering even our
in-core index. However, we do sometimes legitimately add
entries with null sha1s in order to represent these sentinel
situations; simply forbidding them in add_index_entry breaks
a lot of the existing code. However, we can at least make
sure that our in-core sentinel representation never makes it
to disk.
To be thorough, we will test an attempt to add both a blob
and a submodule entry. In the former case, we might run into
problems anyway because we will be missing the blob object.
But in the latter case, we do not enforce connectivity
across gitlink entries, making this our only point of
enforcement. The current implementation does not care which
type of entry we are seeing, but testing both cases helps
future-proof the test suite in case that changes.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The diff code represents paths using the diff_filespec
struct. This struct has a sha1 to represent the sha1 of the
content at that path, as well as a sha1_valid member which
indicates whether its sha1 field is actually useful. If
sha1_valid is not true, then the filespec represents a
working tree file (e.g., for the no-index case, or for when
the index is not up-to-date).
The diff_filespec is only used internally, though. At the
interfaces to the diff subsystem, callers feed the sha1
directly, and we create a diff_filespec from it. It's at
that point that we look at the sha1 and decide whether it is
valid or not; callers may pass the null sha1 as a sentinel
value to indicate that it is not.
We should not typically see the null sha1 coming from any
other source (e.g., in the index itself, or from a tree).
However, a corrupt tree might have a null sha1, which would
cause "diff --patch" to accidentally diff the working tree
version of a file instead of treating it as a blob.
This patch extends the edges of the diff interface to accept
a "sha1_valid" flag whenever we accept a sha1, and to use
that flag when creating a filespec. In some cases, this
means passing the flag through several layers, making the
code change larger than would be desirable.
One alternative would be to simply die() upon seeing
corrupted trees with null sha1s. However, this fix more
directly addresses the problem (while bogus sha1s in a tree
are probably a bad thing, it is really the sentinel
confusion sending us down the wrong code path that is what
makes it devastating). And it means that git is more capable
of examining and debugging these corrupted trees. For
example, you can still "diff --raw" such a tree to find out
when the bogus entry was introduced; you just cannot do a
"--patch" diff (just as you could not with any other
corrupted tree, as we do not have any content to diff).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
