[yt-dev] Final github repo

Tue Apr 18 20:35:59 PDT 2017

On Tue, Apr 18, 2017 at 10:31 PM, Kacper Kowalik <xarthisius.kk at gmail.com>
wrote:

> On 04/18/2017 09:47 PM, Nathan Goldbaum wrote:
> > On Tue, Apr 18, 2017 at 9:42 PM, Kacper Kowalik <xarthisius.kk at gmail.com
> >
> > wrote:
> >
> >> On 04/18/2017 09:34 PM, Nathan Goldbaum wrote:
> >>> Hi all,
> >>>
> >>> I think the github mirror we set up for testing purposes has been more
> or
> >>> less a success:
> >>>
> >>> https://github.com/yt-project/yt-test
> >>>
> >>> The mirroring seems to work well: the github repository is staying in
> >> sync
> >>> with the bitbucket repo every time we merge pull requests on bitbucket.
> >> To
> >>> make further work on transitioning to github easier, I'd like to settle
> >> on
> >>> what the final converted repo should like.
> >>>
> >>> For the purposes of discussion, I'd like to propose simply renaming the
> >>> yt-project/yt-test repo to be yt-project/yt and agreeing that the
> current
> >>> conversion is satisfactory. This means we'll agree not to use an
> >> alternate
> >>> conversion technique that will change git commit hashes.
> >>
> >> I think we should recreate it from scratch. I force-pushed to it once or
> >> twice stripping some commits. There's a high chance that one of the
> >> forks still have those, and they can be accidentally reintroduced.
> >> Moreover, it only has master(yt) branch. It lacks maintenance(stable),
> >> yt2(yt-2.x) and all the tags.
> >>
> >
> > Good point! I didn't realize you force-pushed. Did you force-push in a
> way
> > that would overwrite commits created in hg? In that case I agree with you
> > that we need to redo the conversion from scratch.
>
> AFAIR I stripped commits resulting from
> https://github.com/yt-project/yt-test/pull/1

I guess those commits are still in the reflog? I don't think in practice
that will matter.

>
>
> > If not, I don't think that requires recreating the repo, just pushing.
> >
> > I think all you need to do is add an "hg push" after this line (i.e. push
> > with no explicit bookmark, so all heads are pushed to the local git repo,
> > we still need the equivalent of "hg push -B master" so the master branch
> > gets updated correctly):
> >
> > https://bitbucket.org/yt_analysis/fido-prhandler/src/
> > e9a6e927d6fc4ce73e8f23908f463894c18ac430/handle_mirror_
> > webhook.py?at=default&fileviewer=file-view-default#
> > handle_mirror_webhook.py-40
> >
> > And then make it so this line does "git push --all":
> >
> > https://bitbucket.org/yt_analysis/fido-prhandler/src/
> > e9a6e927d6fc4ce73e8f23908f463894c18ac430/handle_mirror_
> > webhook.py?at=default&fileviewer=file-view-default#
> > handle_mirror_webhook.py-47
>
> Both branches and all tags are now pushed.
> Cheers,
> Kacerp
>

Thanks!

Any chance we can keep the names "yt-2.x" and "stable" instead of "yt-2"
and "maint"? I think that will help reduce confusion and ease porting
scripts.

> >
> >> Cheers,
> >> Kacper
> >>
> >>> Our mirror bot uses hg-git, and the converted repo hg-git produces
> isn't
> >>> necessarily perfect. In particular, two issues have come up:
> >>>
> >>> * Since git is more selective than mercurial about e-mail and username
> >>> formatting, there are a number of commits associated with dummy e-mail
> >>> addresses like none at none
> >>>
> >>> * Since we do most of our development on a branch named "yt" (not
> >> "default"
> >>> as is typical of mercurial repos) almost every commit in our history
> has
> >> a
> >>> comment in the git commit message recording that it hapenned on the
> "yt"
> >> or
> >>> "stable" branch. This makes it possible to round-trip from hg to git
> and
> >>> back to hg, but it's also some extra noise in every single commit
> >> message.
> >>>
> >>> We could in principle ameliorate these issues by using something
> besides
> >>> hg-git to do the conversion or by modifying hg-git to avoid these
> issues.
> >>> The former options will lose the nice property of being able to
> >> round-trip
> >>> and for others to independently export work from their forks. The
> latter
> >>> option will require us to modify hg-git and waiting for upstream hg-git
> >> to
> >>> review our changes, which might take a while, or telling everyone to
> use
> >> a
> >>> hacked version of hg-git.
> >>>
> >>> Personally, I don't think either of those options are worth the hassle
> >> for
> >>> what to me are minor annoyances. I think I've also ameliorated the
> >>> username/e-mail ambiguity in the converted history by adding a .mailmap
> >>> file to the repo:
> >>>
> >>> https://bitbucket.org/yt_analysis/yt/pull-requests/2582
> >>>
> >>> In addition, the mirroring process we have now seems to work well, so
> >> just
> >>> renaming the yt-test repo and calling the conversion final avoids a
> bunch
> >>> more work which will block further progress on the conversion.
> >>>
> >>> What do you all think? It would be great to get people's +/-1 on
> renaming
> >>> yt-test to yt on github.com/yt-project.
> >>>
> >>> Once we have a final repo name we will be able to start porting tooling
> >>> like the website generator without worrying about the name or content
> of
> >>> the final repo changing.
> >>>
> >>> -Nathan
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> yt-dev mailing list
> >>> yt-dev at lists.spacepope.org
> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> yt-dev mailing list
> >> yt-dev at lists.spacepope.org
> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > yt-dev mailing list
> > yt-dev at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >
>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20170418/742af35b/attachment.html>