[webkit-dev] github mirror

[Adam Barth]

Tor,

I think we should retire the author rewriting script on GitHub.

Jame's is right that there's a lot of value in having git.webkit.org
and GitHub using the same hashes.  For example, both Eric and Gavin
requested that when they started using GitHub.

We would have some trouble adopting the author rewriting script on
git.webkit.org.  For example, the instructions for using git with
WebKit <http://trac.webkit.org/wiki/UsingGitWithWebKit> suggest
configuring git-svn to allow you to commit from your git repository.
When git-svn imports changes from SVN into your git repository, it
won't know to apply the author rewriting script.  That will cause your
local repository to diverge from an author-rewriting git.webkit.org,
which is bad times.

Therefore, it seems like the best way to synchronize the hashes
between git.webkit.org and GitHub is to retire the author rewriting
script on GitHub and do a non-fastforward push of the unrewritten
repository.  That will be somewhat disruptive for folks currently
using the GitHub repository, but at least it's only a one-time cost.

Adam


On Tue, Apr 24, 2012 at 11:06 AM, James Robinson <jamesr at google.com> wrote:
> On Tue, Apr 24, 2012 at 7:15 AM, Tor Arne Vestbø <tor.arne.vestbo at nokia.com>
> wrote:
>> On 24.04.12 16:04, ext Shezan Baig wrote:
>>> On Tue, Apr 24, 2012 at 9:55 AM, Adam Roben<aroben at webkit.org>  wrote:
>>>>> In what situation does this cause issues?
>>>>
>>>>
>>>> Probably the biggest issue is for people who've been using
>>>> git.webkit.org and now want to try out GitHub. Since the commits are
>>>> distinct between the two repositories, they have to do a full clone to
>>>> make the switch.
>>>
>>>
>>>
>>> In theory though, these users should be able to just add a remote to
>>> their existing clone.  Then it will just sync the commit objects, and
>>> not the trees and blobs.  Not ideal, they would have two different
>>> 'masters', but still doable, and not *that* much of an overhead.
>>> Switching between the different masters should also be fast since the
>>> trees will be the same.
>>
>>
>> Right, a fetch should ideally just pull down the commit objects, but it
>> appears git does not have this optimization. If it did, I don't think the
>> issue of two remote masters would be that big, since you would at some point
>> likely transition to use one of the mirrors anyways. And if not, having
>> multiple mirrors/remotes should be fine -- I'm using both the github and
>> gitorious mirror without any issues.
>>
>>
>>> But I agree these two repos should probably merge sooner rather than
>>> later, just to avoid confusion for new users etc :)
>>
>>
>> I would support that if it means cleaning up the author-script (which I'm
>> happy to do), and using that on webkit.org.
>
>
> Whatever we decide to do in the future, author rewriting seems like
> extremely low value compared to having matching SHA1s.  I think we should
> get a clone on github.com that matches the existing git.webkit.org SHA1s and
> then make sure that they stay in sync (either with rewriting or not, but
> whatever webkit.org does).
>
> - James
>
>>
>>
>> tor arne
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>