threads / discuss / 40404

git-svn aborts with "Use of uninitialized value $u" when a non-svn-backed branch is present in remote

Subject: git-svn aborts with "Use of uninitialized value $u" when a non-svn-backed branch is present in remote

## tl;dr

6 messages between Sep 22, 2015 and Jul 2, 2016.

replies: 5people: 3as markdown or json

Jacob Godserv· Sep 22, 2015, 18:48 UTC · lore
I found a specific case in which git-svn improperly aborts:
1. I created a git-svn repository, named "git-svn repo", by cloned an
svn repository via the git-svn tool.
2. I created a normal git repository, named "configuration repo". I
renamed the master branch to "configuration". The initial commit adds
a README and some utility scripts.
3. I created a bare repository, named "master repo".
4. I pushed from the git-svn repo to the master repo.
5. I pushed from the configuration repo to the master repo.

The idea is the configuration branch, which is detached from any git-svn history, can contain some useful tools, defaults, etc., that I can share with teammates who want to use git on this svn project. It's an odd use of git, but it has been working well.

However, a vanilla distribution of Git for Windows 2.5.2 produces the following error when running any git-svn command, such as "git svn info", on the cloned master repo:

Use of uninitialized value $u in substitution (s///) at /mingw64/share/perl5/site_perl/Git/SVN.pm line 105. Use of uninitialized value $u in concatenation (.) or string at /mingw64/share/perl5/site_perl/Git/SVN.pm line 105. refs/remotes/origin/configuration: 'svn+ssh://10.0.1.1/repos/projectA' not found in ''

In the mentioned SVN.pm file, after the line:
                        my $u = (::cmt_metadata("$refname"))[0];
I added the following four lines:
                        if (not defined $u) {
                                warn "W: $refname does not exist in
SVN; skipping";
                                next;
                        }

git-svn appears to operate correctly with this patch. This is my first time ever editing a perl script, so I apologize if I murdered an adorable animal just now.

I'm sending this in so more knowledgeable git-svn developers can comment on this and fix this in the official distribution of git, assuming there is a bug here to fix.

-- 
    Jacob
Jacob Godserv· Jun 24, 2016, 14:44 UTC · re: Jacob Godserv · lore

Re: git-svn aborts with "Use of uninitialized value $u" when a non-svn-backed branch is present in remote

On Tue, Sep 22, 2015 at 2:48 PM, Jacob Godserv <jacobgodserv@gmail.com> wrote:
Show 49 quoted lines
> I found a specific case in which git-svn improperly aborts:
>
> 1. I created a git-svn repository, named "git-svn repo", by cloned an
> svn repository via the git-svn tool.
> 2. I created a normal git repository, named "configuration repo". I
> renamed the master branch to "configuration". The initial commit adds
> a README and some utility scripts.
> 3. I created a bare repository, named "master repo".
> 4. I pushed from the git-svn repo to the master repo.
> 5. I pushed from the configuration repo to the master repo.
>
> The idea is the configuration branch, which is detached from any
> git-svn history, can contain some useful tools, defaults, etc., that I
> can share with teammates who want to use git on this svn project. It's
> an odd use of git, but it has been working well.
>
> However, a vanilla distribution of Git for Windows 2.5.2 produces the
> following error when running any git-svn command, such as "git svn
> info", on the cloned master repo:
>
> Use of uninitialized value $u in substitution (s///) at
> /mingw64/share/perl5/site_perl/Git/SVN.pm line 105.
> Use of uninitialized value $u in concatenation (.) or string at
> /mingw64/share/perl5/site_perl/Git/SVN.pm line 105.
> refs/remotes/origin/configuration: 'svn+ssh://10.0.1.1/repos/projectA'
> not found in ''
>
> In the mentioned SVN.pm file, after the line:
>
>                         my $u = (::cmt_metadata("$refname"))[0];
>
> I added the following four lines:
>
>                         if (not defined $u) {
>                                 warn "W: $refname does not exist in
> SVN; skipping";
>                                 next;
>                         }
>
> git-svn appears to operate correctly with this patch. This is my first
> time ever editing a perl script, so I apologize if I murdered an
> adorable animal just now.
>
> I'm sending this in so more knowledgeable git-svn developers can
> comment on this and fix this in the official distribution of git,
> assuming there is a bug here to fix.
>
> --
>     Jacob

This e-mail has gone ignored several months. Is the maintainer of git-svn on this mailing list? Should I submit this issue elsewhere?

-- 
    Jacob
Eric Wong· Jun 24, 2016, 19:35 UTC · re: Jacob Godserv · lore

Re: git-svn aborts with "Use of uninitialized value $u" when a non-svn-backed branch is present in remote

Jacob Godserv <jacobgodserv@gmail.com> wrote:
Show 39 quoted lines
> On Tue, Sep 22, 2015 at 2:48 PM, Jacob Godserv <jacobgodserv@gmail.com> wrote:
> > I found a specific case in which git-svn improperly aborts:
> >
> > 1. I created a git-svn repository, named "git-svn repo", by cloned an
> > svn repository via the git-svn tool.
> > 2. I created a normal git repository, named "configuration repo". I
> > renamed the master branch to "configuration". The initial commit adds
> > a README and some utility scripts.
> > 3. I created a bare repository, named "master repo".
> > 4. I pushed from the git-svn repo to the master repo.
> > 5. I pushed from the configuration repo to the master repo.
> >
> > The idea is the configuration branch, which is detached from any
> > git-svn history, can contain some useful tools, defaults, etc., that I
> > can share with teammates who want to use git on this svn project. It's
> > an odd use of git, but it has been working well.
> >
> > However, a vanilla distribution of Git for Windows 2.5.2 produces the
> > following error when running any git-svn command, such as "git svn
> > info", on the cloned master repo:
> >
> > Use of uninitialized value $u in substitution (s///) at
> > /mingw64/share/perl5/site_perl/Git/SVN.pm line 105.
> > Use of uninitialized value $u in concatenation (.) or string at
> > /mingw64/share/perl5/site_perl/Git/SVN.pm line 105.
> > refs/remotes/origin/configuration: 'svn+ssh://10.0.1.1/repos/projectA'
> > not found in ''
> >
> > In the mentioned SVN.pm file, after the line:
> >
> >                         my $u = (::cmt_metadata("$refname"))[0];
> >
> > I added the following four lines:
> >
> >                         if (not defined $u) {
> >                                 warn "W: $refname does not exist in
> > SVN; skipping";
> >                                 next;
> >                         }

Christian (Cc-ed) also noticed the problem a few weeks ago and took a more drastic approach by having git-svn die instead of warning: http://mid.gmane.org/1462604323-18545-1-git-send-email-chriscool@tuxfamily.org which landed as commit 523a33ca17c76bee007d7394fb3930266c577c02 in git.git: https://bogomips.org/mirrors/git.git/patch?id=523a33ca17c7

Is dying here too drastic and maybe warn is preferable?
Show 13 quoted lines
> > git-svn appears to operate correctly with this patch. This is my first
> > time ever editing a perl script, so I apologize if I murdered an
> > adorable animal just now.
> >
> > I'm sending this in so more knowledgeable git-svn developers can
> > comment on this and fix this in the official distribution of git,
> > assuming there is a bug here to fix.
> >
> > --
> >     Jacob
> 
> This e-mail has gone ignored several months. Is the maintainer of
> git-svn on this mailing list? Should I submit this issue elsewhere?

Sorry, I wasn't paying attention to the list at that time. It is customary to Cc: authors of the code in question (that also decentralizes our workflow in case vger is down), and also acceptable to send reminders after a week or two in case we're overloaded with other work.

Eric Wong· Jun 24, 2016, 20:06 UTC · lore

Re: git-svn aborts with "Use of uninitialized value $u" when a non-svn-backed branch is present in remote

Please don't drop Cc:, re-adding git@vger and Christian
Jacob Godserv <jacobgodserv@gmail.com> wrote:
Show 11 quoted lines
> > Christian (Cc-ed) also noticed the problem a few weeks ago
> > and took a more drastic approach by having git-svn die
> > instead of warning:
> > http://mid.gmane.org/1462604323-18545-1-git-send-email-chriscool@tuxfamily.org
> > which landed as commit 523a33ca17c76bee007d7394fb3930266c577c02
> > in git.git: https://bogomips.org/mirrors/git.git/patch?id=523a33ca17c7
> >
> > Is dying here too drastic and maybe warn is preferable?
> 
> In my opinion this is too drastic. It keeps me from storing
> git-specific data on a git-svn mirror.
I tend to agree, but will wait to see what Christian thinks.
Show 22 quoted lines
> Here's my setup:
>  - My git-svn mirror uses git-svn to create a git repo that mirrors
> svn history. This repository is then pushed to a clean bare
> repository. So far so good. Only svn-sourced branches exist.
>  - The git-svn mirror script also saves a copy of the git-svn
> configuration used to generate the git mirror repository in an
> "orphaned" branch called something like 'git-svn-conf'. This is
> completely separate from the svn history, and exists only for my
> git-svn purposes.
>  - On the "client" side, another script I wrote knows how to parse the
> git-svn configuration in that 'git-svn-conf' branch to properly
> reconfigure git-svn on the local machine, so I can use 'git svn'
> themselves to commit, etc., and still generate the same hashes so
> there's no forked history during the next mirror fetch.
> 
> Long story short: I have branches which aren't in SVN history for
> automated git-svn purposes.
> 
> It appears that simply skipping the branch in that loop fixes the
> issue. However, I don't know how the metadata is stored and what
> exactly that loop does, so I may be creating hidden side effects I
> have been lucky enough to not trigger yet.
Christian Couder· Jun 25, 2016, 08:39 UTC · re: Eric Wong · lore

Re: git-svn aborts with "Use of uninitialized value $u" when a non-svn-backed branch is present in remote

On Fri, Jun 24, 2016 at 10:06 PM, Eric Wong <e@80x24.org> wrote:
Show 16 quoted lines
> Please don't drop Cc:, re-adding git@vger and Christian
>
> Jacob Godserv <jacobgodserv@gmail.com> wrote:
>> > Christian (Cc-ed) also noticed the problem a few weeks ago
>> > and took a more drastic approach by having git-svn die
>> > instead of warning:
>> > http://mid.gmane.org/1462604323-18545-1-git-send-email-chriscool@tuxfamily.org
>> > which landed as commit 523a33ca17c76bee007d7394fb3930266c577c02
>> > in git.git: https://bogomips.org/mirrors/git.git/patch?id=523a33ca17c7
>> >
>> > Is dying here too drastic and maybe warn is preferable?
>>
>> In my opinion this is too drastic. It keeps me from storing
>> git-specific data on a git-svn mirror.
>
> I tend to agree, but will wait to see what Christian thinks.

Yeah a warning is probably enough. Another possibility would be to default to an error that tells people about a configuration variable that could let them decide depending on their workflow if this should be an error, a warning or just be ignored.

Eric Wong· Jul 2, 2016, 10:33 UTC · re: Christian Couder · lore

[PATCH] git-svn: warn instead of dying when commit data is missing

Christian Couder <christian.couder@gmail.com> wrote:
Show 17 quoted lines
> On Fri, Jun 24, 2016 at 10:06 PM, Eric Wong <e@80x24.org> wrote:
> > Jacob Godserv <jacobgodserv@gmail.com> wrote:
> >> > Christian (Cc-ed) also noticed the problem a few weeks ago
> >> > and took a more drastic approach by having git-svn die
> >> > instead of warning:
> >> > http://mid.gmane.org/1462604323-18545-1-git-send-email-chriscool@tuxfamily.org
> >> > which landed as commit 523a33ca17c76bee007d7394fb3930266c577c02
> >> > in git.git: https://bogomips.org/mirrors/git.git/patch?id=523a33ca17c7
> >> >
> >> > Is dying here too drastic and maybe warn is preferable?
> >>
> >> In my opinion this is too drastic. It keeps me from storing
> >> git-specific data on a git-svn mirror.
> >
> > I tend to agree, but will wait to see what Christian thinks.
> 
> Yeah a warning is probably enough.
OK, patch below.
> Another possibility would be to default to an error that tells people
> about a configuration variable that could let them decide depending on
> their workflow if this should be an error, a warning or just be
> ignored.

I think that's too much. I'm not a fan of having too many configuration variables to throw on users.

------8<------
Subject: [PATCH] git-svn: warn instead of dying when commit data is missing

It is possible to have refs globbed by git-svn which stores data purely in git; gently skip those instead of dying and assuming user error.

ref: http://mid.gmane.org/CALi1mtdtNF_GtzyPTbfb7N51wwxsFY7zm8hsgwxr3tHcZZboyg@mail.gmail.com
Suggested-by: Jacob Godserv <jacobgodserv@gmail.com>
Cc: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Eric Wong <e@80x24.org>
---
 perl/Git/SVN.pm | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index bee1e7d..018beb8 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -97,8 +97,12 @@ sub resolve_local_globs {
 				    "existing: $existing\n",
 				    " globbed: $refname\n";
 			}
-			my $u = (::cmt_metadata("$refname"))[0] or die
-			    "$refname: no associated commit metadata\n";
+			my $u = (::cmt_metadata("$refname"))[0];
+			if (!defined($u)) {
+				warn
+"W: $refname: no associated commit metadata from SVN, skipping\n";
+				next;
+			}
 			$u =~ s!^\Q$url\E(/|$)!! or die
 			  "$refname: '$url' not found in '$u'\n";
 			if ($pathname ne $u) {

-- 
EW

← back to recent threads