* Re: Fork of abandoned SVN mirror - how to keep up to date with the SVN
From: jamespetts @ 2009-03-29 11:52 UTC (permalink / raw)
To: git
In-Reply-To: <fabb9a1e0903290403s2b0bbe1al57ac448a16d05070@mail.gmail.com>
Thank you again for your reply :-) Ahh, yes, that makes sense about the local repository. However, on checking, the local repository that I set up has no files except in .git directories - is that to be expected at this stage?
Also, when I tried "git svn rebase", I got the following error:
"Migrating from a git-svn v1 layout...
"Data from a previous version exists, but .git/svn (required for this version (1.6.2 msysgit.0.186.gf7512) of git-svn) does not exist. Done migrating from a git-svn v1 layout
"Unable to determine upstream SVN information from working tree history"
And the local directories for the repositories are still empty. Am I doing something wrong...?
Heya,
On Sun, Mar 29, 2009 at 12:51, jamespetts <jamespetts@yahoo.com> wrote:
> However, after several hours of downloading (I left it overnight), it gave the error, "The connection was aborted: Can't read from connection: The connection was aborted at C:\Program Files\Git/libexec/git-core/git-svn/ line 2490".
You can continue downloading, just issue' git svn rebase' again, and
it will continue where it left of.
> When I look at my repository on Github, it is still empty, apart
> from the empty README file that I created just to initialise it.
> Why would it be going wrong? How do I deal with that?
You would have to push the repository to github regardless of whether
'git svn rebase' finished in one go. Keep in mind that' git svn
rebase' is the way to get changes _into_ your _local_ repository.
You'll need to use 'git push' to get your changes up to github.
--
Cheers,
Sverre Rabbelier
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
View this message in context: http://n2.nabble.com/Fork-of-abandoned-SVN-mirror---how-to-keep-up-to-date-with-the-SVN-tp2548952p2552334.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH v2 1/2] Documentation/Makefile: make most operations "quiet"
From: Jeff King @ 2009-03-29 11:52 UTC (permalink / raw)
To: Chris Johnsen; +Cc: Junio C Hamano, git
In-Reply-To: <1238136579-23166-1-git-send-email-chris_johnsen@pobox.com>
On Fri, Mar 27, 2009 at 01:49:38AM -0500, Chris Johnsen wrote:
> "v1" of this series can be found here: <http://thread.gmane.org/gmane.comp.version-control.git/114417/focus=114557>.
>
> Changes since "v1": Fixed broken technical/api-index.txt target
> (thanks, Peff). Extended error propagation across calls to
> DOCBOOK2X_TEXI for gitman.texi. Added QUIET_XSLTPROC for
> "one-off" user-manual.html.
This version looks fine to me (though I admit I didn't look at the texi,
since I don't have that toolchain installed).
Thanks for detailing in both series what changed from v1; that makes it
much simpler to review.
-Peff
^ permalink raw reply
* Re: Fork of abandoned SVN mirror - how to keep up to date with the SVN
From: Sverre Rabbelier @ 2009-03-29 12:03 UTC (permalink / raw)
To: jamespetts; +Cc: git
In-Reply-To: <1238327564546-2552334.post@n2.nabble.com>
Heya,
[it is customary on this list not to top post and to reply in-line,
like I'm doing now]
On Sun, Mar 29, 2009 at 13:52, jamespetts <jamespetts@yahoo.com> wrote:
> Also, when I tried "git svn rebase", I got the following error:
> And the local directories for the repositories are still empty. Am I doing something wrong...?
You need to do something like 'git reset --hard trunk' on the master
branch, after which you can use 'git svn rebase'. This is needed the
first time only so that git svn can then figure out where you're at
from the commit messages.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Fork of abandoned SVN mirror - how to keep up to date with the SVN
From: jamespetts @ 2009-03-29 12:08 UTC (permalink / raw)
To: git
In-Reply-To: <fabb9a1e0903290503g7ec0a37djd71ce8eba6220d70@mail.gmail.com>
Heya,
[it is customary on this list not to top post and to reply in-line,
like I'm doing now]
Ohh, terribly sorry - didn't realise.
On Sun, Mar 29, 2009 at 13:52, jamespetts <jamespetts@yahoo.com> wrote:
> Also, when I tried "git svn rebase", I got the following error:
> And the local directories for the repositories are still empty. Am I doing something wrong...?
You need to do something like 'git reset --hard trunk' on the master
branch, after which you can use 'git svn rebase'. This is needed the
first time only so that git svn can then figure out where you're at
from the commit messages.
Thank you for that suggestion :-) Unfortunately, "git reset --hard trunk" produced the following error:
"fatal: ambiguous argument 'trunk': unknown revision or path not in the working tree.
"use '--' to separate paths from revisions".
What am I doing wrong this time...?
--
View this message in context: http://n2.nabble.com/Fork-of-abandoned-SVN-mirror---how-to-keep-up-to-date-with-the-SVN-tp2548952p2552369.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Segfault on merge with 1.6.2.1
From: Miklos Vajna @ 2009-03-29 12:17 UTC (permalink / raw)
To: Michael Johnson; +Cc: git
In-Reply-To: <op.urifmtkkso3nzr@sulidor.mdjohnson.us>
[-- Attachment #1: Type: text/plain, Size: 519 bytes --]
On Sat, Mar 28, 2009 at 11:19:31AM -0500, Michael Johnson <redbeard@mdjohnson.us> wrote:
> The 1.6.2.1 version just segfaults, but 1.5.6.5 says:
>
> /usr/bin/git-merge: line 438: 32335 Segmentation fault
> git-merge-$strategy $common -- "$head_arg" "$@"
> Merge with strategy recursive failed.
>
> In all cases, .git/index.lock is left behind.
That's because 1.6.2.1 has git-merge in C and it calls merge-recursive
directly without a fork. Could you try it in gdb and provide a
backtrace, please?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Fork of abandoned SVN mirror - how to keep up to date with the SVN
From: Sverre Rabbelier @ 2009-03-29 12:35 UTC (permalink / raw)
To: jamespetts; +Cc: git
In-Reply-To: <1238328537685-2552369.post@n2.nabble.com>
Heya,
On Sun, Mar 29, 2009 at 14:08, jamespetts <jamespetts@yahoo.com> wrote:
> "fatal: ambiguous argument 'trunk': unknown revision or path not in the working tree.
>
> "use '--' to separate paths from revisions".
>
> What am I doing wrong this time...?
You can do "git branch -a" to see which branch name git svn uses, it
might be 'git-svn', it depends on which version you're using I think.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Fork of abandoned SVN mirror - how to keep up to date with the SVN
From: jamespetts @ 2009-03-29 12:53 UTC (permalink / raw)
To: git
In-Reply-To: <fabb9a1e0903290535y59cd3a1fvd5a7d3476dff45bc@mail.gmail.com>
Heya,
On Sun, Mar 29, 2009 at 14:08, jamespetts <jamespetts@yahoo.com> wrote:
> "fatal: ambiguous argument 'trunk': unknown revision or path not in the working tree.
>
> "use '--' to separate paths from revisions".
>
> What am I doing wrong this time...?
You can do "git branch -a" to see which branch name git svn uses, it
might be 'git-svn', it depends on which version you're using I think.
Thank you for the suggestion - the first part seemed to work: once I got the correct name, "...reset --hard" responded with:
"HEAD is now at 4939935 first commit".
However, when I tried "git svn rebase" again, I still got this error:
"Unable to determine upstream SVN infromation from working tree history".
Have I done something wrong...?
--
View this message in context: http://n2.nabble.com/Fork-of-abandoned-SVN-mirror---how-to-keep-up-to-date-with-the-SVN-tp2548952p2552470.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Fork of abandoned SVN mirror - how to keep up to date with the SVN
From: Sverre Rabbelier @ 2009-03-29 12:55 UTC (permalink / raw)
To: jamespetts, Eric Wong; +Cc: git
In-Reply-To: <1238331203288-2552470.post@n2.nabble.com>
Heya,
On Sun, Mar 29, 2009 at 14:53, jamespetts <jamespetts@yahoo.com> wrote:
>
> "Unable to determine upstream SVN infromation from working tree history".
>
> Have I done something wrong...?
I'm afraid this is where my git-svn knowledge is no longer sufficient
:(. I have had the same problem myself, and I don't know how to fix
it, perhaps Eric has a moment to enlighten?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Owners
From: Aaron Gray @ 2009-03-29 14:00 UTC (permalink / raw)
To: Git Mailing List
Okay, I seem to have a normal operations now :-
git svn fetch
git reset --hard HEAD
git svn rebase
Seems to do the job, thanks.
I am wondering what is going on with users, the ones that were accidently
written as root are showing root as their owner, where as others under the
user name git is not showing this in the owner field.
If someone could please fill me in in this area.
Many thanks in advance,
Aaron
^ permalink raw reply
* Re: Fork of abandoned SVN mirror - how to keep up to date with the SVN
From: jamespetts @ 2009-03-29 15:07 UTC (permalink / raw)
To: git
In-Reply-To: <fabb9a1e0903290555o3503b58ie097f8f8336c4401@mail.gmail.com>
Heya,
On Sun, Mar 29, 2009 at 14:53, jamespetts <jamespetts@yahoo.com> wrote:
>
> "Unable to determine upstream SVN infromation from working tree history".
>
> Have I done something wrong...?
I'm afraid this is where my git-svn knowledge is no longer sufficient
:(. I have had the same problem myself, and I don't know how to fix
it, perhaps Eric has a moment to enlighten?
Supposing that Eric is unable to find a solution - would there be any mileage in doing it manually? That is, checking out the SVN repository into a local directory, initialising that as a Git repository, and then pushing it to Github? If so, would that make it any harder to re-synchronise with my branch than the git-svn method?
--
View this message in context: http://n2.nabble.com/Fork-of-abandoned-SVN-mirror---how-to-keep-up-to-date-with-the-SVN-tp2548952p2552797.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Git Download/Bootstrap Suggestion
From: Scott Chacon @ 2009-03-29 15:29 UTC (permalink / raw)
To: Jacob Helwig; +Cc: Sverre Rabbelier, Michael J Gruber, Mike Gaffney, git
In-Reply-To: <8c9a060903280924h62f4d7aq47819bf3264e6ad6@mail.gmail.com>
On Sat, Mar 28, 2009 at 5:24 PM, Jacob Helwig <jacob.helwig@gmail.com> wrote:
> So he can compile git from a git repo, and not have to download it
> (again) after compiling from a work tree. Saving a step, and
> re-compiling a bunch of files when he upgrades.
>
I'm a bit unclear why you would compile/install the second time - if
it's the latest tag, it should be the same as you got from the archive
on the website, the second step should just be re-installing the exact
same Git. Why not just build it from source the first time and then
pull down the full source for the subsequent times - you're losing
seconds total in the process. Unless you're doing this all the time,
in which case it seems like it makes more sense to just keep one repo,
build a package of some sort (rpm, deb, etc) and distribute that to
all the computers you're using.
I mean, if you really, really want it then you can :
a) clone the website source : git://github.com/schacon/gitscm
b) write the script that would do it on each release (scripts/ dir)
c) test it
d) write some code that would dynamically link that in the downloads
page at the bottom
If that works then I'll probably pull it in for you.
Scott
> On Sat, Mar 28, 2009 at 09:15, Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> Heya,
>>
>> On Sat, Mar 28, 2009 at 17:09, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> No, I think he meant repo, not work tree.
>>
>> Why would he need the repo to bootstrap?
>>
>> --
>> Cheers,
>>
>> Sverre Rabbelier
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* git-svn stubbornly re-creating branch "master"
From: Marcin Owsiany @ 2009-03-29 17:13 UTC (permalink / raw)
To: git
Hello,
I created my git repository by cloning it with git-svn from an upstream SVN
repository. When I did that, a branch "master" was created. Afterwards I
renamed that branch to "upstream". However every time I "git-svn fetch", it
recreates the "master" branch, pointing it at the newest upstream commit.
Ideally, I'd like it to just forget about "master" and do the same to my
"upstream" branch. Is it possible?
If not, then is it at least possible to have it not recreate the "master"
branch? It clutters my view.
Here's a typescript (with git 1:1.5.6.3-1.1ubuntu2):
$ svnadmin create svn-repo
$ r=`pwd`/svn-repo
$ svn co file://$r svn
Checked out revision 0.
$ (cd svn && echo one >> file && svn add file && svn ci -m one file)
A file
Adding file
Transmitting file data .
Committed revision 1.
$ git-svn clone file://$r git
Initialized empty Git repository in /home/mowsiany/tmp/gs/git/.git/
A file
r1 = 66e7199fe089b1e626efb5f2f3106189d992d288 (git-svn)
Checked out HEAD:
file:///home/mowsiany/tmp/gs/svn-repo r1
$ (cd git && git show-ref )
66e7199fe089b1e626efb5f2f3106189d992d288 refs/heads/master
66e7199fe089b1e626efb5f2f3106189d992d288 refs/remotes/git-svn
$ (cd git && git branch mystuff )
$ (cd git && git show-ref )
66e7199fe089b1e626efb5f2f3106189d992d288 refs/heads/master
66e7199fe089b1e626efb5f2f3106189d992d288 refs/heads/mystuff
66e7199fe089b1e626efb5f2f3106189d992d288 refs/remotes/git-svn
$ (cd git && git branch -m master upstream )
$ (cd git && git show-ref )
66e7199fe089b1e626efb5f2f3106189d992d288 refs/heads/mystuff
66e7199fe089b1e626efb5f2f3106189d992d288 refs/heads/upstream
66e7199fe089b1e626efb5f2f3106189d992d288 refs/remotes/git-svn
$ (cd svn && echo two >> file && svn ci -m two file)
Sending file
Transmitting file data .
Committed revision 2.
$ (cd git && git-svn fetch )
M file
r2 = c2f8e7fd146e0e9f1223f20bf3c2105f71632c4b (git-svn)
$ (cd git && git show-ref )
c2f8e7fd146e0e9f1223f20bf3c2105f71632c4b refs/heads/master
66e7199fe089b1e626efb5f2f3106189d992d288 refs/heads/mystuff
66e7199fe089b1e626efb5f2f3106189d992d288 refs/heads/upstream
c2f8e7fd146e0e9f1223f20bf3c2105f71632c4b refs/remotes/git-svn
As you can see, "master" sprang back to life after the last command.
--
Marcin Owsiany <porridge@debian.org> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
^ permalink raw reply
* [PATCH] git-svn: don't output git commits in quiet mode
From: Simon Arlott @ 2009-03-29 19:34 UTC (permalink / raw)
To: gitster; +Cc: git
Ideally only errors should be output in this mode so fetch
can be run from cron and normally produce no output. Without
this change it would output a single line on each git commit,
e.g.
r1909 = 32ef87860662526d4a62f903949ed21e0341079e (u2_10_12_branch)
Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
---
git-svn.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 8be6be0..e100b69 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2331,13 +2331,13 @@ sub do_git_commit {
$self->{last_rev} = $log_entry->{revision};
$self->{last_commit} = $commit;
- print "r$log_entry->{revision}";
+ print "r$log_entry->{revision}" unless $::_q;
if (defined $log_entry->{svm_revision}) {
- print " (\@$log_entry->{svm_revision})";
+ print " (\@$log_entry->{svm_revision})" unless $::_q;
$self->rev_map_set($log_entry->{svm_revision}, $commit,
0, $self->svm_uuid);
}
- print " = $commit ($self->{ref_id})\n";
+ print " = $commit ($self->{ref_id})\n" unless $::_q;
if (--$_gc_nr == 0) {
$_gc_nr = $_gc_period;
gc();
--
1.6.2
--
Simon Arlott
^ permalink raw reply related
* Re: git-svn stubbornly re-creating branch "master"
From: Dmitry Potapov @ 2009-03-29 19:52 UTC (permalink / raw)
To: Marcin Owsiany; +Cc: git, Eric Wong
In-Reply-To: <20090329171347.GA26866@beczulka>
On Sun, Mar 29, 2009 at 18:13:47 +0100, Marcin Owsiany
<porridge@debian.org> wrote:
>
> As you can see, "master" sprang back to life after the last command.
It looks like git-svn does not like a repo without 'master'. It seems
the problem was caused by this patch:
http://git.kernel.org/?p=git/git.git;a=commit;h=1e889ef36c45b5554f7e317493ed3f4f901f8d9f
I have added Eric to CC...
Dmitry
^ permalink raw reply
* Re: [PATCH 1/4] test-suite: adding a test for fast-export with tag variants
From: Erik Faye-Lund @ 2009-03-29 20:05 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, gitster
In-Reply-To: <1237812789-1360-1-git-send-email-kusmabite@gmail.com>
OK, I see now that the previous patch-series has been merged to "pu".
Is there a reason why this updated patch-series hasn't superseded it?
Did I do something wrong when I resubmitted it? And what do I need to
do to get these patches going forward from there?
On Mon, Mar 23, 2009 at 2:53 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> The first two new tests are crashing, so I'm adding them commented out as they
> exit with unpredictable return-codes.
>
> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
> ---
> t/t9301-fast-export.sh | 14 +++++++++++++-
> 1 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
> index 86c3760..db4b0b3 100755
> --- a/t/t9301-fast-export.sh
> +++ b/t/t9301-fast-export.sh
> @@ -28,7 +28,12 @@ test_expect_success 'setup' '
> git commit -m sitzt file2 &&
> test_tick &&
> git tag -a -m valentin muss &&
> - git merge -s ours master
> + git merge -s ours master &&
> + HEAD_TREE=`git show -s --pretty=raw HEAD | grep tree | sed "s/tree //"` &&
> + git tag tree_tag -m "tagging a tree" $HEAD_TREE &&
> + git tag -a tree_tag-obj -m "tagging a tree" $HEAD_TREE &&
> + git tag tag-obj_tag -m "tagging a tag" tree_tag-obj &&
> + git tag -a tag-obj_tag-obj -m "tagging a tag" tree_tag-obj
>
> '
>
> @@ -259,4 +264,11 @@ test_expect_success 'cope with tagger-less tags' '
>
> '
>
> +# NEEDSWORK: not just check return status, but validate the output
> +# two tests commented out due to crash and thus unreliable return code
> +#test_expect_success 'tree_tag' 'git fast-export tree_tag'
> +#test_expect_success 'tree_tag-obj' 'git fast-export tree_tag-obj'
> +test_expect_failure 'tag-obj_tag' 'git fast-export tag-obj_tag'
> +test_expect_failure 'tag-obj_tag-obj' 'git fast-export tag-obj_tag-obj'
> +
> test_done
> --
> 1.6.2.1.225.g9a4a0.dirty
>
>
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* RE: Newbie installation problem: non 7-zip archive
From: Angus Monro @ 2009-03-29 20:18 UTC (permalink / raw)
To: git
In-Reply-To: <200903281417.46285.barra_cuda@katamail.com>
OK, Successfully installed the Win native app after downloading using IE7
rather than FF3. Still had no success with the portable app, curiously, but
am happy now. Thanks.
Angus.
^ permalink raw reply
* Re: [PATCH 2/2] Resolve double chmod() in move_temp_to_file()
From: Junio C Hamano @ 2009-03-29 20:31 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Johannes Sixt
In-Reply-To: <200903281201.35409.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> On Saturday 28 March 2009, Junio C Hamano wrote:
>> Johan Herland <johan@herland.net> writes:
>> > - if (chmod(filename, 0444) || adjust_shared_perm(filename))
>> > + if (chmod(filename, get_shared_perm(0444)))
>>
>> Your get_shared_perm() will end up feeding 0444 to S_ISDIR(), which would
>> most likely say "no" and cause real harm, but there is no guarantee that
>> we won't start checking S_ISREG() or other things in get_shared_perm()
>> later. I do not like this.
... should have been s/and cause/and cause no/; I think you read it correctly, though...
> ...
>> diff --git a/sha1_file.c b/sha1_file.c
>> index 8869488..5bfc36c 100644
>> --- a/sha1_file.c
>> +++ b/sha1_file.c
>> @@ -2263,7 +2263,7 @@ int move_temp_to_file(const char *tmpfile, const
>> char *filename) *
>> * The same holds for FAT formatted media.
>> *
>> - * When this succeeds, we just return 0. We have nothing
>> + * When this succeeds, we just return; we have nothing
>
> Small nit: This belongs in the previous patch, doesn't it?
Thanks for all the above fixes.
^ permalink raw reply
* Re: [PATCH] git-svn: fix ls-tree usage with dash-prefixed paths
From: Junio C Hamano @ 2009-03-29 20:33 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Anton Gyllenberg
In-Reply-To: <20090329061045.GA29721@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> To find the blob object name given a tree and pathname, we were
> incorrectly calling "git ls-tree" with a "--" argument followed
> by the pathname of the file we wanted to get.
>
> git ls-tree <TREE> -- --dashed/path/name.c
>
> Unlike many command-line interfaces, the "--" alone does not
> symbolize the end of non-option arguments on the command-line.
>
> ls-tree interprets the "--" as a prefix to match against, thus
> the entire contents of the --dashed/* hierarchy would be
> returned because the "--" matches "--dashed" and every path
> under it.
The above makes only half a sense to me. In an empty directory:
$ git init
Initialized empty Git repository in /tmp/empty/.git
$ mkdir -p ./--dashed/path
$ >./--dashed/path/name
$ git add .
$ git ls-files
--dashed/path/name
$ git commit -a -m initial
[master (root-commit) cd44284] initial
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 --dashed/path/name
$ git ls-tree HEAD^{tree} --
$ git ls-tree HEAD^{tree} -- --dashed/path/name
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 --dashed/path/name
$ mkdir ./--
$ >./--/eman
$ git add .
$ git commit -m second
[master 80f8ef9] second
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 --/eman
$ git ls-tree HEAD^{tree} -- --dashed/path
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 --/eman
040000 tree 23e59e0c91294c39ac7c5a2e39efb01d878de9a0 --dashed/path
$ exit
Perhaps the problem repository had a pathname that is exactly -- (in
addition to --dashed/), and ls-tree emitted everything under --/
hierarchy? In other words, your fix to git-svn may be correct and I am
reading your problem description above incorrectly?
As the command always takes exactly one tree, it could be argued that it
is not a bug that it does not honour the usual -- convention, even though
I am tempted to think it is of a very dark shade of gray. It is certainly
something that we would have done differently if we were implementing the
command today.
"Fixing" ls-tree would be trivial to ignore the first "--" if it precedes
other pathspecs (see below), but the command is a plumbing, and such a
change will break existing scripts that have relied on the existing
behaviour since 2005, so I do not think it is worth the risk of causing
such silent breakages to them. Besides, with such a "fix", fixing of user
scripts will become much more cumbersome, as they need to detect the
version of git and drive ls-tree differently.
builtin-ls-tree.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index 22008df..08c4307 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -186,6 +186,12 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
if (get_sha1(argv[1], sha1))
die("Not a valid object name %s", argv[1]);
+ if (3 < argc && !strcmp(argv[2], "--")) {
+ /* ls-tree <tree> -- pathspec */
+ argc--;
+ argv++;
+ warning("ignoring -- in 'ls-tree <tree> -- <pathspec>'");
+ }
pathspec = get_pathspec(prefix, argv + 2);
tree = parse_tree_indirect(sha1);
if (!tree)
^ permalink raw reply related
* [PATCH] import-zips: fix thinko
From: Johannes Schindelin @ 2009-03-29 20:42 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <cover.1238359324u.git.johannes.schindelin@gmx.de>
Embarrassingly, the common prefix calculation did not work properly, due
to a mistake in the assignment: instead of assigning the dirname of the
current file name, the dirname of the current common prefix needs to
be assigned to common prefix, when the current prefix does not match the
current file name.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
contrib/fast-import/import-zips.py | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/import-zips.py b/contrib/fast-import/import-zips.py
index c674fa2..7051a83 100755
--- a/contrib/fast-import/import-zips.py
+++ b/contrib/fast-import/import-zips.py
@@ -44,7 +44,8 @@ for zipfile in argv[1:]:
common_prefix = name[:name.rfind('/') + 1]
else:
while not name.startswith(common_prefix):
- common_prefix = name[:name.rfind('/') + 1]
+ last_slash = common_prefix[:-1].rfind('/') + 1
+ common_prefix = common_prefix[:last_slash]
mark[name] = ':' + str(next_mark)
next_mark += 1
--
1.6.2.1.493.g67cf3
^ permalink raw reply related
* Re: [PATCH 1/4] test-suite: adding a test for fast-export with tag variants
From: Junio C Hamano @ 2009-03-29 21:32 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Erik Faye-Lund, git, gitster
In-Reply-To: <40aa078e0903291305p28ec2ae8xf0cb465e593af0b0@mail.gmail.com>
Erik Faye-Lund <kusmabite@googlemail.com> writes:
> OK, I see now that the previous patch-series has been merged to "pu".
> Is there a reason why this updated patch-series hasn't superseded it?
Even if the tested program crashes, it is Ok to test them inside
expect_failure, so I'd suggest not commenting the first two out.
But running the tests with the first patch applied to the same base as
where v1 was applied gives this, which is a more serious issue:
$ sh t9301-fast-export.sh 2>&1 | tail -n 2
* still have 4 known breakage(s)
* failed 6 among remaining 15 test(s)
In other words, the changes to the set-up part seem to break unrelated
tests. Why can such an update supersede the previous one?
^ permalink raw reply
* Re: [PATCH 1/4] test-suite: adding a test for fast-export with tag variants
From: Erik Faye-Lund @ 2009-03-29 21:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Erik Faye-Lund, git
In-Reply-To: <7vwsa8ow10.fsf@gitster.siamese.dyndns.org>
On Sun, Mar 29, 2009 at 11:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Even if the tested program crashes, it is Ok to test them inside
> expect_failure, so I'd suggest not commenting the first two out.
OK, the reason why I didn't want to do that is because the test
appears to succeed on windows when it crashes. But you might not care
too much about that ;)
> But running the tests with the first patch applied to the same base as
> where v1 was applied gives this, which is a more serious issue:
>
> $ sh t9301-fast-export.sh 2>&1 | tail -n 2
> * still have 4 known breakage(s)
> * failed 6 among remaining 15 test(s)
>
> In other words, the changes to the set-up part seem to break unrelated
> tests. Why can such an update supersede the previous one?
That's weird. I did test it properly before I applied it, and I don't
recall having any failures on Linux. On Windows, I get lots of
failures with vanilla git.git, and I don't have access to my Linux-box
right now, so I can't easily verify this until that box comes up
again. I did see that another patch (ebeec7d) has made it's way into
the test since I submitted it - perhaps these two collided?
But OK, I'll have a look at it when that box comes up, and see if I
can come up with a good patch-series.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [PATCH] git-svn: fix ls-tree usage with dash-prefixed paths
From: Eric Wong @ 2009-03-29 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Anton Gyllenberg
In-Reply-To: <7v8wmoqdc1.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > To find the blob object name given a tree and pathname, we were
> > incorrectly calling "git ls-tree" with a "--" argument followed
> > by the pathname of the file we wanted to get.
> >
> > git ls-tree <TREE> -- --dashed/path/name.c
> >
> > Unlike many command-line interfaces, the "--" alone does not
> > symbolize the end of non-option arguments on the command-line.
> >
> > ls-tree interprets the "--" as a prefix to match against, thus
> > the entire contents of the --dashed/* hierarchy would be
> > returned because the "--" matches "--dashed" and every path
> > under it.
>
> The above makes only half a sense to me. In an empty directory:
Ah, I think you missed this line:
"the entire contents of the --dashed/* hierarchy would be"
> $ git init
> Initialized empty Git repository in /tmp/empty/.git
> $ mkdir -p ./--dashed/path
> $ >./--dashed/path/name
# Add a second file
>./--dashed/path/ame
> $ git add .
> $ git ls-files
> --dashed/path/name
> $ git commit -a -m initial
> [master (root-commit) cd44284] initial
> 0 files changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 --dashed/path/name
> $ git ls-tree HEAD^{tree} --
> $ git ls-tree HEAD^{tree} -- --dashed/path/name
> 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 --dashed/path/name
> $ mkdir ./--
> $ >./--/eman
> $ git add .
> $ git commit -m second
> [master 80f8ef9] second
> 0 files changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 --/eman
> $ git ls-tree HEAD^{tree} -- --dashed/path
> 100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 --/eman
> 040000 tree 23e59e0c91294c39ac7c5a2e39efb01d878de9a0 --dashed/path
This is similar to the problem I was experiencing.
> $ exit
>
> Perhaps the problem repository had a pathname that is exactly -- (in
> addition to --dashed/), and ls-tree emitted everything under --/
> hierarchy? In other words, your fix to git-svn may be correct and I am
> reading your problem description above incorrectly?
I think so.
> As the command always takes exactly one tree, it could be argued that it
> is not a bug that it does not honour the usual -- convention, even though
> I am tempted to think it is of a very dark shade of gray. It is certainly
> something that we would have done differently if we were implementing the
> command today.
Well, if somebody had a path in their repo called "--full-name" then it
would certainly be ambiguous and respecting "--" would help. Something
we should definitely go back and fix if we have time travel[1]
> "Fixing" ls-tree would be trivial to ignore the first "--" if it precedes
> other pathspecs (see below), but the command is a plumbing, and such a
> change will break existing scripts that have relied on the existing
> behaviour since 2005, so I do not think it is worth the risk of causing
> such silent breakages to them. Besides, with such a "fix", fixing of user
> scripts will become much more cumbersome, as they need to detect the
> version of git and drive ls-tree differently.
I concur completely. I didn't propose a "fix" to ls-tree for exactly
the reasons you stated.
[1] But if we had time travel we could just release git before any other
SCM and hopefully not have to deal with SVN at all :)
--
Eric Wong
^ permalink raw reply
* git svn init --username ignored
From: Lachlan Deck @ 2009-03-29 21:56 UTC (permalink / raw)
To: git
Hi there,
Is it a bug that the when specifying --username=foo for either git-svn
init or git-svn clone that this isn't stored in .git/config?
It means that for http[s] urls you need to specify it each time for
git-svn fetch, for example.
Is there any way to specify it manually in the config file - or would
that have some bad consequences?
Thanks.
with regards,
--
Lachlan Deck
^ permalink raw reply
* Re: Fork of abandoned SVN mirror - how to keep up to date with the SVN
From: Eric Wong @ 2009-03-29 22:16 UTC (permalink / raw)
To: jamespetts; +Cc: Sverre Rabbelier, git
In-Reply-To: <fabb9a1e0903290555o3503b58ie097f8f8336c4401@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Sun, Mar 29, 2009 at 14:53, jamespetts <jamespetts@yahoo.com> wrote:
> >
> > "Unable to determine upstream SVN infromation from working tree history".
> >
> > Have I done something wrong...?
>
> I'm afraid this is where my git-svn knowledge is no longer sufficient
> :(. I have had the same problem myself, and I don't know how to fix
> it, perhaps Eric has a moment to enlighten?
What does "git log" in your working tree say before you run "git svn
rebase"?
Then, what does "git log <ref_of_svn_remote_you_reset_to>" say?
"git svn rebase" relies on the "git-svn-id:" line in the log message
as well as the stored checksum to determine how to rebase the
current HEAD.
However, "git svn fetch" should always work[1] and not touch the current
HEAD. You can run "git svn fetch" to get the new updates and then
push your remotes out as heads by setting up your pushes to github
like this .git/config (totally untested):
[remote "github"]
url = user@github.com/foo/bar.git
push = refs/remotes/*:refs/heads/*
[1] - at least on POSIX, I don't know if git-svn is still broken
in Windows and can't help if is.
--
Eric Wong
^ permalink raw reply
* Re: git-svn stubbornly re-creating branch "master"
From: Eric Wong @ 2009-03-29 22:28 UTC (permalink / raw)
To: Marcin Owsiany; +Cc: git
In-Reply-To: <20090329171347.GA26866@beczulka>
Marcin Owsiany <porridge@debian.org> wrote:
> Hello,
>
> I created my git repository by cloning it with git-svn from an upstream SVN
> repository. When I did that, a branch "master" was created. Afterwards I
> renamed that branch to "upstream". However every time I "git-svn fetch", it
> recreates the "master" branch, pointing it at the newest upstream commit.
>
> Ideally, I'd like it to just forget about "master" and do the same to my
> "upstream" branch. Is it possible?
>
> If not, then is it at least possible to have it not recreate the "master"
> branch? It clutters my view.
"master" has been a git convention since the earliest days of git and
it's less confusing to new users following documentation if it always
exists (and a lot of users' first git experience is with git svn).
Why not just use "master" as one of your branches? It won't bite you.
"git svn fetch" will never clobber your "master" if it already exists.
--
Eric Wong
^ permalink raw reply
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