user/sven/git.git/git-archimport.perl, branch v1.8.0.2

perl: use "use warnings" instead of -w

2010-09-27T19:37:56Z

Change the Perl scripts to turn on lexical warnings instead of setting the global $^W variable via the -w switch. The -w sets warnings for all code that interpreter runs, while "use warnings" is lexically scoped. The former is probably not what the authors wanted. As an auxiliary benefit it's now possible to build Git with: PERL_PATH='/usr/bin/env perl' Which would previously result in failures, since "#!/usr/bin/env perl -w" doesn't work as a shebang. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

perl: bump the required Perl version to 5.8 from 5.6.[21]

2010-09-27T19:37:41Z

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 Acked-by: Tor Arntsen Acked-by: Randal L. Schwartz Signed-off-by: Junio C Hamano

Make usage strings dash-less

2008-07-13T21:12:48Z

When you misuse a git command, you are shown the usage string. But this is currently shown in the dashed form. So if you just copy what you see, it will not work, when the dashed form is no longer supported. This patch makes git commands show the dash-less version. For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh generates a dash-less usage string now. Signed-off-by: Stephan Beyer Signed-off-by: Junio C Hamano

Make git-archimport log entries more consistent

2007-08-31T02:22:02Z

When appending the "git-archimport-id:" line to the end of log entries, git-archimport would use two blank lines as a separator when there was no body in the arch log (only a Summary: line), and zero blank lines when there was a body (making it hard to see the break between the actual log message and the git-archimport-id: line). This patch makes git-archimport generate one blank line as a separator in all cases. Signed-off-by: Junio C Hamano

War on whitespace

2007-06-07T07:04:01Z

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

git-archimport: allow remapping branch names

2007-03-07T18:30:22Z

This patch adds support to archimport for remapping the branch names to match those used in git more closely. This is useful for projects that migrate to git (as opposed to users that want to use git on Arch-based projects). For example, one can choose an Arch branch name and call it "master". The new command-line syntax works even if there is a colon in a branch name, since only the part after the last colon is taken to be the git name (git does not allow colons in branch names). The new feature is implemented so that archives rotated every year can also be remapped into a single git archive. Signed-off-by: Paolo Bonzini Signed-off-by: Junio C Hamano

git-archimport: support empty summaries, put summary on a single line.

2007-02-28T20:38:08Z

Don't fail if the summary line in an arch commit is empty. In this case, try to use the first line in the commit message followed by an ellipsis. In addition, if the summary is multi-line, it is joined on a single line. Signed-off-by: Junio C Hamano

git-archimport: initial import needs empty directory

2007-02-05T01:05:16Z

git-archimport should better refuse to start an initial import if the current directory is not empty. (http://bugs.debian.org/400508) Signed-off-by: Gerrit Pape Signed-off-by: Junio C Hamano

use 'init' instead of 'init-db' for shipped docs and tools

2007-01-12T21:36:16Z

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 Signed-off-by: Junio C Hamano

Fix more typos, primarily in the code

2006-07-10T07:36:44Z

The only visible change is that git-blame doesn't understand "--compability" anymore, but it does accept "--compatibility" instead, which is already documented. Signed-off-by: Pavel Roskin Signed-off-by: Junio C Hamano