At Fri, 24 May 2013 12:44:35 -0400, Eli Barzilay wrote: > > > * The script should also take care to deal with files that got > > > removed in the past. > > > > Ditto. > > I don't believe that it's *not* doing this, so I did the double-check > in the form of a test.
You're right --- I misunderstood your example. Still, I'm happy enough with the result in your example. The conversion does preserve `git log --follow' results for the files that survive, which was my intended spec. And maybe it's better to explain my interest as `git blame', since my main interest in the history of a file is often how/why a particular bit of code ended up as it is. > What I'm saying is that if filter-branch using your script takes 20 > hours Just to confirm, my experiment on the main repo completed in right at 20 hours. (The `git log --follow's and `git blame's that I tried look good to me.) > * filter-branch one time using your script to reorganize the files > according to packages > * use filter-branch with a subdirectory filter 5 times to create > each repository > Total runtime: about 21 hours > > This latter use would end up with the final tree being exactly the > same (since you're talking about doing the reorganization within git), > but the history would be different since it's as if the files were > there the whole time. I don't see how that works. Since my script leaves each file in its original location for old commits, I expect a subdirectory `filter-branch' to still drop history for the old locations. In any case, I'm happy to sort out that detail later. If we agree that `git mv' before splitting is practical, though, that's all I need for now. >From my perspective, the important thing is to have the ability to just edit and move files around to sort out packages, instead of having the indirection of a script that edits and moves files around. _________________________ Racket Developers list: http://lists.racket-lang.org/dev
