Sorry, I meant to say "instead of Git". :) bugzilla-tool (or really scm.py) is completely agnostic wrt SCM system, so I just relaunched the commit-queue from an SVN checkout instead of a Git checkout. I expect it will continue to work just fine, if slightly slower.
-eric On Tue, Dec 22, 2009 at 10:47 PM, David Kilzer <[email protected]> wrote: > 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
