Re: [git-users] git svn dcommit: Use of uninitialized value $rec in scalar chomp at /usr/share/perl5/Git.pm line 557, <$fh> chunk 2.
The devs are aware of the issue, a fix is in progress. Sorry for not
looking into the dev mailing list first.
Am 06.04.2018 um 10:47 schrieb Uli He:
Today, I observed this:
|
uli$ git svn dcommit
Committingto https://{censored} ...
Useof uninitialized value $rec inscalar chomp at
/usr/share/perl5/Git.pm line 557,<$fh>chunk 2.
M modules/wws_asfast/templates/http/generic.vhost.erb
Committedr47284
M modules/wws_asfast/templates/http/generic.vhost.erb
r47284 =f83439cfa471ce4be145a475ba8fe720425d40c3
(refs/remotes/svnclone/trunk)
Nochanges between dcf8a0dfa557687ef27f74cb2a7d22c3f963c1a7
andrefs/remotes/svnclone/trunk
Resettingto the latest refs/remotes/svnclone/trunk
|
I've never seen the warning for previous versions of git (2.16.3 and
older). I'm using 2.17.0 at the moment. I'm on Linux.
The warning seems to show up on every dcommit:
|
uli$ git svn dcommit
Committingto https://{censored} ...
Authenticationrealm: scp@dp
Passwordfor'uli':
Useof uninitialized value $rec inscalar chomp at
/usr/share/perl5/Git.pm line 557,<$fh>chunk 2.
M source/_posts/2012-05-18-markdown.md
Committedr722
M source/_posts/2012-05-18-markdown.md
r722 =e2a9ea0ca4cf6667f4fd1da32dcc9f1014b9cb06
(refs/remotes/svnclone/trunk)
Useof uninitialized value $rec inscalar chomp at
/usr/share/perl5/Git.pm line 557,<$fh>chunk 2.
A source/_posts/2016-11-21-ubuntu-1604.markdown
Committedr723
A source/_posts/2016-11-21-ubuntu-1604.markdown
r723 =eb5fcdaa58cfda9e7614b4bafd62b1c3b616d198
(refs/remotes/svnclone/trunk)
Useof uninitialized value $rec inscalar chomp at
/usr/share/perl5/Git.pm line 557,<$fh>chunk 2.
M source/_posts/2012-05-18-markdown.md
Committedr724
M source/_posts/2012-05-18-markdown.md
r724 =f88707776360439b9ddfe0cae30d290ece49374e
(refs/remotes/svnclone/trunk)
Useof uninitialized value $rec inscalar chomp at
/usr/share/perl5/Git.pm line 557,<$fh>chunk 2.
M source/_posts/2016-11-21-ubuntu-1604.markdown
Committedr725
...
|
Shall I try to fix it? Are there contribution guidelines?
Best regards, Uli
--
You received this message because you are subscribed to a topic in the
Google Groups "Git for human beings" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/git-users/DesrlsakXzI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
git-users+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[git-users] git svn dcommit: Use of uninitialized value $rec in scalar chomp at /usr/share/perl5/Git.pm line 557, <$fh> chunk 2.
Today, I observed this:
uli$ git svn dcommit
Committing to https://{censored} ...
Use of uninitialized value $rec in scalar chomp at /usr/share/perl5/Git.pm
line 557, <$fh> chunk 2.
M modules/wws_asfast/templates/http/generic.vhost.erb
Committed r47284
M modules/wws_asfast/templates/http/generic.vhost.erb
r47284 = f83439cfa471ce4be145a475ba8fe720425d40c3 (refs/remotes/svnclone/
trunk)
No changes between dcf8a0dfa557687ef27f74cb2a7d22c3f963c1a7 and refs/remotes
/svnclone/trunk
Resetting to the latest refs/remotes/svnclone/trunk
I've never seen the warning for previous versions of git (2.16.3 and
older). I'm using 2.17.0 at the moment. I'm on Linux.
The warning seems to show up on every dcommit:
uli$ git svn dcommit
Committing to https://{censored} ...
Authentication realm: scp@dp
Password for 'uli':
Use of uninitialized value $rec in scalar chomp at /usr/share/perl5/Git.pm
line 557, <$fh> chunk 2.
M source/_posts/2012-05-18-markdown.md
Committed r722
M source/_posts/2012-05-18-markdown.md
r722 = e2a9ea0ca4cf6667f4fd1da32dcc9f1014b9cb06 (refs/remotes/svnclone/trunk
)
Use of uninitialized value $rec in scalar chomp at /usr/share/perl5/Git.pm
line 557, <$fh> chunk 2.
A source/_posts/2016-11-21-ubuntu-1604.markdown
Committed r723
A source/_posts/2016-11-21-ubuntu-1604.markdown
r723 = eb5fcdaa58cfda9e7614b4bafd62b1c3b616d198 (refs/remotes/svnclone/trunk
)
Use of uninitialized value $rec in scalar chomp at /usr/share/perl5/Git.pm
line 557, <$fh> chunk 2.
M source/_posts/2012-05-18-markdown.md
Committed r724
M source/_posts/2012-05-18-markdown.md
r724 = f88707776360439b9ddfe0cae30d290ece49374e (refs/remotes/svnclone/trunk
)
Use of uninitialized value $rec in scalar chomp at /usr/share/perl5/Git.pm
line 557, <$fh> chunk 2.
M source/_posts/2016-11-21-ubuntu-1604.markdown
Committed r725
...
Shall I try to fix it? Are there contribution guidelines?
Best regards, Uli
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[git-users] git svn dcommit: Your client is too old
Hello I have been using SVN on windows for a while (Tortoise) and now I am trying to switch to git. Since most people in my group are SVN lovers, I was quite happy seeing that I could use git with the existing SVN repository that the rest of the group is using. However I encounter the following problem: $git svn clone X - works fine, I got the whole section of the repository as expected, nice! now I added some file and try to commit it to the SVN repository $git svn dcommit - here I get an error as follows Committing to X A test.txt ERROR from SVN: A repository hook failed: Commit blocked by start-commit hook (exit code 1) with output: Your client is too old to commit to this repository. A version 1.5 or later client is required. W: bed0a231def621f00722a4f9444057b7ae81bd9d and refs/remotes/git-svn differ, usi ng rebase: :100644 00 08cf6101416f0ce0dda3c80e627f333854c4085c D test.txt Current branch master is up to date. ERROR: Not all changes have been committed into SVN, however the committed ones (if any) seem to be successfully integrated into the working tree. Please see the above messages for details. After searching around it seems that git svn is using the existing SVN on the system(?) which is quite up to date as I checked (from within git bash): $ svn --version svn, version 1.8.3 (r1516576) compiled Aug 27 2013, 22:13:03 on x86-microsoft-windows Strangly, the svn within git seems to be old, altough my git is also up to date: $ git svn --version git-svn version 1.8.5.2.msysgit.0 (svn 1.4.6) Can anyone guide me in a direction how to update git-svn to at least 1.5? Any help is appreciated. Thanks a lot, Sebastian -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] git svn dcommit: Your client is too old
On Tue, 7 Jan 2014 09:04:49 -0800 (PST) Sebastian Bürgel s.buer...@googlemail.com wrote: I have been using SVN on windows for a while (Tortoise) and now I am trying to switch to git. Since most people in my group are SVN lovers, I was quite happy seeing that I could use git with the existing SVN repository that the rest of the group is using. However I encounter the following problem: [...] Your client is too old to commit to this repository. A version 1.5 or later client is required. [...] After searching around it seems that git svn is using the existing SVN on the system(?) No, this is a wrong assumption: Git for Windows packages Subversion libraries with itself. You might find them under the bin directory in your Git installation directory. $ git svn --version git-svn version 1.8.5.2.msysgit.0 (svn 1.4.6) And yes, Subversion client libraries packaged with Git for Windows are severely outdated. This is an unfortunately known issue. Can anyone guide me in a direction how to update git-svn to at least 1.5? Not an easy task [1]. Many have tried and failed. To this date, no one seemed to want a newer Subversion client libraries packaged badly enough to pass all the obstacles while dealing with this. 1. http://bit.ly/1cWhFQ5 -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] git svn dcommit: Your client is too old
Thank you very much for the clarification. I don't think I'm able to solve those issues. Wouldn't it be a viable option to offer git for Windows not bundled with an outdated svn but just use the systems svn? Then users would have to install two programs if they decide to use git-svn. Of course i'm not sure if this is technically feasible though. Just trying to see some workarounds because this would give git a strategically strong position of sneaking into existing svn systems. On Jan 7, 2014 6:26 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Tue, 7 Jan 2014 09:04:49 -0800 (PST) Sebastian Bürgel s.buer...@googlemail.com wrote: I have been using SVN on windows for a while (Tortoise) and now I am trying to switch to git. Since most people in my group are SVN lovers, I was quite happy seeing that I could use git with the existing SVN repository that the rest of the group is using. However I encounter the following problem: [...] Your client is too old to commit to this repository. A version 1.5 or later client is required. [...] After searching around it seems that git svn is using the existing SVN on the system(?) No, this is a wrong assumption: Git for Windows packages Subversion libraries with itself. You might find them under the bin directory in your Git installation directory. $ git svn --version git-svn version 1.8.5.2.msysgit.0 (svn 1.4.6) And yes, Subversion client libraries packaged with Git for Windows are severely outdated. This is an unfortunately known issue. Can anyone guide me in a direction how to update git-svn to at least 1.5? Not an easy task [1]. Many have tried and failed. To this date, no one seemed to want a newer Subversion client libraries packaged badly enough to pass all the obstacles while dealing with this. 1. http://bit.ly/1cWhFQ5 -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] git svn dcommit
Hi, It has been a while since I used git svn. Can you help me with the following error? Can't call method “full_url” on an undefined value at /usr/lib/git-core/git-svn line 425 This happens when I call git svn dcommit after I cloned an empty svn repository with git svn clone, added several files (including a snapshot of another git repository) with git add, and git commit -a. Regards, Johannes -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] git svn dcommit after git rebase
Hi Daniel, it makes sense, thanks a lot for your detailed answer. I guess this basically means that in most cases you cannot use git rebase if you're working with subversion repositories. Simone On Wed, Oct 3, 2012 at 11:55 AM, Daniel P. Wright d...@dpwright.com wrote: Simone (Oct03日（Wed）) Hello, I have a git local branch tracking a svn remote branch. I noticed that if I git rebase that branch onto another local branch (tracking a different svn remote branch) then the dcommit I do on the first goes to the remote of the second. IOW branches: *feature1-local* tracks remote svn *feature1*, *master* tracks remote *trunk* git checkout feature1-local git rebase feature1-local master git svn dcommit -- commits to *trunk* * * I would expect that dcommitting feature1-local would commit to feature1 svn remote branch rather than the trunk. git-svn dcommits to the branch that the closest parent commit which has been checked in is on[*]. You may have noticed that every commit which has been dcommited has some git-svn-id metadata attached to the commit message. git-svn steps back through the history until it finds a commit containing this line, and then uses it to determine the branch it belongs to. You can show which commit that is by executing the following: git show --first-parent HEAD --grep git-svn-id -1 If you have no commits in feature1 (on svn), then your commits on feature1-local (local commits, with no git-svn-id) will be reapplied on top of the current master, and tracing the commits back to the first one with a git-svn-id will indeed give you one on the master branch, pointing to trunk. If you do have commits in feature1, you have a rather bigger problem. In SVN, the tree looks like this, say: --A--B--C--D--E--F - trunk \ -G--H--I - feature1 But in git, it looks like this: --A--B--C--D--E--F- trunk \ -G--H--I - feature1 That is to say, commits D, E, and F exist on feature1 in git, and are BEFORE the feature commits G, H, and I. SVN has no way to rewrite history like that, so when you try to git svn dcommit it I'm actually not sure what it will do, but it won't be what you expect. I wrote on a similar subject on this list a week or so back -- I'm afraid Google's web interface messes up the diagrams a bit, but you can see the post here if you'd like: https://groups.google.com/forum/?hl=jafromgroups=#!topic/git-users/8h1xHsTqShE The gist of it is, you need to be aware of which commits are local to your git repository, and which have already been dcommitted to (or pulled from) the subversion server. For the latter set, you have to be careful about which git functionality you make use of, since subversion doesn't support all of it. In the above case, I don't think there's any way around doing a subversion-style merge from trunk to feature1 (you can do it in git, if you like, by merging master into feature1-local with the --squash option), and then again merging your changes from feature1 back into master when you're finished. Hope that helps, -- Dani. [*] Most of the time. I found myself in the situation the other day when it was *not* doing this, because I had done some weird archaeology to my commit tree which resulted in the closest parent commit's hash not matching what git-svn thought it should be. I had to hack the /usr/share/perl5/vendor_perl/Git/SVN.pm file to skip the hash check and perform the operation, after which it righted itself and I could remove the hack. I still don't understand this properly, but it shouldn't happen unless you're fiddling with git-svn's internals anyway. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/0E8qpgzFE04J. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] git svn dcommit after git rebase
Simone (Oct03日（Wed）) Hello, I have a git local branch tracking a svn remote branch. I noticed that if I git rebase that branch onto another local branch (tracking a different svn remote branch) then the dcommit I do on the first goes to the remote of the second. IOW branches: *feature1-local* tracks remote svn *feature1*, *master* tracks remote *trunk* git checkout feature1-local git rebase feature1-local master git svn dcommit -- commits to *trunk* * * I would expect that dcommitting feature1-local would commit to feature1 svn remote branch rather than the trunk. git-svn dcommits to the branch that the closest parent commit which has been checked in is on[*]. You may have noticed that every commit which has been dcommited has some git-svn-id metadata attached to the commit message. git-svn steps back through the history until it finds a commit containing this line, and then uses it to determine the branch it belongs to. You can show which commit that is by executing the following: git show --first-parent HEAD --grep git-svn-id -1 If you have no commits in feature1 (on svn), then your commits on feature1-local (local commits, with no git-svn-id) will be reapplied on top of the current master, and tracing the commits back to the first one with a git-svn-id will indeed give you one on the master branch, pointing to trunk. If you do have commits in feature1, you have a rather bigger problem. In SVN, the tree looks like this, say: --A--B--C--D--E--F - trunk \ -G--H--I - feature1 But in git, it looks like this: --A--B--C--D--E--F- trunk \ -G--H--I - feature1 That is to say, commits D, E, and F exist on feature1 in git, and are BEFORE the feature commits G, H, and I. SVN has no way to rewrite history like that, so when you try to git svn dcommit it I'm actually not sure what it will do, but it won't be what you expect. I wrote on a similar subject on this list a week or so back -- I'm afraid Google's web interface messes up the diagrams a bit, but you can see the post here if you'd like: https://groups.google.com/forum/?hl=jafromgroups=#!topic/git-users/8h1xHsTqShE The gist of it is, you need to be aware of which commits are local to your git repository, and which have already been dcommitted to (or pulled from) the subversion server. For the latter set, you have to be careful about which git functionality you make use of, since subversion doesn't support all of it. In the above case, I don't think there's any way around doing a subversion-style merge from trunk to feature1 (you can do it in git, if you like, by merging master into feature1-local with the --squash option), and then again merging your changes from feature1 back into master when you're finished. Hope that helps, -- Dani. [*] Most of the time. I found myself in the situation the other day when it was *not* doing this, because I had done some weird archaeology to my commit tree which resulted in the closest parent commit's hash not matching what git-svn thought it should be. I had to hack the /usr/share/perl5/vendor_perl/Git/SVN.pm file to skip the hash check and perform the operation, after which it righted itself and I could remove the hack. I still don't understand this properly, but it shouldn't happen unless you're fiddling with git-svn's internals anyway. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/0E8qpgzFE04J. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
