* [PATCH 2/3] 'git-svndump'
From: Sergey Yanovich @ 2007-06-18 12:14 UTC (permalink / raw)
To: git, normalperson, Matthieu.Moy; +Cc: Sergey Yanovich
In-Reply-To: <4e79874760c3773448d886608d6db7bbda3c97f2.1182168501.git.ynvich@gmail.com>
Signed-off-by: Sergey Yanovich <ynvich@gmail.com>
---
Documentation/git-svndump.txt | 106 +++++++++++++++++++++++++++++++++++++++++
git-svndump-init.sh | 85 +++++++++++++++++++++++++++++++++
git-svndump-sync.sh | 85 +++++++++++++++++++++++++++++++++
3 files changed, 276 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-svndump.txt
create mode 100755 git-svndump-init.sh
create mode 100755 git-svndump-sync.sh
diff --git a/Documentation/git-svndump.txt b/Documentation/git-svndump.txt
new file mode 100644
index 0000000..9caf02b
--- /dev/null
+++ b/Documentation/git-svndump.txt
@@ -0,0 +1,106 @@
+git-svndump(1)
+==========
+
+NAME
+----
+git-svndump - Exporting from git to a single Subversion branch
+
+SYNOPSIS
+--------
+'git-svndump' <command> [options] [arguments]
+
+DESCRIPTION
+-----------
+git-svndump is essentially a wrapper around 'git-svn commit-diff'. It
+will work only when it is the sole method of committing to the
+Subversion repository.
+
+It is designed to export a linear git branch. However, thanks to the way
+'git' handles source code, 'git-svndump' seems to work in other
+conditions. For example, when branches are switched or merged.
+
+git-svndump provides a solution when you need to export you source code
+in Subversion format (who would need this with git :), but do not want
+to have all the shackles that 'git-svn init' puts on your repository.
+
+COMMANDS
+--------
+--
+
+'init'::
+ Initialize an existing git repository with additional
+ metadata directories for git-svndump. The Subversion URL
+ must be specified as the first non-optional command-line
+ argument. 'git' tree-ish that correspond to the HEAD of
+ that Subversion URL may be specified as the second optional
+ command-line argument.
+
+-f;;
+ git-svndump normally declines to reinitialize the same git
+ repository. With the '-f' option that behavior is overridden.
+
+-A<filename>;;
+--authors-file=<filename>;;
+ The filename is stored, and provided as an argument to 'git-svn'
+ on calls of 'git-svndump sync'.
+
+'sync'::
+ Commit git revisions to the Subversion repository. If a git
+ <tree-ish> is specified as an optional command-line argument,
+ than all commits between the last 'sync' and that <tree-ish> are
+ send. If the argument is omitted, the HEAD of the active branch
+ is used.
+
+-A<filename>;;
+--authors-file=<filename>;;
+ The filename is provided as an argument to 'git-svn'.
+
+--
+
+BASIC EXAMPLE
+--------------
+
+Contributing to a Subversion repository:
+
+------------------------------------------------------------------------
+# Create your git repository, do some work and commit your changes
+# You are working on a computer A (git.foo.org)
+# Prepare your git repository for export (you are in the top dir)
+ git-svndump-init -A .auth http://svn.foo.org/project
+# Commit the whole branch:
+ git-svndump-sync
+# Now you go a different computer B
+# Clone a git repo:
+ git clone git.foo.org:/path/to/project.git
+# Enter the newly cloned directory:
+ cd project
+# Immediately prepare the new repository for export
+ git-svndump-init -A .auth http://svn.foo.org/project HEAD
+# Do some work and commit both locally and to A:
+ git commit ...
+ git push
+# Commit the new work:
+ git-svndump-sync
+# Now you return to the computer A
+# Reinit your repository for export!
+ git-svndump-init -f -A .auth http://svn.foo.org/project HEAD
+------------------------------------------------------------------------
+
+BUGS
+----
+
+The HEAD of the Subversion repository is not tracked. If your
+git-svndump repository goes out-of-sync with the Subversion mirror,
+the latter will most probably be corrupted.
+
+SEE ALSO
+--------
+gitlink:git-svn[1]
+
+Author
+------
+Written by Sergey Yanovich <ynvich@gmail.com>.
+
+Documentation
+-------------
+Written by Sergey Yanovich <ynvich@gmail.com>.
diff --git a/git-svndump-init.sh b/git-svndump-init.sh
new file mode 100755
index 0000000..4cf61b8
--- /dev/null
+++ b/git-svndump-init.sh
@@ -0,0 +1,85 @@
+#!/bin/sh
+
+usage()
+{
+ cat << EOF
+Usage: git-svndump-init [-f] subversion-url [<commit>]
+ subversion-url -- URL of the subversion repository to which you want
+ to dump the current git repository
+ <commit> -- git <commit> that correspond to the latest revision
+ in the subversion repository
+OPTIONS
+ -f
+ do not stop, if the git repository is already initialized.
+EOF
+ exit 1
+}
+
+if test x$GIT_DIR = x ; then
+ if test -d ./.git ; then
+ GIT_DIR=`pwd`/.git
+ fi
+fi
+
+if test ! -d $GIT_DIR ; then
+ usage
+fi
+
+if test x$1 = x ; then
+ usage
+fi
+
+if test x$1 = x-f; then
+ shift
+ rm -rf $GIT_DIR/svndump
+fi
+
+if test -d $GIT_DIR/svndump ; then
+ echo git-svndump-init: error: This git repository is already initialized
+ exit 1
+fi
+
+mkdir $GIT_DIR/svndump
+if test ! -d $GIT_DIR/svndump ; then
+ echo git-svndump-init: error: Failed to create $GIT_DIR/svndump
+ exit 1
+fi
+
+rev=`svn info $1 >$GIT_DIR/svndump/error.log`
+if test $? -ne 0 ; then
+ echo git-svndump-init: error: While quering $1
+ rm -rf $GIT_DIR/svndump
+ exit 1
+fi
+
+rev=`cat $GIT_DIR/svndump/error.log | sed -ne "/Revision/s/.* //p"`
+rm $GIT_DIR/svndump/error.log
+
+if test x$rev = x ; then
+ echo "git-svndump-init: error: Cannot determine the latest revision"
+ echo " at $1"
+ rm -rf $GIT_DIR/svndump
+ exit 1
+fi
+
+if test $rev -eq 0 ; then
+ mkdir -p $GIT_DIR/svndump/import && cd $GIT_DIR/svndump/import &&
+ svn import . $1 -m "Initial import by git-svndump"
+ if test $? -ne 0 ; then
+ echo "git-svndump-init: error: Failed to init $1"
+ rm -rf $GIT_DIR/svndump
+ exit 1
+ fi
+ rmdir $GIT_DIR/svndump/import
+fi
+
+echo "$1" > $GIT_DIR/svndump/url
+
+if test x$2 != x ; then
+ commit=`GIT_DIR=$GIT_DIR git-rev-list --max-count=1 $2`
+ if test $? -ne 0 ; then
+ echo "git-svndump-init: warning: Bad commit $2 ignored"
+ else
+ echo $commit >> $GIT_DIR/svndump/last
+ fi
+fi
diff --git a/git-svndump-sync.sh b/git-svndump-sync.sh
new file mode 100755
index 0000000..e1c04e1
--- /dev/null
+++ b/git-svndump-sync.sh
@@ -0,0 +1,85 @@
+#!/bin/sh
+
+usage()
+{
+ cat << EOF
+Usage: git-svndump-sync [<commit>]
+ <commit> -- git <commit> that correspond to the latest revision
+ to be dumped to the subversion repository
+EOF
+ exit 1
+}
+
+if test x$GIT_DIR = x ; then
+ if test -d ./.git ; then
+ GIT_DIR=`pwd`/.git
+ fi
+fi
+
+if test ! -d $GIT_DIR ; then
+ usage
+fi
+
+if test ! -d $GIT_DIR/svndump ; then
+ echo "git-svndump-sync: error: This git repository is not initialized"
+ echo " Run git-svndump-init first"
+ exit 1
+fi
+
+if test ! -f $GIT_DIR/svndump/url ; then
+ echo "git-svndump-sync: error: Cannot read url"
+ exit 1
+fi
+
+url=`cat $GIT_DIR/svndump/url`
+rev=`svn info $url >$GIT_DIR/svndump/error.log`
+if test $? -ne 0 ; then
+ echo git-svndump-sync: error: While quering $url
+ rm -rf $GIT_DIR/svndump/error.log
+ exit 1
+fi
+
+rev=`cat $GIT_DIR/svndump/error.log | sed -ne "/Revision/s/.* //p"`
+rm $GIT_DIR/svndump/error.log
+
+if test x$rev = x ; then
+ echo "git-svndump-init: error: Cannot determine the latest revision"
+ echo " at $url"
+ exit 1
+fi
+
+if test x$1 = x ; then
+ commit=HEAD
+else
+ commit=`GIT_DIR=$GIT_DIR git-rev-list --max-count=1 $1`
+ if test $? -ne 0 ; then
+ echo "git-svndump-sync: error: Bad commit '$1'"
+ exit 1
+ fi
+fi
+
+start=""
+last=0000000000000000000000000000000000000000
+if test -f $GIT_DIR/svndump/last ; then
+ last=`cat $GIT_DIR/svndump/last`
+ start=^`GIT_DIR=$GIT_DIR git-rev-list --max-count=1 $last`
+ if test $? -ne 0 ; then
+ echo "git-svndump-sync: warning: Ignoring bad commit '$last'"
+ start=""
+ last=0000000000000000000000000000000000000000
+ fi
+fi
+
+list=`GIT_DIR=$GIT_DIR git-rev-list $commit $start`
+
+diffs=""
+for c in $list ; do
+ diffs="$c $diffs"
+done
+
+for c in $diffs ; do
+ GIT_DIR=$GIT_DIR git-svn commit-diff -r$rev $last $c $url
+ echo "$c" > $GIT_DIR/svndump/last
+ last=$c
+ let rev++
+done
--
1.5.2.1
^ permalink raw reply related
* [PATCH 3/3] Fix large-scale exports by 'git-svndump'
From: Sergey Yanovich @ 2007-06-18 12:14 UTC (permalink / raw)
To: git, normalperson, Matthieu.Moy; +Cc: Sergey Yanovich
In-Reply-To: <4e79874760c3773448d886608d6db7bbda3c97f2.1182168501.git.ynvich@gmail.com>
* Split revision list using 'tail' shell command.
* Wrap multiple list generation in an endless cycle with 'while true'.
Exit from cycle when the current list is empty.
* Improve handling of merges by adding '--no-merges --topo-order'i
arguments to the list generating command.
Signed-off-by: Sergey Yanovich <ynvich@gmail.com>
---
git-svndump-sync.sh | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/git-svndump-sync.sh b/git-svndump-sync.sh
index e1c04e1..516edaf 100755
--- a/git-svndump-sync.sh
+++ b/git-svndump-sync.sh
@@ -70,7 +70,14 @@ if test -f $GIT_DIR/svndump/last ; then
fi
fi
-list=`GIT_DIR=$GIT_DIR git-rev-list $commit $start`
+while true ; do
+
+list=`GIT_DIR=$GIT_DIR git-rev-list --no-merges --topo-order $commit $start |
+tail -n 8`
+
+if test -z "$list" ; then
+ exit 0
+fi
diffs=""
for c in $list ; do
@@ -79,7 +86,14 @@ done
for c in $diffs ; do
GIT_DIR=$GIT_DIR git-svn commit-diff -r$rev $last $c $url
+ if test $? -ne 0 ; then
+ exit $?
+ fi
echo "$c" > $GIT_DIR/svndump/last
last=$c
let rev++
done
+
+start=^$last
+
+done
--
1.5.2.1
^ permalink raw reply related
* git tool to keep a subversion mirror
From: Sergey Yanovich @ 2007-06-18 12:14 UTC (permalink / raw)
To: git, normalperson, Matthieu.Moy
On 6/18/07, Sergey Yanovich <ynvich@gmail.com> wrote:
> However, '--chain-reply-to' seems to have failed. The patches (2 of
> them) came as top-level posts. Or I may be doing something wrong.
I should have used '--thread' and '--in-reply-to=' when I was formating
the patches. It should be correctied this time.
Sorry for being akward :)
--
Sergey Yanovich
^ permalink raw reply
* [PATCH 1/3] Accept root <tree-ish> in 'git-svn commit-diff'
From: Sergey Yanovich @ 2007-06-18 12:14 UTC (permalink / raw)
To: git, normalperson, Matthieu.Moy; +Cc: Sergey Yanovich
In-Reply-To: <vpqhcp6b85c.fsf@bauges.imag.fr>
Signed-off-by: Sergey Yanovich <ynvich@gmail.com>
---
git-svn.perl | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 50128d7..8ad291b 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2572,7 +2572,12 @@ sub generate_diff {
}
push @diff_tree, '--find-copies-harder' if $_find_copies_harder;
push @diff_tree, "-l$_rename_limit" if defined $_rename_limit;
- push @diff_tree, $tree_a, $tree_b;
+ if ($tree_a eq '0000000000000000000000000000000000000000') {
+ push @diff_tree, '--root';
+ } else {
+ push @diff_tree, $tree_a;
+ }
+ push @diff_tree, $tree_b;
my ($diff_fh, $ctx) = command_output_pipe(@diff_tree);
local $/ = "\0";
my $state = 'meta';
@@ -2606,6 +2611,8 @@ sub generate_diff {
}
$x->{file_b} = $_;
$state = 'meta';
+ } elsif ($state eq 'meta' && $_ eq $tree_b &&
+ $tree_a eq '0000000000000000000000000000000000000000') {
} else {
croak "Error parsing $_\n";
}
--
1.5.2.1
^ permalink raw reply related
* Re: [PATCH] mergetool: make Apple's FileMerge available as a merge_tool
From: Scott Lamb @ 2007-06-18 9:39 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Theodore Tso, Git Mailing List
In-Reply-To: <42FEB11E-426D-4B44-9E7E-0E35032CB1B0@zib.de>
Steffen Prohaska wrote:
>
> On Jun 17, 2007, at 8:12 PM, Theodore Tso wrote:
>> Do you know of a way of determining whether or not under MacOS X, a
>> program can easily determine whether or not the user is sitting in
>> front of the graphical display, as opposed to coming in via an SSH
>> connection?
>
> this might do the job:
>
> --- SNIP ---
> #! /bin/sh
>
> pid=$$
>
> while [ $pid -ne 1 ] ; do
> command=$(ps -p $pid | tail -n 1 | cut -b 27-)
> echo $command | grep -q sshd && { echo "ssh" ; exit ; }
> echo $command | grep -q Terminal && { echo "local" ; exit ; }
> pid=$(ps -O ppid -p $pid | tail -n 1 | cut -b 6-11)
> done
>
> echo "unknown"
> --- SNIP ---
I propose a simpler test:
if [ -n "$TERM_PROGRAM" ]; then
echo local
else
echo remote
fi
This environment variable seems to be set by Terminal.app and even two
alternatives I just tried (iTerm.app and GLterm.app). It's not
transmitted across ssh unless you stick an AcceptEnv in sshd_config.
About the only time it would fail is logging in via local xterm. I'd
guess few people do that, and determining if xterm is local or not seems
infeasible - the best I've got is examining DISPLAY, but where do you
draw the line between :0.0 or localhost:0 (probably local), foobar:0
(probably remote), and :10 (probably remote via ssh forwarding)? I'd
rather not try.
--
Scott Lamb <http://www.slamb.org/>
^ permalink raw reply
* Re: Stupid quoting...
From: David Kastrup @ 2007-06-18 8:00 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <f51irh$shq$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> David Kastrup wrote:
>
>> what is the point in quoting file names and their characters in
>> git-diff's output?
>
> 7-bit email.
I think it can be reasonably safely assumed that people using 8-bit
characters in file names will not refrain from using them in the files
themselves: file names usually are chosen descriptive of the contents,
and so rarely are in a different language. So I don't see what
quoting such characters in file names is supposed to buy with regard
to diff output in 7-bit email.
--
David Kastrup
^ permalink raw reply
* [PATCH 3/3] Fix large-scale exports by 'git-svndump'
From: Sergey Yanovich @ 2007-06-18 7:54 UTC (permalink / raw)
To: git, normalperson; +Cc: Sergey Yanovich
* Split revision list using 'tail' shell command.
* Wrap multiple list generation in an endless cycle with 'while true'.
Exit from cycle when the current list is empty.
* Improve handling of merges by adding '--no-merges --topo-order'i
arguments to the list generating command.
Signed-off-by: Sergey Yanovich <ynvich@gmail.com>
---
git-svndump-sync.sh | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/git-svndump-sync.sh b/git-svndump-sync.sh
index e1c04e1..516edaf 100755
--- a/git-svndump-sync.sh
+++ b/git-svndump-sync.sh
@@ -70,7 +70,14 @@ if test -f $GIT_DIR/svndump/last ; then
fi
fi
-list=`GIT_DIR=$GIT_DIR git-rev-list $commit $start`
+while true ; do
+
+list=`GIT_DIR=$GIT_DIR git-rev-list --no-merges --topo-order $commit $start |
+tail -n 8`
+
+if test -z "$list" ; then
+ exit 0
+fi
diffs=""
for c in $list ; do
@@ -79,7 +86,14 @@ done
for c in $diffs ; do
GIT_DIR=$GIT_DIR git-svn commit-diff -r$rev $last $c $url
+ if test $? -ne 0 ; then
+ exit $?
+ fi
echo "$c" > $GIT_DIR/svndump/last
last=$c
let rev++
done
+
+start=^$last
+
+done
--
1.5.2.1
^ permalink raw reply related
* Re: git tool to keep a subversion mirror
From: Sergey Yanovich @ 2007-06-18 6:42 UTC (permalink / raw)
To: git, normalperson, Matthieu Moy
In-Reply-To: <vpqhcp6b85c.fsf@bauges.imag.fr>
Matthieu Moy wrote:
>> which is corrected by an attached patch.
>
> I believe you forgot it then ... ;-)
>
Absolutely right. Forgot to add a dir in the end. But I noticed that,
and send a catch-up:
git-send-email --to git () vger . kernel.org --to normalperson ()
yhbt.net --chain-reply-to --subject "git tool to keep a subversion
mirror" --compose --in-reply-to 11821061823423-git-send-email-ynvich ()
gmail.com /tmp/out/
Here, I replace @ with ' () ' in the above for some anti-bot protection.
However, '--chain-reply-to' seems to have failed. The patches (2 of
them) came as top-level posts. Or I may be doing something wrong.
--
Sergey Yanovich
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.2.2
From: Arkadiusz Miskiewicz @ 2007-06-18 6:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070618062902.GL18491@spearce.org>
On Monday 18 of June 2007, Shawn O. Pearce wrote:
> Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
> > On Monday 18 of June 2007, Shawn O. Pearce wrote:
> > > Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
> > > > * FAIL 16: corrupt a pack and see if verify catches
> > > > cat test-1-${packname_1}.idx >test-3.idx &&
> > > > cat test-2-${packname_2}.pack >test-3.pack &&
> > >
> > > Hmm. That is t5300-pack-objects.sh.
> >
> > If anyone is interested in debugging that problem then I can give ssh
> > access to this machine.
>
> How about we start with the output of:
>
> cd t && ./t5300-pack-objects.sh -v
>
> ? That should be a lot more verbose, as it will include the
> commands we are running and their stdout/stderr. Sometimes fun
> details about broken tools can be easily obtained from that output.
The reason was... missing /dev/zero! :-) Mystery solved, thanks!
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.2.2
From: Shawn O. Pearce @ 2007-06-18 6:29 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: Junio C Hamano, git
In-Reply-To: <200706180821.59582.arekm@maven.pl>
Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
> On Monday 18 of June 2007, Shawn O. Pearce wrote:
> > Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
> > > * FAIL 16: corrupt a pack and see if verify catches
> > > cat test-1-${packname_1}.idx >test-3.idx &&
> > > cat test-2-${packname_2}.pack >test-3.pack &&
> >
> > Hmm. That is t5300-pack-objects.sh.
>
> If anyone is interested in debugging that problem then I can give ssh access
> to this machine.
How about we start with the output of:
cd t && ./t5300-pack-objects.sh -v
? That should be a lot more verbose, as it will include the
commands we are running and their stdout/stderr. Sometimes fun
details about broken tools can be easily obtained from that output.
--
Shawn.
^ permalink raw reply
* Re: git-diff-index -C problem
From: Shawn O. Pearce @ 2007-06-18 6:26 UTC (permalink / raw)
To: Govind Salinas; +Cc: git
In-Reply-To: <69b0c0350706172248l6343e4c6yfd36ced8230a11ef@mail.gmail.com>
Govind Salinas <govindsalinas@gmail.com> wrote:
> I am writing a porcelain for git and I have been playing with
> git-diff-index. I noticed that if i copy a file and git-add the copy
> it shows the file added, as i expect...
>
> But then if i then say git-add on the original file, i expect that -C
> would check that file to see if it was copied, it does not. If i
> touch the file, then git detects the copy, so git-add is not forcing
> git to consider the file modified.
Oddly enough if you add --find-copies-harder Git does actually
find the copy then, without needing to make the file stat-dirty
in the index.
$ rm -rf foo;mkdir foo;cd foo;git init
Initialized empty Git repository in .git/
$ echo hello >a;git add a; git commit -m a
Created initial commit 9d2537b: a
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
$ cp a b;git add b
$ git diff-index --abbrev HEAD
:000000 100644 0000000... ce01362... A b
$ git diff-index --abbrev -C HEAD
:000000 100644 0000000... ce01362... A b
$ git diff-index --abbrev -C --find-copies-harder HEAD
:100644 100644 ce01362... ce01362... C100 a b
$ touch a
$ git diff-index --abbrev -C HEAD
:100644 100644 ce01362... 0000000... M a
:100644 100644 ce01362... ce01362... C100 a b
I *think* the reason this happens is because -C means to find a copy
among the other modified files. Because "a" was not modified (unless
it is stat-dirty or otherwise modified) then "b" is not a copy of it.
The --find-copies-harder makes us also look at the unmodified files,
and there we find the copy.
Indeed, the documentation says exactly that:
--find-copies-harder::
For performance reasons, by default, `-C` option finds copies only
if the original file of the copy was modified in the same
changeset. This flag makes the command
inspect unmodified files as candidates for the source of
copy. This is a very expensive operation for large
projects, so use it with caution. Giving more than one
`-C` option has the same effect.
So what you are seeing is actually as designed, and documented.
--
Shawn.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.2.2
From: Arkadiusz Miskiewicz @ 2007-06-18 6:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070618034322.GI18491@spearce.org>
On Monday 18 of June 2007, Shawn O. Pearce wrote:
> Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
> > On Sunday 17 of June 2007, Junio C Hamano wrote:
> > > The latest maintenance release GIT 1.5.2.2 is available at the
> > > usual places:
[...]
> > Should git testsuite (make test) go without any problem? (I'm asking
> > because some projects have test suites where some tests are expected to
> > fail).
>
[...]
>
> > * FAIL 16: corrupt a pack and see if verify catches
> > cat test-1-${packname_1}.idx >test-3.idx &&
> > cat test-2-${packname_2}.pack >test-3.pack &&
>
> Hmm. That is t5300-pack-objects.sh. Something is really fishy
> if that test failed. We destroy a packfile and then look to see
> if the SHA-1 hash detects the change. It always does. So uh,
> what's up with your hardware that it doesn't fail?
There is no problems known with this hardware (kernel builds are frequently
done on it and no problem occured so far). Test suite fails in the same place
each time I'm running it.
> I just built 1.5.2.2 on one of my Gentoo Linux amd64 systems and I'm
> not seeing any failures from the test suite. Not that I expected
> to find any; Linux amd64 is popular enough that a number of people
> run it.
Not all have the same enviroment.
coreutils-6.9-2.x86_64
curl-7.16.2-1.x86_64
diffutils-2.8.7-4.x86_64
expat-2.0.0-3.x86_64
findutils-4.2.31-1.x86_64
gcc-4.2.0-6.x86_64
glibc-2.6-1.i686
glibc-2.6-1.x86_64
grep-2.5.1a-2.x86_64
openssl-0.9.8e-4.x86_64
perl-5.8.8-11.x86_64
python-2.5.1-2.x86_64
sed-4.1.5-2.x86_64
zlib-1.2.3-4.x86_64
If anyone is interested in debugging that problem then I can give ssh access
to this machine.
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* git-diff-index -C problem
From: Govind Salinas @ 2007-06-18 5:48 UTC (permalink / raw)
To: git
I am writing a porcelain for git and I have been playing with
git-diff-index. I noticed that if i copy a file and git-add the copy
it shows the file added, as i expect...
But then if i then say git-add on the original file, i expect that -C
would check that file to see if it was copied, it does not. If i
touch the file, then git detects the copy, so git-add is not forcing
git to consider the file modified.
I would be happy if there was a way that I could tell git that a file
was modified for this purpose. Otherwise I will have to open/close a
file in which the user may be working, which I shouldn't do from my
app (windows problem modifying open docs). Maybe make "git-add -f" do
that?
Thanks,
Govind.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.2.2
From: Shawn O. Pearce @ 2007-06-18 3:43 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: Junio C Hamano, git
In-Reply-To: <200706171230.37659.arekm@maven.pl>
Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
> On Sunday 17 of June 2007, Junio C Hamano wrote:
> > The latest maintenance release GIT 1.5.2.2 is available at the
> > usual places:
> >
> > http://www.kernel.org/pub/software/scm/git/
> >
> > git-1.5.2.2.tar.{gz,bz2} (tarball)
> > git-htmldocs-1.5.2.2.tar.{gz,bz2} (preformatted docs)
> > git-manpages-1.5.2.2.tar.{gz,bz2} (preformatted docs)
> > RPMS/$arch/git-*-1.5.2.2-1.$arch.rpm (RPM)
>
> Should git testsuite (make test) go without any problem? (I'm asking because
> some projects have test suites where some tests are expected to fail).
No, our test suite should always pass. Junio does not ship a release
of Git where the test suite fails on his standard systems. We have
a lot of users running the current `master` and `next` branches on
a lot of different platforms, so usually platform specific breakages
are caught relatively early, before a release gets made.
We do have tests we expect to fail, but then the test suite has an
inversion in it. That is the test only passes if the underlying
operation failed. ;-)
> I have 4 failures on amd64/linux and this git release:
...
> * FAIL 16: corrupt a pack and see if verify catches
> cat test-1-${packname_1}.idx >test-3.idx &&
> cat test-2-${packname_2}.pack >test-3.pack &&
Hmm. That is t5300-pack-objects.sh. Something is really fishy
if that test failed. We destroy a packfile and then look to see
if the SHA-1 hash detects the change. It always does. So uh,
what's up with your hardware that it doesn't fail?
I just built 1.5.2.2 on one of my Gentoo Linux amd64 systems and I'm
not seeing any failures from the test suite. Not that I expected
to find any; Linux amd64 is popular enough that a number of people
run it.
--
Shawn.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.2.2
From: Shawn O. Pearce @ 2007-06-18 3:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vodjf1gxl.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> GIT v1.5.2.2 Release Notes
> ==========================
>
> Fixes since v1.5.2.1
> --------------------
>
> * Usability fix
>
> - git-gui is shipped with its updated blame interface. It is
> rumored that the older one was not just unusable but was
> active health hazard, but this one is actually pretty.
> Please see for yourself.
Usability fix? More like finally implemented! _Now_ we can start
to work on improving its usability. ;-)
--
Shawn.
^ permalink raw reply
* [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Frank Lichtenheld @ 2007-06-17 23:25 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Jakub Narebski, Frank Lichtenheld
In-Reply-To: <f2t6na$5bi$1@sea.gmane.org>
Use \n as delimiter between key and value and \0 as
delimiter after each key/value pair. This should be
easily parsable output.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
builtin-config.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
Note the FIXME. Does anyone remember the reason why --get-regexp
and --list use different output format?
On Tue, May 22, 2007 at 12:37:57AM +0200, Jakub Narebski wrote:
> Frank Lichtenheld wrote:
> > On Mon, May 21, 2007 at 09:54:23PM +0200, Jan Hudec wrote:
> >> KEY <TAB> VALUE <NUL>
> > Both subsection names and values can contain <TAB> characters, so the
> > latter isn't possible.
> But neither subsection names (even [section "subsection"] style) not key
> names cannot contain newline <LF>. I.e.
> KEY <LF> VALUE <NUL>
diff --git a/builtin-config.c b/builtin-config.c
index b2515f7..bed2722 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -2,7 +2,7 @@
#include "cache.h"
static const char git_config_set_usage[] =
-"git-config [ --global | --system ] [ --bool | --int ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --remove-section name | --list";
+"git-config [ --global | --system ] [ --bool | --int ] [ -z | --null ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --remove-section name | --list";
static char *key;
static regex_t *key_regexp;
@@ -12,14 +12,16 @@ static int use_key_regexp;
static int do_all;
static int do_not_match;
static int seen;
+static char delim = '=';
+static char term = '\n';
static enum { T_RAW, T_INT, T_BOOL } type = T_RAW;
static int show_all_config(const char *key_, const char *value_)
{
if (value_)
- printf("%s=%s\n", key_, value_);
+ printf("%s%c%s%c", key_, delim, value_, term);
else
- printf("%s\n", key_);
+ printf("%s%c", key_, term);
return 0;
}
@@ -39,6 +41,7 @@ static int show_config(const char* key_, const char* value_)
return 0;
if (show_keys)
+ /* FIXME: not useful with --null */
printf("%s ", key_);
if (seen && !do_all)
dup_error = 1;
@@ -54,7 +57,7 @@ static int show_config(const char* key_, const char* value_)
key_, vptr);
}
else
- printf("%s\n", vptr);
+ printf("%s%c", vptr, term);
return 0;
}
@@ -155,6 +158,10 @@ int cmd_config(int argc, const char **argv, const char *prefix)
}
else if (!strcmp(argv[1], "--system"))
setenv("GIT_CONFIG", ETC_GITCONFIG, 1);
+ else if (!strcmp(argv[1], "--null") || !strcmp(argv[1], "-z")) {
+ term = '\0';
+ delim = '\n';
+ }
else if (!strcmp(argv[1], "--rename-section")) {
int ret;
if (argc != 4)
--
1.5.2.1
^ permalink raw reply related
* Re: StGIT vs. guilt: What's the difference?
From: Yann Dirson @ 2007-06-17 22:28 UTC (permalink / raw)
To: Josef Sipek
Cc: Catalin Marinas, Karl Hasselström, Steven Grimm,
'git'
In-Reply-To: <20070617035923.GI7025@filer.fsl.cs.sunysb.edu>
On Sat, Jun 16, 2007 at 11:59:23PM -0400, Josef Sipek wrote:
> > Well, people may not like python, but IMHO it is a lot easier to learn
> > it if you don't know it (that's what I did, although I did not start
> > from zero), than writing a robust and maintainable software of even
> > moderate complexity in shell script. Shell script may be good for
> > prototyping or gluing tools in a simple way, but for advanced sofware
> > on which to rely to store my own data, it is just not really suited.
>
> So, why do you use git? ;)
There is no such problem in git, since only some porcelain commands are
still written in shell - and anyway C rewrites are quite fashionable those
days ;)
Best regards,
--
Yann.
^ permalink raw reply
* Re: GIT_DIR question
From: Matthias Lederhofer @ 2007-06-17 21:52 UTC (permalink / raw)
To: Yakov Lerner; +Cc: git
In-Reply-To: <f36b08ee0706170834m464ce57dl3fd5b549b23abb16@mail.gmail.com>
Yakov Lerner <iler.ml@gmail.com> wrote:
> I wanted to create cloned repo, but with metaninfo separately from data.
> I cloned the repo ( git-clone ~/repo ~/x) ,
> then I moved ~/x/.git to different place (mv ~/x/.git ~/git);
> then exported GIT_DIR=~/git; then
> cd ~/x;
> But now 'git status' says 'fatal: runstatus must be run in a work tree' .
> Why ?
>
> 'ls $GIT_DIR' shows
> FETCH_HEAD HEAD ORIG_HEAD branches config
> description hooks index info logs objects refs
> This is ok, no ?
With current git you have to name the repository directory '.git' to
use it with a working tree. Some commands work even though the
repository is named differently, others don't.
In pu is a patch series by me which changes this. First of all the
core.bare option is used all the time, the directory name of the
repository does not matter if core.bare is specified. Additionally
you can specify the working tree through the config option
core.worktree or the environment variable GIT_WORK_TREE. With this
you can even work in a subdirectory of the working tree. But this is
only in pu and it is not decided yet if this will make it into master,
even though I hope it will. Perhaps more people asking for this helps :)
^ permalink raw reply
* Re: [PATCH] cvsserver: fix legacy cvs client and branch rev issues
From: Martin Langhoff @ 2007-06-17 21:27 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Dirk Koopman, git
In-Reply-To: <20070617103744.GE1828@planck.djpig.de>
On 6/17/07, Frank Lichtenheld <frank@lichtenheld.de> wrote:
> On Sun, Jun 17, 2007 at 10:10:51AM +0100, Dirk Koopman wrote:
> > Frank Lichtenheld wrote:
> > >On Sat, Jun 16, 2007 at 07:50:06PM +0100, Dirk Koopman wrote:
> > >Hmm, I don't see how you could have a problem with that since cvsserver
> > >doesn't support branches and never generates any revision numbers in
> > >that format?
> > >
> > >There is probably much more code out there in cvsserver that does assume
> > >that revision is always a simple integer.
>
> Let me rephrase that (after actually looking through the code):
> All of the revision handling code assumes that.
Exactly. cvsserver emulates CVS on a single HEAD, that's why you use
the headname as the 'module' parameter you pass to CVS when doing a
checkout.
...
> Hmm, so you did the cvs update in an old working copy of the original
> CVS repository? Then CVS sent those version numbers from the CVS/Entries
> file to the server, cvsserver certainly never generates numbers like
> that. And I would be very suprised if you could do anything remotely
> useful with abusing the old working copy this way...
Agreed - that's not really supported.
Now, I'd _love_ to have a bit of time to implement CVS-style branch
support to cvsserver (so a check for valid version numbers that have
more dots would be a good thing), but it's hard hard hard, specially
because there are many ambiguities to resolve. It would enormously
useful to have branch support together with support for a bit of
"version skew" so that you can replace a real CVS server with
cvsserver and have people continue using the old cvs checkouts --
because the file versions and branches match.
As things stand, I want to say thanks to Frank for giving cvsserver
some love :-)
cheers,
martin
^ permalink raw reply
* Re: git tool to keep a subversion mirror
From: Matthieu Moy @ 2007-06-17 21:09 UTC (permalink / raw)
To: Sergey Yanovich; +Cc: git, normalperson
In-Reply-To: <11821061823423-git-send-email-ynvich@gmail.com>
Sergey Yanovich <ynvich@gmail.com> writes:
> which is corrected by an attached patch.
I believe you forgot it then ... ;-)
--
Matthieu
^ permalink raw reply
* Re: Newbie using git -- need a little help
From: Thomas Glanzmann @ 2007-06-17 20:30 UTC (permalink / raw)
To: Robert Smith; +Cc: GIT
In-Reply-To: <2218.85747.qm@web57401.mail.re1.yahoo.com>
Hello Robert,
> The /home/cip/adm/sithglan/work/repositories/private/astro.git is
> simply a .git directory located on the "server", and it doesn't
> actually contain any working code (yet), right?
Right.
(faui02) [~/work/repositories/private/astro.git] ls
HEAD branches/ config description hooks/ info/ objects/ refs/ remotes/
> So what this command is doing is telling git where the "origin" is --
> on the remote server, correct? Also, is the default protocol (since
> all you typed was 131.188.30.102:/.../astro.git) is SSH correct?
The default protocol is git over ssh. And it adds a shorthand called
origin that points to the repository at the server you can now say:
git push origin
git pull origin
Since origin is the default, you can also say:
git push
git pull
Note when you do a "git clone ip:/path/to/dir.git", git will
automatically set up the reference to origin. You don't have to do it
yourself. In my initial example you had to do it yourself, because at
the time you started with the new project there was no origin because
you just started it.
> I'm a little lost on what 'origin' refers to precisely. Is origin
> considered the "root" of all the changes (the workspace as it was
> originally before any patches)? Or is it a location for the working
> files? You give a definition below in your e-mail but I'm still not
> completely sure what it is referring to.
"origin" is a shorthand for the remote repository. If you say git pull
git fetches the objects that are reference in the remote repository by
the head "master" (by default) and puts that in a local file called
.git/refs/remotes/origin/master:
(faui02) [~/work/blastwave] ls -al .git/refs/remotes/origin/master
-rw-r--r-- 1 sithglan icipguru 41 Jun 14 18:35 .git/refs/remotes/origin/master
(faui02) [~/work/blastwave] cat !$
cat .git/refs/remotes/origin/master
50da5cf500b8b57e32720ffe80fbabaadd7c8c9f
After that it tries to merge that remote head into your local branches
head. Most of the time that is .git/refs/heads/master
If you type in only "git fetch" it gets the objects but doesn't do any
merging.
So to answer your question. Origin is a copy of the repository you
pull/push by default. The objects of these tree are in your object store
but the actualy HEAD commit object is in the file I "cat" earlier in
this e-Mail.
Thomas
^ permalink raw reply
* Re: Newbie using git -- need a little help
From: Robert Smith @ 2007-06-17 20:06 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git
Thanks for the quick reply. I have a few questions regarding the infrastructure you described...
> When you push to your server, the repository is updated (that is the
> thing that is in .git) but your working tree isn't.
> So when you push to a repository that also has a working tree attached
> to it, you have to do a "git checkout" on the working tree. Or pull from
> the repository and not push to it.
Ahhh, that makes sense... :)
> Than I publish my project to the server without giving the repository at
> the server a working directory attached to it. A working directory is
> where you can edit files and commit changes locally, just in case I
> didn't introduce the term yet.
> # This creates the repository _without_ the working tree on the server.
> ssh 131.188.30.102 git --git-dir=/home/cip/adm/sithglan/work/repositories/private/astro.git init-db
The /home/cip/adm/sithglan/work/repositories/private/astro.git is simply a .git directory located on the "server", and it doesn't actually contain any working code (yet), right?
> # This adds the remote origin to the config so that I don't have to
> # type in the long repository path each time I am going to push or pull
> # something.
> git remote add origin 131.188.30.102:/home/cip/adm/sithglan/work/repositories/private/astro.git
So what this command is doing is telling git where the "origin" is -- on the remote server, correct? Also, is the default protocol (since all you typed was 131.188.30.102:/.../astro.git) is SSH correct?
> # Now I publish my stuff to the central repository. You need at least
> # one commit in order to be able to do that.
> git push origin master:master
>
> # I add a few lines to my config so that when I type in "git pull" it
> #fetches the stuff and merges it with my local repositories master branch.
>
> "vim .git/config" and add the following lines:
>
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> EOF
I'm a little lost on what 'origin' refers to precisely. Is origin considered the "root" of all the changes (the workspace as it was originally before any patches)? Or is it a location for the working files? You give a definition below in your e-mail but I'm still not completely sure what it is referring to.
> # Now I can fetch back to see if everything works
> git pull
Makes sense...let me give this a try. :)
> Now I am fine the infrastructure is all set up. The next time I am going
> to access the project from a different machine I simply do:
>
> git pull 131.188.30.102:/home/cip/adm/sithglan/work/repositories/private/astro.git
>
> And that's it. The origin and where it is going to merge stuff is set
> automatically up by git. Note: I use ssh (attached to a ssh-agent so that I
> don't have to passwords all the time I am doing a push or pull). I hope that
> helps you and didn't miss your original question. I just fly over your e-Mail
> and picked a few keywords to comment on.
Awesome...thanks, Thomas. I'll tinker around with this a little more and see if I can get this working as wanted.
Thanks again.
- robert -
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
^ permalink raw reply
* git tool to keep a subversion mirror
From: Sergey Yanovich @ 2007-06-17 19:38 UTC (permalink / raw)
To: git, normalperson
Oops, failed to attach patches last time
^ permalink raw reply
* [PATCH 2/2] 'git-svndump'
From: Sergey Yanovich @ 2007-06-17 19:38 UTC (permalink / raw)
To: git, normalperson; +Cc: Sergey Yanovich
In-Reply-To: <11821091373927-git-send-email-ynvich@gmail.com>
Signed-off-by: Sergey Yanovich <ynvich@gmail.com>
---
Documentation/git-svndump.txt | 106 +++++++++++++++++++++++++++++++++++++++++
git-svndump-init.sh | 85 +++++++++++++++++++++++++++++++++
git-svndump-sync.sh | 85 +++++++++++++++++++++++++++++++++
3 files changed, 276 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-svndump.txt
create mode 100755 git-svndump-init.sh
create mode 100755 git-svndump-sync.sh
diff --git a/Documentation/git-svndump.txt b/Documentation/git-svndump.txt
new file mode 100644
index 0000000..9caf02b
--- /dev/null
+++ b/Documentation/git-svndump.txt
@@ -0,0 +1,106 @@
+git-svndump(1)
+==========
+
+NAME
+----
+git-svndump - Exporting from git to a single Subversion branch
+
+SYNOPSIS
+--------
+'git-svndump' <command> [options] [arguments]
+
+DESCRIPTION
+-----------
+git-svndump is essentially a wrapper around 'git-svn commit-diff'. It
+will work only when it is the sole method of committing to the
+Subversion repository.
+
+It is designed to export a linear git branch. However, thanks to the way
+'git' handles source code, 'git-svndump' seems to work in other
+conditions. For example, when branches are switched or merged.
+
+git-svndump provides a solution when you need to export you source code
+in Subversion format (who would need this with git :), but do not want
+to have all the shackles that 'git-svn init' puts on your repository.
+
+COMMANDS
+--------
+--
+
+'init'::
+ Initialize an existing git repository with additional
+ metadata directories for git-svndump. The Subversion URL
+ must be specified as the first non-optional command-line
+ argument. 'git' tree-ish that correspond to the HEAD of
+ that Subversion URL may be specified as the second optional
+ command-line argument.
+
+-f;;
+ git-svndump normally declines to reinitialize the same git
+ repository. With the '-f' option that behavior is overridden.
+
+-A<filename>;;
+--authors-file=<filename>;;
+ The filename is stored, and provided as an argument to 'git-svn'
+ on calls of 'git-svndump sync'.
+
+'sync'::
+ Commit git revisions to the Subversion repository. If a git
+ <tree-ish> is specified as an optional command-line argument,
+ than all commits between the last 'sync' and that <tree-ish> are
+ send. If the argument is omitted, the HEAD of the active branch
+ is used.
+
+-A<filename>;;
+--authors-file=<filename>;;
+ The filename is provided as an argument to 'git-svn'.
+
+--
+
+BASIC EXAMPLE
+--------------
+
+Contributing to a Subversion repository:
+
+------------------------------------------------------------------------
+# Create your git repository, do some work and commit your changes
+# You are working on a computer A (git.foo.org)
+# Prepare your git repository for export (you are in the top dir)
+ git-svndump-init -A .auth http://svn.foo.org/project
+# Commit the whole branch:
+ git-svndump-sync
+# Now you go a different computer B
+# Clone a git repo:
+ git clone git.foo.org:/path/to/project.git
+# Enter the newly cloned directory:
+ cd project
+# Immediately prepare the new repository for export
+ git-svndump-init -A .auth http://svn.foo.org/project HEAD
+# Do some work and commit both locally and to A:
+ git commit ...
+ git push
+# Commit the new work:
+ git-svndump-sync
+# Now you return to the computer A
+# Reinit your repository for export!
+ git-svndump-init -f -A .auth http://svn.foo.org/project HEAD
+------------------------------------------------------------------------
+
+BUGS
+----
+
+The HEAD of the Subversion repository is not tracked. If your
+git-svndump repository goes out-of-sync with the Subversion mirror,
+the latter will most probably be corrupted.
+
+SEE ALSO
+--------
+gitlink:git-svn[1]
+
+Author
+------
+Written by Sergey Yanovich <ynvich@gmail.com>.
+
+Documentation
+-------------
+Written by Sergey Yanovich <ynvich@gmail.com>.
diff --git a/git-svndump-init.sh b/git-svndump-init.sh
new file mode 100755
index 0000000..4cf61b8
--- /dev/null
+++ b/git-svndump-init.sh
@@ -0,0 +1,85 @@
+#!/bin/sh
+
+usage()
+{
+ cat << EOF
+Usage: git-svndump-init [-f] subversion-url [<commit>]
+ subversion-url -- URL of the subversion repository to which you want
+ to dump the current git repository
+ <commit> -- git <commit> that correspond to the latest revision
+ in the subversion repository
+OPTIONS
+ -f
+ do not stop, if the git repository is already initialized.
+EOF
+ exit 1
+}
+
+if test x$GIT_DIR = x ; then
+ if test -d ./.git ; then
+ GIT_DIR=`pwd`/.git
+ fi
+fi
+
+if test ! -d $GIT_DIR ; then
+ usage
+fi
+
+if test x$1 = x ; then
+ usage
+fi
+
+if test x$1 = x-f; then
+ shift
+ rm -rf $GIT_DIR/svndump
+fi
+
+if test -d $GIT_DIR/svndump ; then
+ echo git-svndump-init: error: This git repository is already initialized
+ exit 1
+fi
+
+mkdir $GIT_DIR/svndump
+if test ! -d $GIT_DIR/svndump ; then
+ echo git-svndump-init: error: Failed to create $GIT_DIR/svndump
+ exit 1
+fi
+
+rev=`svn info $1 >$GIT_DIR/svndump/error.log`
+if test $? -ne 0 ; then
+ echo git-svndump-init: error: While quering $1
+ rm -rf $GIT_DIR/svndump
+ exit 1
+fi
+
+rev=`cat $GIT_DIR/svndump/error.log | sed -ne "/Revision/s/.* //p"`
+rm $GIT_DIR/svndump/error.log
+
+if test x$rev = x ; then
+ echo "git-svndump-init: error: Cannot determine the latest revision"
+ echo " at $1"
+ rm -rf $GIT_DIR/svndump
+ exit 1
+fi
+
+if test $rev -eq 0 ; then
+ mkdir -p $GIT_DIR/svndump/import && cd $GIT_DIR/svndump/import &&
+ svn import . $1 -m "Initial import by git-svndump"
+ if test $? -ne 0 ; then
+ echo "git-svndump-init: error: Failed to init $1"
+ rm -rf $GIT_DIR/svndump
+ exit 1
+ fi
+ rmdir $GIT_DIR/svndump/import
+fi
+
+echo "$1" > $GIT_DIR/svndump/url
+
+if test x$2 != x ; then
+ commit=`GIT_DIR=$GIT_DIR git-rev-list --max-count=1 $2`
+ if test $? -ne 0 ; then
+ echo "git-svndump-init: warning: Bad commit $2 ignored"
+ else
+ echo $commit >> $GIT_DIR/svndump/last
+ fi
+fi
diff --git a/git-svndump-sync.sh b/git-svndump-sync.sh
new file mode 100755
index 0000000..e1c04e1
--- /dev/null
+++ b/git-svndump-sync.sh
@@ -0,0 +1,85 @@
+#!/bin/sh
+
+usage()
+{
+ cat << EOF
+Usage: git-svndump-sync [<commit>]
+ <commit> -- git <commit> that correspond to the latest revision
+ to be dumped to the subversion repository
+EOF
+ exit 1
+}
+
+if test x$GIT_DIR = x ; then
+ if test -d ./.git ; then
+ GIT_DIR=`pwd`/.git
+ fi
+fi
+
+if test ! -d $GIT_DIR ; then
+ usage
+fi
+
+if test ! -d $GIT_DIR/svndump ; then
+ echo "git-svndump-sync: error: This git repository is not initialized"
+ echo " Run git-svndump-init first"
+ exit 1
+fi
+
+if test ! -f $GIT_DIR/svndump/url ; then
+ echo "git-svndump-sync: error: Cannot read url"
+ exit 1
+fi
+
+url=`cat $GIT_DIR/svndump/url`
+rev=`svn info $url >$GIT_DIR/svndump/error.log`
+if test $? -ne 0 ; then
+ echo git-svndump-sync: error: While quering $url
+ rm -rf $GIT_DIR/svndump/error.log
+ exit 1
+fi
+
+rev=`cat $GIT_DIR/svndump/error.log | sed -ne "/Revision/s/.* //p"`
+rm $GIT_DIR/svndump/error.log
+
+if test x$rev = x ; then
+ echo "git-svndump-init: error: Cannot determine the latest revision"
+ echo " at $url"
+ exit 1
+fi
+
+if test x$1 = x ; then
+ commit=HEAD
+else
+ commit=`GIT_DIR=$GIT_DIR git-rev-list --max-count=1 $1`
+ if test $? -ne 0 ; then
+ echo "git-svndump-sync: error: Bad commit '$1'"
+ exit 1
+ fi
+fi
+
+start=""
+last=0000000000000000000000000000000000000000
+if test -f $GIT_DIR/svndump/last ; then
+ last=`cat $GIT_DIR/svndump/last`
+ start=^`GIT_DIR=$GIT_DIR git-rev-list --max-count=1 $last`
+ if test $? -ne 0 ; then
+ echo "git-svndump-sync: warning: Ignoring bad commit '$last'"
+ start=""
+ last=0000000000000000000000000000000000000000
+ fi
+fi
+
+list=`GIT_DIR=$GIT_DIR git-rev-list $commit $start`
+
+diffs=""
+for c in $list ; do
+ diffs="$c $diffs"
+done
+
+for c in $diffs ; do
+ GIT_DIR=$GIT_DIR git-svn commit-diff -r$rev $last $c $url
+ echo "$c" > $GIT_DIR/svndump/last
+ last=$c
+ let rev++
+done
--
1.5.2.1
^ permalink raw reply related
* [PATCH 1/2] Accept root <tree-ish> in 'git-svn commit-diff'
From: Sergey Yanovich @ 2007-06-17 19:38 UTC (permalink / raw)
To: git, normalperson; +Cc: Sergey Yanovich
In-Reply-To: <11821091373273-git-send-email-ynvich@gmail.com>
Signed-off-by: Sergey Yanovich <ynvich@gmail.com>
---
git-svn.perl | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 50128d7..8ad291b 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2572,7 +2572,12 @@ sub generate_diff {
}
push @diff_tree, '--find-copies-harder' if $_find_copies_harder;
push @diff_tree, "-l$_rename_limit" if defined $_rename_limit;
- push @diff_tree, $tree_a, $tree_b;
+ if ($tree_a eq '0000000000000000000000000000000000000000') {
+ push @diff_tree, '--root';
+ } else {
+ push @diff_tree, $tree_a;
+ }
+ push @diff_tree, $tree_b;
my ($diff_fh, $ctx) = command_output_pipe(@diff_tree);
local $/ = "\0";
my $state = 'meta';
@@ -2606,6 +2611,8 @@ sub generate_diff {
}
$x->{file_b} = $_;
$state = 'meta';
+ } elsif ($state eq 'meta' && $_ eq $tree_b &&
+ $tree_a eq '0000000000000000000000000000000000000000') {
} else {
croak "Error parsing $_\n";
}
--
1.5.2.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox