Subversion 1.7 and newer implement HTTPv2, an extension that should make HTTP
more efficient. Servers with support for this protocol will make the subversion
client library take an alternative code path that checks (with assertions)
whether the URL is "canonical" or not.
This patch fixes an issue I encountered while trying to `git svn dcommit` a
rename action for a file containing a single quote character ("User's Manual"
to "UserMan.tex"). It does not happen for older subversion 1.6 servers nor
non-HTTP(S) protocols such as the native svn protocol, only on an Apache server
shipping SVN 1.7. Trying to `git svn dcommit` under the aforementioned
conditions yields the following error which aborts the commit process:
Committing to http://example.com/svn ...
perl: subversion/libsvn_subr/dirent_uri.c:1520: uri_skip_ancestor:
Assertion `svn_uri_is_canonical(child_uri, ((void *)0))' failed.
error: git-svn died of signal 6
An analysis of the subversion source for the cause:
- The assertion originates from uri_skip_ancestor which calls
svn_uri_is_canonical, which fails when the URL contains percent-encoded values
that do not necessarily have to be encoded (not "canonical" enough). This is
done by a table lookup in libsvn_subr/path.c. Putting some debugging prints
revealed that the character ' is indeed encoded to %27 which is not
considered canonical.
- url_skip_ancestor is called by svn_ra_neon__get_baseline_info with the root
repository URL and path as parameters;
- which is called by copy_resource (libsvn_ra_neon/commit.c) for a copy action
(or in my case, renaming which is actually copy + delete old);
- which is called by commit_add_dir;
- which is assigned as a structure method "add_file" in
svn_ra_neon__get_commit_editor.
In the whole path, the path argument is not modified.
Through some more uninteresting wrapper functions, the Perl bindings gives you
access to the add_file method which will pass the path argument without
modifications to svn.
git-svn calls the "R"(ename) subroutine in Git::SVN::Editor which contains:
326 my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
327 $self->url_path($m->{file_a}), $self->{r});
"repo_path" basically returns the path as-is, unless the "svn.pathnameencoding"
configuration property is set. "url_path" tries to escape some special
characters, but does not take all special characters into account, thereby
causing the path to contain some escaped characters which do not have to be
escaped.
The list of characters not to be escaped are taken from the
subversion/libsvn_subr/path.c file to fully account for all characters. Tested
with a filename containing all characters in the range 0x20 to 0x78 (inclusive).
Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Subversion's canonical URLs are intended to make URL comparison easy
and therefore have strict rules about what characters are special
enough to urlencode and what characters should be left alone.
When in the fallback codepath because unable to use libsvn's own
canonicalization function for some reason, escape special characters
in URIs according to the svn_uri__char_validity[] table in
subversion/libsvn_subr/path.c (r935829). The libsvn versions that
trigger this code path are not likely to be strict enough to care, but
it's nicer to be consistent.
Noticed by using SVN 1.6.17 perl bindings, which do not provide
SVN::_Core::svn_uri_canonicalize (triggering the fallback code),
with libsvn 1.7.5, whose do_switch is fussy enough to care:
Committing to file:///home/jrn/src/git/t/trash%20directory.\
t9118-git-svn-funky-branch-names/svnrepo/pr%20ject/branches\
/more%20fun%20plugin%21 ...
svn: E235000: In file '[...]/subversion/libsvn_subr/dirent_uri.c' \
line 2291: assertion failed (svn_uri_is_canonical(url, pool))
error: git-svn died of signal 6
not ok - 3 test dcommit to funky branch
After this change, the '!' in 'more%20fun%20plugin!' is not urlencoded
and t9118 passes again.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This shouldn't make a difference because the $deletions hash is
only used when adding a directory (see 379862ec, 2012-02-20) but
it's nice to be consistent to make reading smoother anyway. No
functional change intended.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn reads usernames and other user queries from an interactive
terminal. This cause GUIs (w/o STDIN connected) to hang waiting forever
for git-svn to complete (http://code.google.com/p/tortoisegit/issues/detail?id=967).
This change extends the Git::prompt helper, so that it can also be used
for non password queries, and makes use of it instead of using
hand-rolled prompt-response code that only works with the interactive
terminal.
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If GIT_ASKPASS environment variable is not set, git-svn does not try to use
SSH_ASKPASS as git-core does. This change adds a fallback to SSH_ASKPASS.
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn reads passwords from an interactive terminal or by using
GIT_ASKPASS helper tool. This cause GUIs (w/o STDIN connected) to hang
waiting forever for git-svn to complete
(http://code.google.com/p/tortoisegit/issues/detail?id=967).
Commit 56a853b62c also tried to solve
this issue, but was incomplete as described above.
Instead of using hand-rolled prompt-response code that only works with the
interactive terminal, a reusable prompt() method is introduced in this commit.
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Subversion represents symlinks as ordinary files with content starting
with "link " and the svn:special property set to "*". Thus a file can
switch between being a symlink and a non-symlink simply by toggling
its svn:special property, and new checkouts will automatically write a
file of the appropriate type. Likewise, in subversion 1.6 and older,
running "svn update" would notice changes in filetype and update the
working copy appropriately.
Starting in subversion 1.7 (issue 4091), changes to the svn:special
property trip an assertion instead:
$ svn up svn-tree
Updating 'svn-tree':
svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' \
line 1583: assertion failed (action == svn_wc_conflict_action_edit \
|| action == svn_wc_conflict_action_delete || action == \
svn_wc_conflict_action_replace)
Revisions prepared with ordinary svn commands ("svn add" and not "svn
propset") don't trip this because they represent these filetype
changes using a replace operation, which is approximately equivalent
to removal followed by adding a new file and works fine. Follow suit.
Noticed using t9100. After this change, git-svn's file-to-symlink
changes are sent in a format that modern "svn update" can handle and
tests t9100.11-13 pass again.
[ew: s,git-svn\.perl,perl/Git/SVN/Editor.pm,g]
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Subversion's svn_dirent_canonicalize() and svn_path_canonicalize()
APIs keep a leading slash in the return value if one was present on
the argument, which can be useful since it allows relative and
absolute paths to be distinguished.
When git-svn's canonicalize_path() learned to use these functions if
available, its semantics changed in the corresponding way. Some new
callers rely on the leading slash --- for example, if the slash is
stripped out then _canonicalize_url_ourselves() will transform
"proto://host/path/to/resource" to "proto://hostpath/to/resource".
Unfortunately the fallback _canonicalize_path_ourselves(), used when
the appropriate SVN APIs are not usable, still follows the old
semantics, so if that code path is exercised then it breaks. Fix it
to follow the new convention.
Noticed by forcing the fallback on and running tests. Without this
patch, t9101.4 fails:
Bad URL passed to RA layer: Unable to open an ra_local session to \
URL: Local URL 'file://homejrnsrcgit-scratch/t/trash%20directory.\
t9101-git-svn-props/svnrepo' contains unsupported hostname at \
/home/jrn/src/git-scratch/perl/blib/lib/Git/SVN.pm line 148
With it, the git-svn tests pass again.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
All users of $gs->{path} should have been converted to use the
accessor by now. Check our work by renaming the underlying variable
to break callers that try to use it directly.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The accessors should improve maintainability and enforce
consistent access to Git::SVN objects.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
When using the {word,[...]} style of configuration for tags and branches,
it appears the intent is to only match whole path parts, since the words
in the {} pattern are meta-character quoted.
When the pattern word appears in the beginning or middle of the url,
it's matched completely, since the left side, pattern, and (non-empty)
right side are joined together with path separators.
However, when the pattern word appears at the end of the URL, the
right side is an empty pattern, and the resulting regex matches
more than just the specified pattern.
For example, if you specify something along the lines of
branches = branches/project/{release_1,release_2}
and your repository also contains "branches/project/release_1_2", you
will also get the release_1_2 branch. By restricting the match regex
with anchors, this is avoided.
Signed-off-by: Ammon Riley <ammon.riley@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This fixes a bug where git finds the incorrect merge parent. Consider a
repository with trunk, branch1 of trunk, and branch2 of branch1.
Without this change, git interprets a merge of branch2 into trunk as a
merge of branch1 into trunk.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Reviewed-by: Sam Vilain <sam@vilain.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Consider the case where you have trunk, branch1 of trunk, and branch2 of
branch1. trunk is merged back into branch2, and then branch2 is
reintegrated into trunk. The merge of branch2 into trunk will have
svn:mergeinfo property references to both branch1 and branch2. When
git-svn fetches the commit that merges branch2 (check_cherry_pick),
it is necessary to eliminate the merged contents of branch1 as well as
branch2, or else the merge will be incorrectly ignored as a cherry-pick.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Reviewed-by: Sam Vilain <sam@vilain.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
A series by Michael Schwern via Eric to update git-svn to revamp the
way URLs are internally passed around, to make it work with SVN 1.7.
* ms/git-svn-1.7:
git-svn: remove ad-hoc canonicalizations
git-svn: canonicalize newly-minted URLs
git-svn: introduce add_path_to_url function
git-svn: canonicalize earlier
git-svn: replace URL escapes with canonicalization
git-svn: attempt to mimic SVN 1.7 URL canonicalization
t9107: fix typo
t9118: workaround inconsistency between SVN versions
Git::SVN{,::Ra}: canonicalize earlier
git-svn: path canonicalization uses SVN API
Git::SVN::Utils: remove irrelevant comment
git-svn: add join_paths() to safely concatenate paths
git-svn: factor out _collapse_dotdot function
git-svn: use SVN 1.7 to canonicalize when possible
git-svn: move canonicalization to Git::SVN::Utils
use Git::SVN{,::RA}->url accessor globally
use Git::SVN->path accessor globally
Git::SVN::Ra: use accessor for URLs
Git::SVN: use accessor for URLs internally
Git::SVN: use accessors internally for path
Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30),
git-svn has maintained some private per-repository caches in
.git/svn/.caches to avoid refetching and recalculating some
mergeinfo-related information with every 'git svn fetch'.
This memoization can cause problems, e.g consider the following case:
SVN repo:
... - a - b - c - m <- trunk
\ /
d - e <- branch1
The Git import of the above repo is at commit 'a' and doesn't know about
the branch1. In case of an 'git svn rebase', only the trunk of the
SVN repo is imported. During the creation of the git commit 'm', git svn
uses the svn:mergeinfo property and tries to find the corresponding git
commit 'e' to create 'm' with 'c' and 'e' as parents. But git svn rebase
only imports the current branch so commit 'e' is not imported.
Therefore git svn fails to create commit 'm' as a merge commit, because one
of its parents is not known to git. The imported history looks like this:
... - a - b - c - m <- trunk
A later 'git svn fetch' to import all branches can't rewrite the commit 'm'
to add 'e' as a parent and to make it a real git merge commit, because it
was already imported.
That's why the imported history misses the merge and looks like this:
... - a - b - c - m <- trunk
\
d - e <- branch1
Right now the only known workaround for importing 'm' as a merge is to
force reimporting 'm' again from SVN, e.g. via
$ git svn reset --revision $(git find-rev $c)
$ git svn fetch
Sadly, this is where the behavior has regressed: git svn reset doesn't
invalidate the old mergeinfo cache, which is no longer valid for the
reimport, which leads to 'm' beeing imprted with only 'c' as parent.
As solution to this problem, this commit invalidates the mergeinfo cache
to force correct recalculation of the parents.
During development of this patch, several ways for invalidating the cache
where considered. One of them is to use Memoize::flush_cache, which will
call the CLEAR method on the underlying Memoize persistency implementation.
Sadly, neither Memoize::Storable nor the newer Memoize::YAML module
introduced in 68f532f4ba could optionally be used implement the
CLEAR method, so this is not an option.
Reseting the internal hash used to store the memoized values has the same
problem, because it calls the non-existing CLEAR method of the
underlying persistency layer, too.
Considering this and taking into account the different implementations
of the memoization modules, where Memoize::Storable is not in our control,
implementing the missing CLEAR method is not an option, at least not if
Memoize::Storable is still used.
Therefore the easiest solution to clear the cache is to delete the files
on disk in 'git svn reset'. Normally, deleting the files behind the back
of the memoization module would be problematic, because the in-memory
representation would still exist and contain wrong data. Fortunately, the
memoization is active in memory only for a small portion of the code.
Invalidating the cache by deleting the files on disk if it isn't active
should be safe.
Signed-off-by: Peter Baumann <waste.manager@gmx.de>
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Go through all the spots that use the new add_path_to_url() to
make a new URL and canonicalize them.
* copyfrom_path has to be canonicalized else find_parent_branch
will get confused
* due to the `canonicalize_url($full_url) ne $full_url)` line of
logic in gs_do_switch(), $full_url is left alone until after.
At this point SVN 1.7 passes except for 3 tests in
t9100-git-svn-basic.sh that look like an SVN bug to do with
symlinks.
[ew: commit title]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Remove the ad-hoc versions.
This is mostly to normalize the process and ensure the URLs produced
don't have double slashes or anything.
Also provides a place to fix the corner case where a file path
contains a percent sign.
[ew: commit title]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The old hand-rolled URL escape functions were inferior to
canonicalization functions.
Continuing to move towards getting everything canonicalizing the same way.
* Git::SVN->init_remote_config and Git::SVN::Ra->minimize_url both
have to canonicalize the same way else init_remote_config
will incorrectly think they're different URLs causing
t9107-git-svn-migrate.sh to fail.
[ew: commit title]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Previously, our URL canonicalization didn't do much of anything.
Now it actually escapes and collapses slashes. This is mostly a cut & paste
of escape_url from git-svn.
This is closer to how SVN 1.7's canonicalization behaves. Doing it with
1.6 lets us chase down some problems caused by more effective canonicalization
without having to deal with all the other 1.7 issues on top of that.
* Remote URLs have to be canonicalized otherwise Git::SVN->find_existing_remote
will think they're different.
* The SVN remote is now written to the git config canonicalized. That
should be ok. Adjust a test to account for that.
[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>
Straight cut & paste. That's the last class.
* Make Git::SVN load it on its own, its the only thing that needs it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Except for adding the 1; at the end, this is a straight copy & paste.
Tests still pass, but its doubtful Git::SVN will compile on its own
without git-svn being loaded. Next commit will fix that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Put them in a new module called Git::SVN::Utils. Yeah, not terribly
original and it will be a dumping ground. But its better than having
them in the main git-svn program. At least they can be documented
and tested.
* fatal() is used by many classes.
* Change the $can_compress lexical into a function.
This should be enough to extract Git::SVN.
Signed-off-by: Michael G. Schwern <schwern@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
While Makefile.PL now finds .pm files on its own, it does not
detect new files after it generates perl/perl.mak.
[ew: commit message, minor tweaks]
ref: http://mid.gmane.org/7vlii51xz4.fsf@alter.siamese.dyndns.org
Signed-off-by: Eric Wong <normalperson@yhbt.net>
It is no longer necessary to manually add new .pm files to the
Makefile.PL. This makes it easier to add modules.
It is still necessary to add them to the Makefile, but that extra work
should be removed at a future date.
Signed-off-by: Michael G Schwern <schwern@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
In older Perls, sometimes $@ can become unset between the eval and
checking $@. Its safer to check the eval directly.
Signed-off-by: Michael G Schwern <schwern@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Usually it isn't, but its nice if it can be run with warnings on.
Signed-off-by: Michael G Schwern <schwern@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
In the NO_PERL_MAKEMAKER=YesPlease fallback case, make the directory
that will contain each module when installing it (simulating "install
-D") instead of hardcoding "Git/SVN/Memoize is the deepest level".
This should make this codepath which is not used often on development
machines a little easier to maintain.
Requested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
v1.7.11-rc1~12^2~2 (2012-05-27) and friends split some git-svn code
into separate modules but did not update the fallback rules to install
them when NO_PERL_MAKEMAKER is set. Add the appropriate rules so
users without MakeMaker can use git-svn again.
Affected modules: Git::SVN::Prompt, Git::SVN::Fetcher,
Git::SVN::Editor, Git::SVN::Ra, Git::SVN::Memoize::YAML.
Reported-by: Adam Roben <adam@roben.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmali.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adding or removing a module requires modifying both files to support
builds with and without MakeMaker. Add a comment to remind patch
authors and reviewers at the crucial moment.
Longer term, it would be nicer to maintain a single list, perhaps in a
separate file used by both build systems.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30),
git-svn has maintained some private per-repository caches in
.git/svn/.caches to avoid refetching and recalculating some
mergeinfo-related information with every "git svn fetch".
These caches use the 'nstore' format from the perl core module
Storable, which can be read and written quickly and was designed for
transfer over the wire (the 'n' stands for 'network'). This format is
endianness-independent and independent of floating-point
representation.
Unfortunately the format is *not* independent of the perl version ---
new perl versions will write files that very old perl cannot read.
Worse, the format is not independent of the size of a perl integer.
So if you toggle perl's use64bitint compile-time option, then using
'git svn fetch' on your old repositories produces errors like this:
Byte order is not compatible at ../../lib/Storable.pm (autosplit
into ../../lib/auto/Storable/_retrieve.al) line 380, at
/usr/share/perl/5.12/Memoize/Storable.pm line 21
That is, upgrading perl to a version that uses use64bitint for the
first time makes git-svn suddenly refuse to fetch in existing
repositories. Removing .git/svn/.caches lets git-svn recover.
It's time to switch to a platform independent serializer backend with
better compatibility guarantees. This patch uses YAML::Any.
Other choices were considered:
- thawing data from Data::Dumper involves "eval". Doing that without
creating a security risk is fussy.
- the JSON API works on scalars in memory and doesn't provide a
standard way to serialize straight to disk.
YAML::Any is reasonably fast and has a pleasant API. In most
backends, LoadFile() reads the entire file into a scalar anyway and
converts it as a second step, but having an interface that allows the
deserialization to happen on the fly without a temporary is still a
comfort.
YAML::Any is not a core perl module, so we take care to use it when
and only when it is available. Installations without that module
should fall back to using Storable with all its quirks, keeping their
cache files in
.git/svn/.caches/*.db
Installations with YAML peacefully coexist by keeping a separate set
of cache files in
.git/svn/.caches/*.yaml.
In most cases, switching between is a one-time thing, so it doesn't
seem worth the complication to migrate existing caches.
The upshot: after this patch, as long as YAML::Any is installed you
can move your git repository between machines with different perl
installations and "git svn fetch" will work fine. If you do not have
YAML::Any, the behavior is unchanged (and in particular does not get
any worse).
Reported-by: Sandro Weiser <sandro.weiser@informatik.tu-chemnitz.de>
Reported-by: Bdale Garbee <bdale@gag.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This slices off another 600 or so lines from the frighteningly long
git-svn.perl script.
The Git::SVN::Ra interface is similar enough to SVN::Ra that it is
probably safe to ignore most of its implementation on first reading.
(Documenting or moving functions that do not fit that pattern is left
as an exercise to the interested reader.)
[ew: rebased and fixed conflict against
commit c26ddce86d
(git-svn: platform auth providers are working only on 1.6.15 or newer)]
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This makes the git-svn script shorter and less scary for beginners to
read through for the first time. Take the opportunity to explain the
purpose and basic interface of the Git::SVN::Editor class while at it.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This patch removes a chunk of code (the Git::SVN::Fetcher consumer of
libsvn's tree delta protocol) from git-svn.perl and documents its
interface so the hurried reader does not have to read that code right
away.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn.perl is very long (around 6500 lines) and although it is
nicely split into modules, some new readers do not even notice --- it
is too distracting to see all this functionality collected in a single
file.
Splitting it into multiple files would make it easier for people
to read individual modules straight through and to experiment with
components separately.
Let's start with Git::SVN::Prompt. For simplicity, we install this as
a module in the standard search path, just like the existing Git and
Git::I18N modules. In the process, add a manpage explaining its
interface and that it is not likely to be useful for other projects to
avoid confusion.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
When I added the i18n infrastructure in v1.7.8-rc2-1-g5e9637c I forgot
to install Git::I18N also when NO_PERL_MAKEMAKER=YesPlease was
set. Change the generation of the fallback perl.mak file to do that.
Now Git/I18N.pm is installed alongside Git.pm in such a way that
anything that uses GITPERLLIB will find it.
Reported-by: Tom G. Christensen <tgc@statsbiblioteket.dk>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the Exporter invocation in Git::I18N to be compatible with
5.8.0 to 5.8.2 inclusive. Before Exporter 5.57 (released with 5.8.3)
Exporter didn't export the 'import' subroutine.
Reported-by: Tom G. Christensen <tgc@statsbiblioteket.dk>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
docs: describe behavior of relative submodule URLs
fix hang in git fetch if pointed at a 0 length bundle
Documentation: read-tree --prefix works with existing subtrees
Add MYMETA.json to perl/.gitignore
* maint-1.7.7:
docs: describe behavior of relative submodule URLs
Documentation: read-tree --prefix works with existing subtrees
Add MYMETA.json to perl/.gitignore
ExtUtils::MakeMaker generates MYMETA.json in addition to MYMETA.yml
since version 6.57_07. As it suggests, it is just meta information about
the build and is cleaned up with 'make clean', so it should be ignored.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the skeleton implementation of i18n in Git to one that can show
localized strings to users for our C, Shell and Perl programs using
either GNU libintl or the Solaris gettext implementation.
This new internationalization support is enabled by default. If
gettext isn't available, or if Git is compiled with
NO_GETTEXT=YesPlease, Git falls back on its current behavior of
showing interface messages in English. When using the autoconf script
we'll auto-detect if the gettext libraries are installed and act
appropriately.
This change is somewhat large because as well as adding a C, Shell and
Perl i18n interface we're adding a lot of tests for them, and for
those tests to work we need a skeleton PO file to actually test
translations. A minimal Icelandic translation is included for this
purpose. Icelandic includes multi-byte characters which makes it easy
to test various edge cases, and it's a language I happen to
understand.
The rest of the commit message goes into detail about various
sub-parts of this commit.
= Installation
Gettext .mo files will be installed and looked for in the standard
$(prefix)/share/locale path. GIT_TEXTDOMAINDIR can also be set to
override that, but that's only intended to be used to test Git itself.
= Perl
Perl code that's to be localized should use the new Git::I18n
module. It imports a __ function into the caller's package by default.
Instead of using the high level Locale::TextDomain interface I've
opted to use the low-level (equivalent to the C interface)
Locale::Messages module, which Locale::TextDomain itself uses.
Locale::TextDomain does a lot of redundant work we don't need, and
some of it would potentially introduce bugs. It tries to set the
$TEXTDOMAIN based on package of the caller, and has its own
hardcoded paths where it'll search for messages.
I found it easier just to completely avoid it rather than try to
circumvent its behavior. In any case, this is an issue wholly
internal Git::I18N. Its guts can be changed later if that's deemed
necessary.
See <AANLkTilYD_NyIZMyj9dHtVk-ylVBfvyxpCC7982LWnVd@mail.gmail.com> for
a further elaboration on this topic.
= Shell
Shell code that's to be localized should use the git-sh-i18n
library. It's basically just a wrapper for the system's gettext.sh.
If gettext.sh isn't available we'll fall back on gettext(1) if it's
available. The latter is available without the former on Solaris,
which has its own non-GNU gettext implementation. We also need to
emulate eval_gettext() there.
If neither are present we'll use a dumb printf(1) fall-through
wrapper.
= About libcharset.h and langinfo.h
We use libcharset to query the character set of the current locale if
it's available. I.e. we'll use it instead of nl_langinfo if
HAVE_LIBCHARSET_H is set.
The GNU gettext manual recommends using langinfo.h's
nl_langinfo(CODESET) to acquire the current character set, but on
systems that have libcharset.h's locale_charset() using the latter is
either saner, or the only option on those systems.
GNU and Solaris have a nl_langinfo(CODESET), FreeBSD can use either,
but MinGW and some others need to use libcharset.h's locale_charset()
instead.
=Credits
This patch is based on work by Jeff Epler <jepler@unpythonic.net> who
did the initial Makefile / C work, and a lot of comments from the Git
mailing list, including Jonathan Nieder, Jakub Narebski, Johannes
Sixt, Erik Faye-Lund, Peter Krefting, Junio C Hamano, Thomas Rast and
others.
[jc: squashed a small Makefile fix from Ramsay]
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This file is auto-generated by newer versions of ExtUtils::MakeMaker
(presumably starting with the version shipping with Perl 5.14). It just
contains extra information about the environment and arguments to the
Makefile-building process, and should be ignored.
Signed-off-by: Sebastian Morr <sebastian@morr.cc>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move common parts of Git::config(), Git::config_bool(), Git::config_int()
and Git::config_path() into _config_common() helper.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use --path option when calling 'git config' thus allow for pathname
expansion, e.g. a tilde.
Signed-off-by: Cord Seele <cowose@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When command_input_pipe and command_output_pipe are used as a
method of a Git::repository instance, they eventually call into
_cmd_exec method that sets up the execution environment such as
GIT_DIR, GIT_WORK_TREE environment variables and the current
working directory in the child process that interacts with the
repository.
command_bidi_pipe however didn't expect to be called as such, and
lacked all these set-up. Because of this, a program that did this
did not work as expected:
my $repo = Git->repository(Directory => '/some/where/else');
my ($pid, $in, $out, $ctx) =
$repo->command_bidi_pipe(qw(hash-object -w --stdin-paths));
This patch refactors the _cmd_exec into _setup_git_cmd_env that
sets up the execution environment, and makes _cmd_exec and
command_bidi_pipe to use it.
Note that unlike _cmd_exec that execv's a git command as an
external process, command_bidi_pipe is called from the main line
of control, and the execution environment needs to be restored
after open2() does its magic.
Signed-off-by: Masatake Osanai <unpush@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Formalize our dependency on perl 5.8, bumped from 5.6.[12]. We already
used the three-arg form of open() which was introduced in 5.6.1, but
t/t9700/test.pl explicitly depended on 5.6.2.
However git-add--interactive.pl has been failing on the 5.6 line since
it was introduced in v1.5.0-rc0~12^2~2 back in 2006 due to this open
syntax:
sub run_cmd_pipe {
my $fh = undef;
open($fh, '-|', @_) or die;
return <$fh>;
}
Which when executed dies on "Can't use an undefined value as
filehandle reference". Several of our tests also fail on 5.6 (even
more when compiled with NO_PERL_MAKEMAKER=1):
t2016-checkout-patch.sh
t3904-stash-patch.sh
t3701-add-interactive.sh
t7105-reset-patch.sh
t7501-commit.sh
t9700-perl-git.sh
Our code is bitrotting on 5.6 with no-one interested in fixing it, and
pinning us to such an ancient release of Perl is keeping us from using
useful features introduced in the 5.8 release.
The 5.6 series is now over 10 years old, and the 5.6.2 maintenance
release almost 7. 5.8 on the other hand is more than 8 years old.
All the modern Unix-like operating systems have now upgraded to it or
a later version, and 5.8 packages are available for old IRIX, AIX
Solaris and Tru64 systems.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Tor Arntsen <tor@spacetec.no>
Acked-by: Randal L. Schwartz <merlyn@stonehenge.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
PREFIX and INSTALL_BASE are mutually exclusive. If both are supplied
by INSTALL_BASE being set in PERL_MM_OPT ExtUtils::MakeMaker will
produce an error:
$ echo $PERL_MM_OPT
INSTALL_BASE=/home/avar/perl5
$ make -C perl PERL_PATH='/usr/bin/perl' prefix='/home/avar' perl.mak
make: Entering directory `/home/avar/g/git/perl'
/usr/bin/perl Makefile.PL PREFIX='/home/avar'
Only one of PREFIX or INSTALL_BASE can be given. Not both.
make: *** [perl.mak] Error 255
make: Leaving directory `/home/avar/g/git/perl'
Change the perl Makefile to work around this by explicitly unsetting
INSTALL_BASE.
INSTALL_BASE is set in PERL_MM_OPT by e.g. the popular local::lib
package, from its documentation:
eval $(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib 2>/dev/null)
Many other environments might also have set PERL_MM_OPT before
building Git. This change enables us to build in these environments.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Provide the bad directory name alongside with $!
Note: $! is set if there is "No such file or directory",
but isn't set if the file exists but is not a directory.
Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before commit d3c9634e, performing a "git svn rebase" that fetched a
change containing CRLFs corrupted the git-svn meta-data. This was
worked around in d3c9634e by setting core.autocrlf to "false" in the
per-repo config when initing the clone. However, if the config
variable was later changed, the corruption would still occur.
This patch tries to fix it while allowing core.autocrlf to be
enabled, by disabling filters when when hashing.
git-svn is currently the only call-site for hash_and_insert_object
(apart from the test-suite), so changing it should be safe.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
It appears that ExtUtils::MakeMaker versions older than 6.11 do not
implement the DESTDIR mechanism. So add a test to the generated perl.mak
to detect when DESTDIR is used along with a too old ExtUtils::MakeMaker and
abort with a message suggesting the use of NO_PERL_MAKEMAKER.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Building with prefix=/some/where and temporarily installing it to
elsewhere for tar'ing up is done with:
make prefix=/some/where
make prefix=/some/where DESTDIR=/else/where install
Make handcrafted perl/perl.mak without NO_PERL_MAKEMAKER honour DESTDIR.
Ancient ExtUtils::MakeMaker (pre 6.11?) has the same issue, but recent
versions of Perl ships with at leat 6.17; this patch does not address that
issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
So far we only set it to absolute paths in some cases which lead
to problems like wc_chdir not working.
Signed-off-by: Frank Lichtenheld <flichtenheld@astaro.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise git will use the current directory as work tree which will
lead to unexpected results if we operate in sub directory of the
work tree.
Signed-off-by: Frank Lichtenheld <flichtenheld@astaro.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This can be used in GUIs to open installed HTML documentation in the
browser.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The error message to Error::Simple() must be passed as a single argument.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The repository constructor mistakenly rewrote a Directory parameter that
Perl happens to evaluate to false (e.g. "0") to ".".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unify all
fatal: Not a git repository
error messages so they include path information.
Signed-off-by: Richard Hartmann <richih@net.in.tum.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update the usage of File::Temp->tempfile to place the temporary files
within the repository directory instead of just letting Perl decide what
directory to use, given there is a repository specified when requesting
the temporary file.
This is needed to be able to fix git-svn on msys as msysperl generates
paths with UNIX-style paths (/tmp/xxx) while the git tools expect natvie
path format (c:/..). The repository dir is stored in native format so by
using it as the base directory for temporary files we always get a
usable native full path.
Signed-off-by: Marten Svanfeldt <developer@svanfeldt.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Make it possible to write subclasses of Git.pm
Signed-off-by: Christian Jaeger <christian@jaeger.mine.nu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Perl 5.8.0 ships with File::Temp 0.13, which does not have the new()
interface introduced in 0.14, as pointed out by Tom G. Christensen.
This modifies Git.pm to use the more established tempfile() interface
and updates 'git svn' to match.
Signed-off-by: Marcus Griep <marcus@griep.us>
Acked-by: Eric Wong <normalperson@yhbt.net>
Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This will ensure that the API at large is accessible to nearly
all Perl versions, while only the temp file caching API is tied to
the File::Temp and File::Spec modules being available.
Signed-off-by: Marcus Griep <marcus@griep.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch offers a generic interface to allow temp files to be
cached while using an instance of the 'Git' package. If many
temp files are created and destroyed during the execution of a
program, this caching mechanism can help reduce the amount of
files created and destroyed by the filesystem.
The temp_acquire method provides a weak guarantee that a temp
file will not be stolen by subsequent requests. If a file is
locked when another acquire request is made, a simple error is
thrown.
Signed-off-by: Marcus Griep <marcus@griep.us>
Acked-by: Eric Wong <normalperson@yhbt.net>
Use double quotes to protect against paths which may contain spaces.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git::DESTROY calls _close_cat_blob and _close_hash_and_insert_object,
which in turn call command_close_bidi_pipe, which calls waitpid, which
alters $?. If this happens during global destruction, it may alter the
program's exit status unexpectedly. Making $? local to the function
solves the problem.
(The problem was discovered due to a failure of test #8 in
t9106-git-svn-commit-diff-clobber.sh.)
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The perl modules must be copied to blib/lib so they are available for
testing.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch also converts the good ole' git-remote.perl to use it.
It is otherwise used in the repo.or.cz machinery and I guess other
scripts might find it useful too.
Unfortunately,
git-ls-remote --heads .
is subtly different from
git-ls-remote . refs/heads/
(since the second matches anywhere in the string, not just at the
beginning) so we have to provide interface for both.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If config is called in array context, it is supposed to return all
values set for the given option key. This works for all cases except
if there is no value set at all. In that case, it wrongly returns
(undef) instead of (). This fixes the return statement so that it
returns undef in scalar context but an empty array in array context.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation of hash_object incorrectly states that it accepts a
file handle -- in fact it doesn't, and there is even a TODO comment
for this. This fixes the documentation.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recent "git-svn optimization" series introduced Git::cat_blob() subroutine
whose interface was broken in that it returned the size of the blob but
signalled an error by returning 0. You can never use an empty blob with
such an interface.
This fixes the interface to return a negative value to signal an error.
Reported by Björn Steinbrink.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These functions are more efficient ways of executing `git hash-object -w` and
`git cat-file blob` when you are dealing with many files/objects.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
command_bidi_pipe hands back the stdin and stdout file handles from the
executed command. command_close_bidi_pipe closes these handles and terminates
the process.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git var doesn't require to be called in a repository anymore,
so don't require it either.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git config itself doesn't require to be called in a repository,
so don't add arbitrary restrictions.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
DESTDIR is supposed to be overridden on 'make install' after doing
'make'. Have the automatically generated perl/perl.mak not cache the
value of DESTDIR to support that for the perl/ subdirectory also.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is mostly lifted from earlier series by Dan Zwell, but updated to
use "git config --get-color" and "git config --get-colorbool" to make it
simpler and more consistent with commands written in C.
A new configuration color.interactive variable is like color.diff and
color.status, and controls if "git-add -i" uses color.
A set of configuration variables, color.interactive.<slot>, are used to
define what color is used for the prompt, header, and help text.
For perl scripts, Git.pm provides $repo->get_color() method, which takes
the slot name and the default color, and returns the terminal escape
sequence to color the output text. $repo->get_colorbool() method can be
used to check if color is set to be used for a given operation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Integer variables can have optional 'k', 'm' or 'g' suffix.
config_int() method will return simple decimal number, taking
care of those suffixes.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn occasionally fails with no details as to what went wrong - this should help debug those situations.
Signed-off-by: Ask Bjørn Hansen <ask@develooper.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
MakeMaker supports three installation modes: perl, site, and vendor. The first
and third install manpages to $PREFIX/share/man, only site installs to
$PREFIX/man. For consistency with the rest of git, which does not make the
distinction and writes all manpages to $PREFIX/share/man, this change makes
sure that perl does too, even when it's installed in site mode.
Signed-off-by: martin f. krafft <madduck@madduck.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For reason unknown a package in ActiveState Perl 5.8.7 must implement
READLINE method differently for scalar and array context. The code
tested to work for more sane and recent version of perl (5.8.8 shipped
with Ubuntu), so maybe it was always a requirement.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time. There are a few files that need
to have trailing whitespaces (most notably, test vectors). The results
still passes the test, and build result in Documentation/ area is unchanged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch renames config_boolean() to config_bool() for consistency with
the commandline interface and because it is shorter but still obvious. ;-)
It also changes the return value from some obscure string to real Perl
boolean, allowing for clean user code.
Signed-off-by: Petr Baudis <pasky@suse.cz>
There is a mechanism PERL_PATH in the Makefile to specify path to
Perl binary, but sometimes it is convenient to let 'env' figure
out where Perl comes from, with PERL_PATH="/usr/bin/env perl".
Allowing this would make things easier to MacPorts, where we wish
to work with the MacPorts perl if it is installed, but fall back
to the system perl if it isn't.
Signed-off-by: Bryan Larsen <bryan@larsen.st>
Signed-off-by: Junio C Hamano <junkio@cox.net>
bdash (on IRC) had a problem with Git.pm (via git-svn) when his
site installation of Error.pm was older than the version we
package.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes the same issue as 8bef6204, which became an issue again
after 31d0399c.
Besides, it is not really helpful to print just "GEN " (_without_
"perl.mak").
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- print output file name for .c files
- suppress output of the names of subdirectories when make changes into them
- use GEN prefix for makefile generation in perl/
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Per Junio's suggestion we are setting 'make' to be quiet by default,
with `make V=1` available to force GNU make back to its default
behavior of showing each command it is running.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I find it difficult to see compiler warnings amongst the massive
spewing produced by GNU make as it works through our productions.
This is especially true if CFLAGS winds up being rather long, due
to a large number of -W options being enabled and due to a number
of -D options being configured/required by my platform.
By defining QUIET_MAKE (e.g. make QUIET_MAKE=YesPlease) during
compilation users will get a less verbose output, such as:
...
CC builtin-grep.c
builtin-grep.c:187: warning: 'external_grep' defined but not used
CC builtin-init-db.c
CC builtin-log.c
CC builtin-ls-files.c
CC builtin-ls-tree.c
...
The verbose (normal make) output is still the default.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
which happens if you use ActiveState Perl and a
pipe workaround specially for it.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise it tries to tie it to a scalar and complains about missing
method. Dunno why, may be ActiveState brokenness again.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also add "git" to the pipe parameters, otherwise it does not work at all, as
no git commands are usable out of git context.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
From time to time, I would get this error:
[...]
sed: -e expression #8, char 41: Unterminated `s' command
make: *** [git-add--interactive] Error 1
Turns out that the function WriteMakefile() called in Makefile.PL
outputs the message "Writing perl.mak for Git" to stdout! Thus,
the output of "make -C perl -s --no-print-directory instlibdir"
would be prefixed by that message whenever Makefile.PL was newer
than perl.mak.
This is fixed by redirecting stdout to stderr in Makefile.PL.
Signed-off-by: Johannes E. Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
While 'init-db' still is and probably will always remain a valid git
command for obvious backward compatibility reasons, it would be a good
idea to move shipped tools and docs to using 'init' instead.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier commit f848718a broke the build in perl/ directory by
allowing the Makefile.PL to overwrite the now-tracked Makefile.
Fix this by forcing Makefile.PL to produce its output in
perl.mak as the broken commit originally intended.
Signed-off-by: Junio C Hamano <junkio@cox.net>
On Cygwin + ActivateState Perl, Makefile generated with
MakeMaker is not usable because of line-endings and
back-slashes.
This teaches perl/Makefile to write a handcrafted equivalent
perl.mak file with 'make NO_PERL_MAKEMAKER=NoThanks'.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch removes Git.xs from the repository for the time being. This
should hopefully enable Git.pm to finally make its way to master.
Git.xs is not going away forever. When the Git libification makes some
progress, it will hopefully return (but most likely as an optional
component, due to the portability woes) since the performance boosts are
really important for applications like Gitweb or Cogito. It needs to go
away now since it is not really reliable in case you use it for several
repositories in the scope of a single process, and that is not possible
to fix without some either very ugly or very intrusive core changes.
Rest in peace. (While you can.)
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Makes life for binary packagers easier, as the Perl modules will
be installed inside DESTDIR.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used just the blessed() routine so steal it from Scalar/Util.pm.
Unfortunately, Scalar::Util is not bundled with older Perl versions.
This is a newer much saner blessed() version by Randal L. Schwarz.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Direct .xs routine. Note that it does not work 100% correctly when
you juggle multiple repository objects, but it is not that bad either.
The trouble is that we might reuse packs information for another
Git project; that is not an issue since Git depends on uniqueness
of SHA1 ids so if we have found the object somewhere else, it is
nevertheless going to be the same object. It merely makes object
existence detection through this method unreliable; it is duly noted
in the documentation.
At least that's how I see it, I hope I didn't overlook any other
potential problem. I tested it for memory leaks and it appears to be
doing ok.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This introduces a setup_git() function which is essentialy a (public)
backend for setup_git_env() which lets anyone specify custom sources
for the various paths instead of environment variables. Since the repositories
may get switched on the fly, this also updates code that caches paths to
invalidate them properly; I hope neither of those is a sweet spot.
It is used by Git.xs' xs__call_gate() to set up per-repository data
for libgit's consumption. No code actually takes advantage of it yet
but get_object() will in the next patches.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This accessor will retrieve value(s) of the given configuration variable.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Back in the old days, we called Git's die() from the .xs code, but we had to
hijack Perl's die() for that. Now we don't call Git's die() so no need to do
the hijacking and it silences a compiler warning.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Both of these casts _should_ be safe, since you do not want to muck around
with the version or the path anyway.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes us not include ppport.h which seems not to give us anything
real anyway; it is useful for checking for portability warts but since
Devel::PPPort is a portability wart itself, we shouldn't require it
for build. You can check for portability problems by calling make check
in perl/.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
PerlIO_*() is not portable before 5.7.3, according to ppport.h, and it's
more clear what is going on when we do it in the Perl part of the Git module
anyway.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The syntax for 'require' was wrong, and it was always failing, which
resulted in installing our own version of Error.pm anyways.
Now we used to ship our own Error.pm in the same directory, so after
fixing the syntax, 'require' always succeeds, but it does not test if
the platform has Error.pm module installed anymore. So rename the
source we ship to private-Error.pm, and install that as Error.pm when
the platform does not have one already.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm about to introduce get_object() and it will be better for consistency
if the object type always goes first. And writing 'blob' there explicitly
is not much bother.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The code is stolen from git-annotate and completely untested since
I don't have access to any Microsoft operating system now. Someone
ActiveState-savvy should look at it anyway and try to implement
the input pipe as well, if it is possible at all; also, the implementation
seems to be horribly whitespace-unsafe.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- We passed our own *.a archives as LIBS to the submake that runs
in perl/; separate LIBS and EXTLIBS and pass the latter which
tells what the system libraries are used.
- The quoting of preprocesor symbol definitions passed down to
perl/ submake was loose and we lost double quotes around
include directives. Use *_SQ to quote them properly.
- The installation location of perl/ submake is not
architecture neutral anymore, so use SITEARCH instead of
SITELIB.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch adds support for subdirectories inside of working copies;
you can specify them in the constructor either as the Directory
option (it will just get autodetected using rev-parse) or explicitly
using the WorkingSubdir option. This makes Git->repository() do the
exact same path setup and repository lookup as the Git porcelain
does.
This patch also introduces repo_path(), wc_path() and wc_subdir()
accessor methods and wc_chdir() mutator.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This gives the user a way to easily pass options to the command routines.
Currently only the STDERR option is implemented and can be used to adjust
what shall be done with error output of the called command (most usefully,
it can be used to silence it).
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rename command_pipe() to command_output_pipe(), outsource
the functionality to _command_common_pipe().
Add command_input_pipe().
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently if an external command returns error exit code, a generic exception
is thrown and there is no chance for the caller to retrieve the command's
output.
This patch introduces a Git::Error::Command exception class which is thrown
in this case and contains both the error code and the captured command output.
You can use the new git_cmd_try statement to fatally catch the exception
while producing a user-friendly message.
It also adds command_close_pipe() for easier checking of exit status of
a command we have just a pipe handle of. It has partial forward dependency
on the next patch, but basically only in the area of documentation.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
So far, errors just killed the whole program and in case of an error
inside of libgit it would be totally uncatchable. This patch makes
Git.pm throw standard Perl exceptions instead. In the future we might
subclass Error to Git::Error or something but for now Error::Simple
is more than enough.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I have been thinking about how to do the error reporting the best
way and after scraping various overcomplicated concepts, I have
decided that by far the most elegant way is to throw Error exceptions;
the closest sane alternative is to catch the dies in Git.pm by
enclosing the calls in eval{}s and that's really _quite_ ugly.
The only "small" trouble is that Error.pm turns out sadly not to be
part of the standard distribution, and installation from CPAN is
a bother, especially if you can't install it system-wide. But since
it is very small, I've decided to just bundle it.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
