Done. The commit-queue is now using an SVN checkout of Git. -eric
On Tue, Dec 22, 2009 at 10:01 PM, Maciej Stachowiak <[email protected]> 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 <[email protected]> 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
