[webkit-dev] [webkit-changes] [52439] trunk/WebCore

[Eric Seidel]

Done.  The commit-queue is now using an SVN checkout of Git.

-eric

On Tue, Dec 22, 2009 at 10:01 PM, Maciej Stachowiak <mjs at apple.com> 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 <ddkilzer at webkit.org> 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
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>