hg-git: push -d default seems not to work.

[Matt Harbison]

On Fri, 05 May 2017 16:26:45 -0400, Uwe Brauer <oub at mat.ucm.es> wrote:

>
>     > On Fri, May 5, 2017 at 5:10 AM, Uwe Brauer <oub at mat.ucm.es> wrote:
>     > style.
>
>
>     > You CANNOT push a changeset without its ancestors. It's impossible
>     > no matter which extension you are using. A commit's ID depends on
>     > the ID(s) of its parent(s) so any parent(s) must be included when
>     > you push. You have a few options:
>
>     > 1. Don't merge at all. You made a mistake by using a named branch
>     > instead of a bookmark, to use this option. Normally (especially
>     > when working with git repos) you'd just create a new head, or at
>     > most create a new bookmark, instead of a using a named branch for
>     > small changes like this. Named branches are *permanent*, and git
>     > doesn't have a similar concept unless it was recently introduced.
>
> Well I like named branches because it makes the graph easy to
> understand, and I can close and reopen a named branch if I wish. But of
> course you are right, for git this is toxic stuff, at least at the
> moment, or in any forseeable future the  hg-git plugin would translate a
> named branch into a bookmark (if memory saves me right this is possible
> for mercurial repo with some extension, but I forgot the details.)
>
>     > 2. Use "graft" instead of a merge (if you want to keep your branch
>     > locally for some reason).
>
> Yes I do.

I'm not clear on some of the details of what you are doing.  The original  
question was how to push a merge without one of its ancestor branches.   
That implies you effectively want to fold up the changes on your feature  
branch and rebase them onto default as one change.  But here you mention  
grafting, and below you mention exporting, which sounds like you want the  
_individual_ commits to be copied to the default branch.  So, are you  
looking to get one commit, individual commits, or it depends on the  
situation?

>     > 3. Use "rebase".
>
> But wouldn't rebase --keep do the same as graft for that purpose?
> Although I presume graft and rebase have different functionality.

The implementation is different, but the result is effectively the same  
IIRC.  I don't see why you couldn't add --collapse to `rebase --keep`, so  
that you keep the originals while you flatten them on default.

>     > As a last resort you can use mq, but really "rebase" is all you  
> need in
>     > your scenario and mq is overkill.
>
> Ok, thanks. I have used rebase in the past and did not like it too much,

Do you remember what your concern was?

> So finally I think, I will stick to my idea of two repos, one for my
> stuff: repo-hg and repo-bridge from which I would push. So I would
> export the changeset I want from repo-hg to repo-bridge. That is a bit
> cumbersome but maybe the best solutions given my preferences.
> Thanks

Here's an alternative, if you are OK with the single changeset that you  
would have ended up with when you were trying to push only the merge  
commit:

1) create your feature branch, and hack as needed, as you've been doing
2) merge default into your feature branch as needed (you were merging the  
other way)
3) when you want something to push upstream, merge default into  
feature_branch one more time, and commit
4) hg update default
5) hg revert --all -r feature_branch
6) hg commit -m "collapsed patch for submission"
7) hg push -r .

This will effectively recreate your changes as one commit, on top of the  
latest upstream.  The key here is that you never do `hg merge  
feature_branch` while on default.  It's clunky, but it's got to be easier  
than shuffling patches between two repos.

> _______________________________________________
> Mercurial mailing list
> Mercurial at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial