On 01/28/2014 05:58 PM, Kacper Kornet wrote: > On Mon, Jan 27, 2014 at 10:58:29AM -0800, Jonathan Nieder wrote: >> Hi, > >> Kacper Kornet wrote: > >>> The change in release numbering also breaks down gitolite v2 setups. One >>> of the gitolite commands, gl-compile-conf, expects the output of git >>> --version >>> to match /git version (\d+)\.(\d+)\.(\d+)/. > >>> I have no idea how big problem it is, as I don't know how many people >>> hasn't migrate to gitolite v3 yet. > >> http://qa.debian.org/popcon.php?package=gitolite says there are some. >> I guess soon we'll see if there are complaints. > >> http://gitolite.com/gitolite/migr.html says gitolite v2 is still >> maintained. Hopefully the patch to gitolite v2 to fix this would not >> be too invasive --- e.g., how about this patch (untested)? > >> Thanks, >> Jonathan > >> diff --git i/src/gl-compile-conf w/src/gl-compile-conf >> index f497ae5..8508313 100755 >> --- i/src/gl-compile-conf >> +++ w/src/gl-compile-conf >> @@ -394,8 +394,9 @@ die " >> the server. If it is not, please edit ~/.gitolite.rc on the server and >> set the \$GIT_PATH variable to the correct value\n >> " unless $git_version; >> -my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version >> (\d+)\.(\d+)\.(\d+)/); >> +my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version >> (\d+)\.(\d+)\.([^.-]*)/); >> die "$ABRT I can't understand $git_version\n" unless ($gv_maj >= 1); >> +$gv_patchrel = 0 unless ($gv_patchrel =~ m/^\d+$/); >> $git_version = $gv_maj*10000 + $gv_min*100 + $gv_patchrel; # now it's >> "normalised" > >> die "\n\t\t***** AAARGH! *****\n" . > > It works for 1.9.rc1 but I think it will fail with final 1.9. The > following version should be ok: > > diff --git a/src/gl-compile-conf b/src/gl-compile-conf > index f497ae5..c391468 100755 > --- a/src/gl-compile-conf > +++ b/src/gl-compile-conf > @@ -394,7 +394,7 @@ die " > the server. If it is not, please edit ~/.gitolite.rc on the server and > set the \$GIT_PATH variable to the correct value\n > " unless $git_version; > -my ($gv_maj, $gv_min, $gv_patchrel) = ($git_version =~ m/git version > (\d+)\.(\d+)\.(\d+)/); > +my ($gv_maj, $gv_min, undef, $gv_patchrel) = ($git_version =~ m/git version > (\d+)\.(\d+)(\.(\d+))?/); > die "$ABRT I can't understand $git_version\n" unless ($gv_maj >= 1); > $git_version = $gv_maj*10000 + $gv_min*100 + $gv_patchrel; # now it's > "normalised"
Gitolite v3 will be 2 years old in a month or so. I would prefer to use this as an opportunity to encourage people to upgrade; v2 really has nothing going for it now. People who cannot upgrade gitolite should simply cut that whole block of code and throw it out. Distro's should probably do that if they are still keeping gitolite v2 alive, because it is clearly not needed if the same distro is up to 1.9 of git! My policy has been to continue support for critical bugs. A bug that can be fixed by simply deleting the offending code block, with no harm done, is -- to my mind -- not critical enough :-) side note, Kacper: I'd use non-capturing parens than an undef in the destination list. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
