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

[Matt Harbison]

On Thu, 11 May 2017 16:34:18 -0400, Uwe Brauer <oub at mat.ucm.es> wrote:

>
> [Snip]...
>
>     > Latest upstream pulled and updated.  Ready to finalize patch for  
> submission.
>     >   $ hg rebase -d . -b feature --collapse
>     >   rebasing 1:8b6e6e26b73c "Feature1"
>     >   rebasing 2:36c3fdd7241e "Feature2"
>     >   merging feature.txt
>     >   $ hg log -G -Tcompact --hidden
>     >   o  4[tip]   71db6f73e391   1970-01-01 00:00 +0000   test
>     >   |    Collapsed revision
>     >   |
>     >   @  3:0   6f6112e52af3   1970-01-01 00:00 +0000   test
>     >   |    Master2
>     >   |
>     >   | x  2   36c3fdd7241e   1970-01-01 00:00 +0000   test
>     >   | |    Feature2
>     >   | |
>     >   | x  1   8b6e6e26b73c   1970-01-01 00:00 +0000   test
>     >   |/     Feature1
>     >   |
>     >   o  0   fe1cc974d811   1970-01-01 00:00 +0000   test
>     >        Master1
>
> This is really *great*.
>
> With the evolve extension rebase is much more intuitive and convenient, I
> would even say usable :-D
>
>     > The feature branch isn't contiguous, but so what?
>     >   $ hg log -G -b feature --hidden
>     >   @  changeset:   5:dde9d9d6ae41
>     >   |  branch:      feature
>     >   ~  tag:         tip
>     >      user:        test
>     >      date:        Thu Jan 01 00:00:00 1970 +0000
>     >      summary:     feature3
>
>     >   x  changeset:   2:36c3fdd7241e
>     >   |  branch:      feature
>     >   |  user:        test
>     >   |  date:        Thu Jan 01 00:00:00 1970 +0000
>     >   |  summary:     Feature2
>     >   |
>     >   x  changeset:   1:8b6e6e26b73c
>     >   |  branch:      feature
>     >   ~  user:        test
>     >      date:        Thu Jan 01 00:00:00 1970 +0000
>     >      summary:     Feature1
>
> Just one thing: suppose I found out that the really correct rev was
>
> 2:36c3fdd7241e
>
> I would update to this rev by
>
>  hg --hidden touch 2
>
> (And use the (d)uplicate the changeset option)
>
> Yes?

I'm not sure what you mean by "correct" in this case, since you've rebased  
1+2 to make 4.  2 can't be correct by itself.  You *could* touch 2 like  
that, but it will create a commit that is marked "unstable" (because the  
parent of 2 is obsolete/hidden).  I'm not sure what the point would be.

If you are just trying to continue the feature branch (unbroken) after you  
have rebased and pushed, you *could* just `hg update --hidden 2` and start  
committing again.  That too would create an unstable commit though.   
(There's nothing scary about unstable commits.  It just means if you `hg  
evolve`, it will automatically rebase the unstable commit.  In this case,  
if you committed to top of 2, `hg evolve` would rebase it onto 4 (since 2  
was succeeded by 4 in the original rebase).  That may sound like exactly  
what you want.  But it's not because if you pulled stuff from upstream,  
it's not rebased onto that upstream stuff.)

> Thanks again I will use your proposal from now on, at least for the
> repos I push to (not so sure about my private ones).
>
> Uwe
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial