importing git branches as named branches work with git-remote-hg

[Uwe Brauer]

Hi

I just found out, that

1. if I use Felipe's Contreras git-remote-hg plugin

2. I can push from a local (cloned) git repository to a new (empty)
mercurial repository, where

3. git branches that are then converted to named hg branches.

4. Since I use Manuel's Jacob patch for exporting named branches as
git branches,


I tested the following workflow: [1]

1. hg-repo-named-branch---> gitlab

2. Other git users push or create branches

3. Clone the new commits with git

git(clone-gitlab)-->local git-repository

4. Use Felip's plugit -->git-remote-hg-->new-hg-local

5. Add new commits in new-hg-local

6. Then (hg-git) new-hg-local-->gitlab


seems to work without problems

Regards

Uwe Brauer





Footnotes:
[1] I wrote down the detailed steps in a README file you can find in https://gitlab.com/kalthad/named-branch-only


--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

[Felipe Contreras]

On Sun, Mar 26, 2023 at 3:13 AM Uwe Brauer <o...@mat.ucm.es> wrote:

> I just found out, that
>
> 1. if I use Felipe's Contreras git-remote-hg plugin
>
> 2. I can push from a local (cloned) git repository to a new (empty)
> mercurial repository, where
>
> 3. git branches that are then converted to named hg branches.
>
> 4. Since I use Manuel's Jacob patch for exporting named branches as
> git branches,

That patch is interesting. If you specify the template as
`refs/heads/branches/{branch}` then git-remote-hg will know how these
branches are meant to be pushed.

> I tested the following workflow: [1]

There's a mistake there:

git push my-mercurial-remote feature:branches/feature
git push my-mercurial-remote stable:branches/stable

The order should be the other way around, otherwise the commits in
both branches will appear to be on the "feature" branch in Mercurial,
when they should be in "stable".

I see the git repository you generated doesn't have this problem, so
you didn't actually do them in this order.

And you mentioned this caveat:

> The only caveat is that you *cannot* pull with the hg-git plugin, (all new commits will endup on the default branch where you don't want them)

If there was a mirror for Manuel Jacob's patch to specify a template
for how branches should be imported (rather than exported), then you
could use "branches/stable" instead of "stable" in your git
repository, and everything would work.

This also would have the advantage that you don't have to specify a
refspec while pushing.

Instead of doing:

git push hg-remote stable:branches/stable

You could just do:

git push hg-remote branches/stable

Or just:

git push hg-remote

git-remote-hg will know which mercurial branch you want your commits to have.

Cheers.

--
Felipe Contreras

[Uwe Brauer]

> On Sun, Mar 26, 2023 at 3:13 AM Uwe Brauer <o...@mat.ucm.es> wrote:

> That patch is interesting. If you specify the template as
> `refs/heads/branches/{branch}` then git-remote-hg will know how these
> branches are meant to be pushed.

> There's a mistake there:

> git push my-mercurial-remote feature:branches/feature
> git push my-mercurial-remote stable:branches/stable

This is an issue I have to understand: which git branch to push first.
I usually do the following.

1. I clone a git repository (say auctex) with hg-git,

2. then all git branches are imported as g bookmarks

3. Hg bookmark tells me where in the graph the bookmarks are
located.

4. I then, using your plugin push the gitbranches first that look
the oldest in the graph.

Is this sensible or what should be the criterion?

> The order should be the other way around, otherwise the commits in
> both branches will appear to be on the "feature" branch in Mercurial,
> when they should be in "stable".

> I see the git repository you generated doesn't have this problem, so
> you didn't actually do them in this order.

> And you mentioned this caveat:

> If there was a mirror for Manuel Jacob's patch to specify a template
> for how branches should be imported (rather than exported), then you
> could use "branches/stable" instead of "stable" in your git
> repository, and everything would work.

Unfortunately this patch seems to be forgotten and nobody want even to
merge it into the release branch.


I have another also important question, suppose after pushing the git
branches as named branches to my hg repository, I add a commit to say the
stable branch (it seems that I could push this directly via hg-git to
the remote repository, but maybe one day this does not work, so I would
like to know how to pull first with git and the push to remote)

1. I add a new commit to the stable branch, how to I pull that?

git checkout stable
git pull my-mercurial-remote stable
or
git pull my-mercurial-remote branches/stable

Regards