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.
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@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
+1, thanks for this!
Sent from my iPhone
On Apr 18, 2017, at 10:34 PM, Nathan Goldbaum nathan12343@gmail.com 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.
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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.
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Tue, Apr 18, 2017 at 9:42 PM, Kacper Kowalik xarthisius.kk@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.
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
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Tue, Apr 18, 2017 at 9:47 PM, Nathan Goldbaum nathan12343@gmail.com wrote:
On Tue, Apr 18, 2017 at 9:42 PM, Kacper Kowalik xarthisius.kk@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.
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/e9a6e92 7d6fc4ce73e8f23908f463894c18ac430/handle_mirror_webhook.py?a t=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/e9a6e92 7d6fc4ce73e8f23908f463894c18ac430/handle_mirror_webhook.py?a t=default&fileviewer=file-view-default#handle_mirror_webhook.py-47
Hmm, I think you might actually need to create "stable" and "yt-2.x" bookmarks and push them analogously to master. And I guess "git push --tags".
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On 04/18/2017 09:47 PM, Nathan Goldbaum wrote:
On Tue, Apr 18, 2017 at 9:42 PM, Kacper Kowalik xarthisius.kk@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
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
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Tue, Apr 18, 2017 at 10:31 PM, Kacper Kowalik xarthisius.kk@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@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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On 04/18/2017 10:35 PM, Nathan Goldbaum wrote:
On Tue, Apr 18, 2017 at 10:31 PM, Kacper Kowalik xarthisius.kk@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@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.
I don't know how to do that :) What we are mapping to git branches are hg bookmarks, and you can't have bookmark matching named branch:
$ hg bookmark yt-2.x abort: a bookmark cannot have the name of an existing branch
Cheers, Kacper
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Wed, Apr 19, 2017 at 7:40 AM, Kacper Kowalik xarthisius.kk@gmail.com wrote:
I don't know how to do that :) What we are mapping to git branches are hg bookmarks, and you can't have bookmark matching named branch:
$ hg bookmark yt-2.x abort: a bookmark cannot have the name of an existing branch
Cheers, Kacper
I created a pull request that should fix this issue:
https://github.com/yt-project/fido-prhandler/pull/1
In addition this pull request sets the mirror target to the final repo location, in expectation of getting approval in this thread.
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
addresses like none@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I'm okay with renaming it, but honestly I would kind of like to get rid of our first PR being "test" and our second being "grid visitors". I *think*, but am not *sure*, that this might mess up a bunch of things with getting issue number redirection.
On Wed, Apr 19, 2017 at 11:08 AM, Nathan Goldbaum nathan12343@gmail.com wrote:
On Wed, Apr 19, 2017 at 7:40 AM, Kacper Kowalik xarthisius.kk@gmail.com wrote:
I don't know how to do that :) What we are mapping to git branches are hg bookmarks, and you can't have bookmark matching named branch:
$ hg bookmark yt-2.x abort: a bookmark cannot have the name of an existing branch
Cheers, Kacper
I created a pull request that should fix this issue:
https://github.com/yt-project/fido-prhandler/pull/1
In addition this pull request sets the mirror target to the final repo location, in expectation of getting approval in this thread.
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
> addresses like none@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@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Wed, Apr 19, 2017 at 11:11 AM, Matthew Turk matthewturk@gmail.com wrote:
I'm okay with renaming it, but honestly I would kind of like to get rid of our first PR being "test" and our second being "grid visitors". I *think*, but am not *sure*, that this might mess up a bunch of things with getting issue number redirection.
Fair enough, let's just blow away yt-test and regenerate it once my PR is merged.
On Wed, Apr 19, 2017 at 11:08 AM, Nathan Goldbaum nathan12343@gmail.com wrote:
On Wed, Apr 19, 2017 at 7:40 AM, Kacper Kowalik xarthisius.kk@gmail.com wrote:
I don't know how to do that :) What we are mapping to git branches are hg bookmarks, and you can't have bookmark matching named branch:
$ hg bookmark yt-2.x abort: a bookmark cannot have the name of an existing branch
Cheers, Kacper
I created a pull request that should fix this issue:
https://github.com/yt-project/fido-prhandler/pull/1
In addition this pull request sets the mirror target to the final repo location, in expectation of getting approval in this thread.
> 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
>> addresses like none@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@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > >
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (4)
-
John ZuHone -
Kacper Kowalik -
Matthew Turk -
Nathan Goldbaum