[PATCH] Change git-cvsimport to handle slashes in CVS tags

[PATCH] Change git-cvsimport to handle slashes in CVS tags

[Wayne Scott]

The Tcl/Tk CVS tree contains some tags like this one:
  dev-stubs-merge-8-1-3/9/99

CVS doesn't mind that tag, but git can't handle the slash
characters in the tag.  Just change those to underscore
so imports can complete.

Signed-off-by: Wayne Scott <wsc9tt@gmail.com>
---

 git-cvsimport.perl |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

applies-to: cf6439199f61d87dbb70fd7b43144e41462a359d
225c95454711467fc889c15cb3f7ca3230fce58d
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index bbb83fb..d71c30c 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -636,6 +636,7 @@ my $commit = sub {
                my($xtag) = $tag;
                $xtag =~ s/\s+\*\*.*$//; # Remove stuff like ** INVALID ** and *
* FUNKY **
                $xtag =~ tr/_/\./ if ( $opt_u );
+               $xtag =~ tr/\//_/;

                my $pid = open2($in, $out, 'git-mktag');
                print $out "object $cid\n".
---
0.99.8.GIT

Re: [PATCH] Change git-cvsimport to handle slashes in CVS tags

[Johannes Schindelin]

Hi,

http://www.gelato.unsw.edu.au/archives/git/0508/7825.html

Ciao,
Dscho

Re: [PATCH] Change git-cvsimport to handle slashes in CVS tags

[Linus Torvalds]

Hmm.. git can certainly handle slashes in tags, but you'd need to 
basically "mkdir" the path up to there before creating them. 

That's probably not the right thing to do for a tag that comes from the 
outside, since in git, the slashes work like in a filesystem, and should 
imply grouping (ie you might have a family of tags that is named by 
usage, and be called something like "release/xyz" or whatever).

Is "_" the right thing to replace it with, though? To me, "_" replaces 
either a space or a dash, while a slash could be replaced by something 
more like a special character.

Maybe it's just me, but your example "dev-stubs-merge-8-1-3/9/99" might
look nicer either of these ways:

 - dev-stubs-merge-8-1-3|9|99 (but "|" is hard to use with shell)
 - dev-stubs-merge-8-1-3.9.99 (CVS tags can't contain '.', right?)
 - dev-stubs-merge-8-1-3:9:99 (confuse with time?)
 - dev-stubs-merge-8-1-3+9+99 (one arithmetic op replaced by another)
 - dev-stubs-merge-8-1-3#9#99 (that's pretty ugly)
 - dev-stubs-merge-8-1-3?9?99 (Wayne might be right after all)
 - dev-stubs-merge-8-1-3_9_99 (maybe Wayne _is_ right?)

I dunno. But maybe we do want the option of just keeping it as a slash, 
and teach git-cvsimport to create the proper subdirectory prefixes.

I have no idea how to do that in perl, though. Right now it just does

	open(C,">$git_dir/refs/tags/$xtag")

how would you do "create file with all path components"?

		Linus

Re: [PATCH] Change git-cvsimport to handle slashes in CVS tags

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> I dunno. But maybe we do want the option of just keeping it as a slash, 
> and teach git-cvsimport to create the proper subdirectory prefixes.

How about doing both?

I think patch by Johannes to allow replacing slash to arbitrary
string is a reasonable thing to have, but somebody who uses
cvsimport needs to sign that off for me -- I do not regularly
use git-ANYimport myself.

> I have no idea how to do that in perl, though. Right now it just does
>
> 	open(C,">$git_dir/refs/tags/$xtag")
>
> how would you do "create file with all path components"?

Something like this? 

use File::Path;
my $file = "$git_dir/refs/tags/$xtag";
my ($dir) =  $file =~ m/(.*)\//;
mkpath($dir) && open C, ">$file";

Re: [PATCH] Change git-cvsimport to handle slashes in CVS tags

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> Is "_" the right thing to replace it with, though? To me, "_" replaces 
> either a space or a dash, while a slash could be replaced by something 
> more like a special character.
> 

If nothing else it creates a nice symmetry, since CVS can't use '.' in 
tags (which only is the most common character in nearly all versioning 
schemes), and which is commonly replaced by '_'.  We already have the -m 
option to change that back to dots, so we'd go:

'/' -> '_' -> '.'

... which at least means no info loss.

	-hpa