On Apr 10, Robby Findler wrote: > Another alternative is, of course, to not migrate that stuff (right?)
Sure. That's roughly what I meant in the last sentence -- you just recreate any tags you want in your own clone of the repository. (But I will of course have git tags that correspond to the svn release tags.) > On Sat, Apr 10, 2010 at 4:30 PM, Eli Barzilay <[email protected]> wrote: > > On Apr 10, David Herman wrote: > >> Forgive me for seeking Cliff Notes, but if we've only used branches > >> as "tags" -- to wit, branches but no merges -- are we ok without > >> additional action on our part? > > > > These fall under the category of branches that you'd want to preserve > > in the migration. That is: I need to be told about them explicitly, > > but in addition I need to be told to convert them to a tag. But if > > this is truly like a tag, with no commits on the branch, then you can > > just tell me which revision number it is, and creating it in the > > converted git repository is even easier this way. > > > > And the same applies for the post-migration part: once the repository > > is set up, you clone it and get your tag, then I remove it from the > > server and you keep it (unless it's a tag with a public utility). > > This means that an alternative for all of this is to check the commit > > message that you're interested in, and then create the tag yourself in > > the converted git and avoid all the hassle. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
