Blog post idea : converting and keeping track of an upstream Git repo
This is basically what we're doing for the forked Heptapod components, but it can be of use to someone else.
Extract from Mattermost chat with @burbon. All the needed info is in there, it just has to be formalized.
What is recommended/correct workflow to work with git repositories? I'm using hggit. I enabled bookmarks for the repo. Locally, after it was cloned from git repo, it looks like:
hg: @ changeset: 3:da91c65bc8a8 | bookmark: master | tag: 0.0.2 | tag: default/master | tag: tip | parent: 0:6978c5dfd1fd | user: superuser | date: Mon Sep 21 21:54:30 2020 +0100 | summary: test3 | | o changeset: 2:a98fe450e13e |/ bookmark: test2 | tag: default/test2 | parent: 0:6978c5dfd1fd | user: superuser | date: Mon Sep 21 21:53:41 2020 +0100 | summary: test2 | | o changeset: 1:8244a14a251a |/ bookmark: test1 | tag: default/test1 | user: superuser | date: Mon Sep 21 21:52:51 2020 +0100 | summary: test1 | o changeset: 0:6978c5dfd1fd tag: 0.0.1 user: superuser date: Mon Sep 21 21:52:28 2020 +0100 summary: init
I'm pushing with:
hg push -f --new-branch remote: adding changesets remote: adding manifests remote: adding file changes remote: added 4 changesets with 4 changes to 1 files (+2 heads) remote: To create a merge request for wild/8244a14a251a6b6c87ccbb9a68fd448d7ebb93a2, visit: remote: http://Stuff/foobar/-/merge_requests/new?merge_request%5Bsource_branch%5D=wild%2F8244a14a251a6b6c87ccbb9a68fd448d7ebb93a2 remote: To create a merge request for wild/da91c65bc8a8ccba735d1553f9716342a97d302d, visit: remote: http://Stuff/foobar/-/merge_requests/new?merge_request%5Bsource_branch%5D=wild%2Fda91c65bc8a8ccba735d1553f9716342a97d302d remote: To create a merge request for wild/a98fe450e13e58fd6c1ef5728221439a342e9ad4, visit: remote: http://Stuff/foobar/-/merge_requests/new?merge_request%5Bsource_branch%5D=wild%2Fa98fe450e13e58fd6c1ef5728221439a342e9ad4
What do i do to get those wild branches named after hg bookmarks/git branches? The only branch with actual name that gets created is default. (edited)
Tue, Sep 22, 2020 Georges Racinet 10:37 AM
What happens is that you're not pushing the bookmarks. If you do hg push -fB master, hg push -fB test1 etc, it should work, and the "wild" GitLab branches will be removed
Błażej Cegiełka 12:44 PM
And what do you do with git tags? i have them in hg-git converted repo, but they are not looking pushed into heptapod - they don't show up in UI, and no tags are present when project is hg-cloned from heptapod.
Georges Racinet 1:05 PM
@burbon hg-git puts the Git tags in .hg/git-tags and has the related code so that hg tags displays them, but they aren't pushed
what I'm doing to include them in regular hg tags is to actually commit them in .hgtags but I don't want to introduce new commits on top of the ones converted from Git (would break subsequent conversions)
so what I'm doing, is that I started a dedicated (named) branch, actually a new root of the repo, something like
hg up 000000000000 hg branch git-tags cp .hg/git-tags .hgtags hg add .hgtags hg ci -m "Imported Git tags as Mercurial tags"
and then, each time I make a new import, I commit that file again in the dedicated branch. What matters for Mercurial tags system is the content of .hgtags in any absolute repository head.