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>
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>
