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

Tue May 9 02:33:28 UTC 2017

On Mon, 08 May 2017 12:44:54 -0400, Uwe Brauer <oub at mat.ucm.es> wrote:

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

>
>    > 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.
>
>
> Ah that is very interesting
> this is what I did
>
> hg init
> echo Upstream1 > main.txt
> hg add main.txt
> hg commit -m "Master1"
> hg branch feature
> echo feature1 > feature.txt
> hg add feature.txt
> hg commit -m "Feature1"
> echo feature2 >> feature.txt
> hg commit -m "Feature2"
> hg update default
> echo uwe-three >> main.txt
> hg commit -m "Master2"
> hg rebase -d 3 -b 2 --keepbranches

Given your desired goal of keeping the original commits and not having  
branch names for your upstream submissions, you probably want '--keep'  
instead of '--keepbranches'.  (--keepbranches preserves the branch name,  
and strips the originals.)

> hg log -r 3 --debug
>
>
> But I see
> hg log -r 3 --debug
> all_dirs: _parse called with args ['log', '-r', '3', '--debug']
> all_dirs: _parse found another command log
> invalid branchheads cache (visible): tip differs
> changeset:   3:ec317cd8396d45adf8ddd6b05f88b0adf936b024
> phase:       draft
> parent:      0:bb057aae85867f4739cef10531ba1bdbede66591
> parent:      -1:0000000000000000000000000000000000000000
> manifest:    3:2d35da9b5b85caba1a5e103800df1c710cd6ae2f
> user:        Uwe Brauer <oub at mat.ucm.es>
> date:        Mon May 08 16:27:52 2017 +0000
> files:       main.txt
> extra:       branch=default
> description:
> Master2

I'd say either you have an older version of Mercurial and some behavior  
has since changed, or there was a misfire in there.  I got this output  
(note the 'rebase_source'):

   changeset:   3:702a148d633b851190f0e9912ea76deb1b82f567
   branch:      feature
   tag:         tip
   phase:       draft
   parent:      2:f8858ec22b0949bfda18404635bb9578b373a632
   parent:      -1:0000000000000000000000000000000000000000
   manifest:    3:09408fb9a973fd397c05f70e6f6821b7ee7e0ff0
   user:        test
   date:        Thu Jan 01 00:00:00 1970 +0000
   files:       feature.txt
   extra:       branch=feature
   extra:       rebase_source=36c3fdd7241e92fc4cf2c3a6d0a6dd2af15c2066
   description:
   Feature2

> That is not very helpful, I'd say. Moreover if I understand that
> approach correctly I have to do that for all the rev I suspect to be  
> rebased?

Depends what you want.  I didn't want to throw templates and revsets at  
you too.  This will find all commits created by rebase:

   hg log -r "extra('rebase_source')"

To find the source commit, adding a template like this:

   hg log -r "extra('rebase_source')" -T "{rev} (rebased from  
{get(extras,'rebase_source')})\n"

produces output like:

   7341 (rebased from ba7b0992a0108eba795ab5ef729c7d86f41f862a)
   7342 (rebased from 173f2b4df0d3dfb65a32a2c99d68731020c8156e)
   7343 (rebased from f158f6bcd2b28043e06f6f474f99bd45f91bce30)

>
>    > 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).
>
> Evolve I have used for renaming branches, but I thought it is only 100
> watertight for repos in draft phase not for those which are public.
> A deeper understanding of evolve for sure is on my TODO list.

It won't let you modify things that are public.  But until you push your  
feature branch somewhere (assuming that you aren't serving it), it should  
stay in draft mode.

>
> [Snip]...
>
>
>
>    > 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).
>
> I checked that, all I can see is that the rev, which has been rebased is
> shown as white ball instead of a blue one. As longer as I think about it
> as more I want some graphical indication of a rebase operation in the  
> repo.
>
>    > 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.
> ok
>
>    > 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"
>
>
> Thanks for pointing this out to me. I was wondering already. So in short
> I think your advice is very useful and helpful. Thanks
>
>
> Uwe
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial