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

Sun May 7 17:06:47 UTC 2017

On Sat, 06 May 2017 12:48:28 -0400, Uwe Brauer <oub at mat.ucm.es> wrote:

>
>    > On Fri, 05 May 2017 16:26:45 -0400, Uwe Brauer <oub at mat.ucm.es>  
> wrote:
>
>    > 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?
>
> Maybe at that point of the thread my original problem is a bit lost. (I
> did not mention grafting, it was pointed out to me).
>
>     -  my preferences is: I want on a named branches, with as many
>        commits as necessary. When I am satisfied I want to merge (either
>        the feature branch into default or the other way around, see
>        below). That results in a graph I understand even months later.
>
>     -  the maintainer of the repo in question (a git repo) want no
>        clutter but single clean commits, and they don't want branches
>        neither (although I think one can delete whole branches in git,
>        but I am not sure).
>
> So I want a compromise between both positions.

OK.  I'm under the impression that this is a pull request based project.   
What happens when someone else submits a PR at the same time?  (I'd assume  
the maintainer does a merge, but that doesn't sound like the branch-free  
commits I picture when you say that.)

>    > 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.
>
>
>    > Do you remember what your concern was?
>
>
> Sure:
>
>
>     -  I found it a bit dangerous, if you select the wrong rev numbers
>        you might mess up things (that can not happen with a merge).
>
>     -  after a couple of weeks I might not be able to say what I based
>        on what, if the graph could represent a rebase that would be
>        different something like this

Rebase will store metadata in the commits that it creates, letting you  
know where it originally was.  The easiest way to see it is to use `hg log  
-r $rebased_revision --debug`, and look in the 'extras' section.

I hesitate to throw even more concepts at you, but have you tried the  
evolve extension?  It keeps the original commits in the tree (but hidden,  
so you may not like that).  If you mess up, you can recover the originals  
(though you should be able to do that without evolve, unless you  
explicitly said --no-backup).

MQ was mentioned, and feel free to try it.  But my impression of the  
workflow you describe is that you want all of the original commits to stay  
in the tree forever.  MQ is more for rewriting one or more commits, and  
applying them to a new upstream location (which removes them from the  
previous location).

> For example a merge is represented as
> @    changeset:   6941:8fee77df90d7
> |\   bookmark:    master
> | |  tag:         tip
> | |  parent:      6938:0d01b9868000
> | |  parent:      6940:e6d514f7926a
> | |  user:        Uwe Brauer <oub at mat.ucm.es>
> | |  date:        Sat May 06 10:48:53 2017 +0000
> | |  summary:     Merged
> | |
> | o  changeset:   6940:e6d514f7926a
>
> Why not represent a rebase like
>
> @    changeset:   6941:8fee77df90d7
> |*   bookmark:    master
> | *  tag:         tip
> | |  parent:      6938:0d01b9868000
> | |  parent:      6940:e6d514f7926a
> | |  user:        Uwe Brauer <oub at mat.ucm.es>
> | |  date:        Sat May 06 10:48:53 2017 +0000
> | |  summary:     Merged
> | |
> | o  changeset:   6940:e6d514f7926a
>
> Or something like this. But this is a different topic and I have the
> feeling there are not may people who would like it.
>

Well, rebase without --keep will remove the source from the tree.  As  
mentioned, evolve keeps the source, but hides it by default.  I don't  
think the ASCII graph shows the src/dest relationship like that, but other  
apps can (like TortoiseHg).

>
>
>
>    > 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:
>
> That sounds very interesting, let me comment on it and then provide a
> series of commandos in order to see whether I understood you correctly.
>
>    > 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)
>
> Oh well, yes and no. If there was changes upstream and I pulled, then
> you are right. But if not, then not because I would obtain when trying
> to merge
> abort: merging with a working directory ancestor has no effect
> so what I am supposed to do in scenario if nothing happened in upstream
> and the is nothing to pull???

The point of this step is to apply the latest and greatest upstream to  
your feature branch.  If you already merged the latest default into  
feature (which is what this message is telling you), then you can skip  
this step.  But you want to be sure that you have the latest upstream in  
feature before proceeding.  Otherwise, the revert command will undo the  
upstream changes that you don't have.

> Here is what I did and it seems to have worked out nicely my only doubt
> is the merge process: to merge default into feature if nothing happened
> in upstream??
>
> Thanks
>
> Uwe
>
> hg init repo-server
> cd repo-server
> echo master1 > test.txt
> hg add test.txt
> hg commit   -m "master1"
> echo master2 >> test.txt
> hg commit   -m "master2"
>
>
> cd ..
>
> hg clone repo-server repo-local
> cd repo-local
>
> hg branch feature
> echo feature-one > feature.txt
> hg add feature.txt
> hg commit -m "feature1"
> echo feature-two >> feature.txt
> hg commit -m "Last and best commit"
> # now somthing is happending in the server
> cd ../repo-server
> hg update default
> echo default >> test.txt
> hg commit -m "back to default"

You should already be on default on the server (especially since it only  
has default), but this is OK for demo purposes.

> cd ../repo-local
> # we pull the changes from upstream but what to do if there
> # were none?
> hg pull -u

The -u here is wrong, but probably harmless.  '-u' will take you to the  
tip of the current named branch that you are on locally.  Just be careful  
not to confuse yourself if you end up in an unexpected location.

> hg up feature
> hg merge default
> hg commit -m "Merged default once into feature"
> hg update default
> hg revert --all -r feature
> hg commit -m "collapsed patch for submission"
> hg push -r .
>

Yes, this looks right.  One final step that you should now add is to merge  
default back into feature, before you do more work on the feature or pull  
again from upstream.

$ hg up feature
$ hg merge default
$ hg ci -m "merge with my changes in upstream"

A couple points about this.  1) it will never complain about merging with  
an ancestor, 2) it will never have a merge conflict.

The reason for doing it is to avoid some future merge conflicts if there  
are changes in or around what you have just submitted.  It may also help  
you visually to see where you submitted something, since the revert  
command doesn't insert any tracking metadata for its source.

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