You mean it's using git-svn instead of just git now? In my original message, I meant that it should be using a local svn working directory (no git at all) to fix the file history issue. I'm sure that would present a number of issues, though, not the least of which would be much slower operation.
Dave On Tue, December 22, 2009 8:29:09 PM, Eric Seidel wrote: > Done. The commit-queue is now using an SVN checkout of Git. > > -eric > > On Tue, Dec 22, 2009 at 10:01 PM, Maciej Stachowiak wrote: > > > > On Dec 21, 2009, at 12:22 PM, Eric Seidel wrote: > > > >> I'm happy to move the commit-queue to use an SVN checkout instead if > >> that would be a desired change. :) > > > > Yes please. > > > > - Maciej > > > >> > >> -eric > >> > >> On Mon, Dec 21, 2009 at 2:20 PM, David Kilzer wrote: > >>> > >>> If you want to make sure you're not going to lose history, you should use > >>> svn directly. The svn-apply script already knows all the magic to do the > >>> right thing...if you used svn-create-patch to create the patch *and* if > >>> you're committing to an svn repository. > >>> > >>> The "git svn dcommit" command (especially in newer versions of git) will > >>> try to relate source files that are moved or copied, but it only uses a > >>> heuristic when committing. Using the "--dry-run" switch may provide some > >>> insight into whether git will show copied/moved files or not, but I've > >>> never > >>> tested it to make sure how accurate it is compared to the actual commit. > >>> > >>> If the commit-queue is using a git repository, it will only work as well > >>> as git's heuristic does. > >>> > >>> Setting "[diff] renames = copies" in ~/.gitconfig or in your .git/config > >>> file for each project will make git diff try to do rename detection when > >>> creating a patch. (You may also use "--find-copies-harder" or > >>> "--find-copies-harder -C" switches on the command line.) This will > >>> provide > >>> hints in the git diff about file renames, but it still only uses a > >>> heuristic, and svn-apply currently doesn't know about these hints: > >>> > >>> Bug 32834: svn-apply should handle git patches with similarity index, > >>> rename and copy directives > >>> https://bugs.webkit.org/show_bug.cgi?id=32834 > >>> > >>> Also note that --find-copies-harder doesn't work on small files (files > >>> under a certain number of lines), although I don't know what that > >>> threshold > >>> is off the top of my head. > >>> > >>> I've also seen git think that a new header file (whose license text is > >>> larger than the header code itself) is actually a copy of another > >>> similarly > >>> short header file when doing large merges. > >>> > >>> Again, you should use svn if you want to ensure file history. > >>> > >>> Dave > >>> > >>> > >>> On Mon, December 21, 2009 10:19:03 AM, Eric Seidel wrote: > >>> > >>>> If such git magic exists, it would be possible to teach svn-apply to use > >>>> it. > >>>> > >>>> -eric > >>>> > >>>> On Mon, Dec 21, 2009 at 12:05 PM, Darin Adler wrote: > >>>>> > >>>>> On Dec 21, 2009, at 8:31 AM, Pavel Feldman wrote: > >>>>> > >>>>>> Sorry about that - it was git's decision. > >>>>> > >>>>> It that’s the case, then please consider not using git for this type of > >>>>> change > >>>> > >>>> in the future. We don’t want to unnecessarily lose repository history > >>>> when such > >>>> changes occur. > >>>>> > >>>>> If a git expert can show you how to do such changes with git while > >>>>> preserving > >>>> > >>>> the Subversion history, then that gives you another option. > >>>>> > >>>>> -- Darin > >>>> > >>> > >> _______________________________________________ > >> webkit-dev mailing list > >> [email protected] > >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
