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

[Matt Harbison]

On Tue, 09 May 2017 16:26:13 -0400, Uwe Brauer <oub at mat.ucm.es> wrote:

>
>    > On Mon, 08 May 2017 12:44:54 -0400, Uwe Brauer <oub at mat.ucm.es>  
> wrote:
>
>
>    > you too. This will find all commits created by rebase:
>
>    >   hg log -r "extra('rebase_source')"
>
>
> Works nicely!
>
>
>    > 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"
>
> That as well great, thanks a lot.
>
>
> Still I think to have something in the ASCII graph would be nice as
> well, but I have seen that question in a discussion. What do others
> think would such a feature be considered as useful??

There are two problems.  The first is that the original commit (typically)  
isn't still there, so there's nothing to draw a line back to.  (The hash  
you see is just a string stored on the commit you logged.)  The second is  
https://www.mercurial-scm.org/wiki/CompatibilityRules.

That said, if you like having the rebase source printed out by default,  
you can make your own style file.  See `hg help config.ui.style`, and the  
default file to get ideas [1].  You can %include this default file, and  
then redefine 'changeset' for example.  We did that at work, because the  
files are annoyingly space delimited, and it's easier to read one per line.


[1]  
https://www.mercurial-scm.org/repo/hg/file/247bb7a2c492/mercurial/templates/map-cmdline.default

>
>    > 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.
>
> Ok but now I am getting curious, how would you use evolve instead
> of
>
>  hg revert --all -r feature
>
> But I don't want to abuse you generosity in asking my basic questions.

This extends your example, using the Mercurial test format so that you can  
see the output.  It eliminates the need for both of the merges and the  
revert (the rebase takes the place of one merge), so it's easier to manage.

My general philosophy is that I don't care about the parts that made up a  
commit that I landed upstream.  They are typically only adding debug,  
going down dead-end paths, etc.  Lessons learned go into the commit  
message of the final patch.  There are 3300 hidden commits in my current  
repo, and I've only gone back to look at something a handful of times.

   $ hg init
   $ echo Upstream1 > main.txt
   $ hg add main.txt
   $ hg commit -m "Master1"
   $ hg branch -q feature
   $ echo feature1 > feature.txt
   $ hg add feature.txt
   $ hg commit -m "Feature1"
   $ echo feature2 >> feature.txt
   $ hg commit -m "Feature2"
   $ hg update -q default
   $ echo uwe-three >> main.txt
   $ hg commit -m "Master2"

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

Hacking commits are hidden by default to reduce clutter...
   $ hg log -G -Tcompact
   o  4[tip]   71db6f73e391   1970-01-01 00:00 +0000   test
   |    Collapsed revision
   |
   @  3:0   6f6112e52af3   1970-01-01 00:00 +0000   test
   |    Master2
   |
   o  0   fe1cc974d811   1970-01-01 00:00 +0000   test
        Master1

... but can still be seen if needed.  They are never pulled or cloned once  
they
are hidden by `rebase`.
   $ 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

Update to submitted patch
   $ hg update -q

If you want to see what hacking commits were used to create this commit...
(Don't forget the --hidden)
   $ hg log -G -r 'precursors(tip)' --hidden
   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

Ready to do more hacking.  Just create a new feature branch, with the same  
name
if you want.
   $ hg branch -q feature
   $ echo feature3 > feature.txt
   $ hg ci -m feature3
   $ hg log -G -Tcompact
   @  5[tip]   dde9d9d6ae41   1970-01-01 00:00 +0000   test
   |    feature3
   |
   o  4   71db6f73e391   1970-01-01 00:00 +0000   test
   |    Collapsed revision
   |
   o  3:0   6f6112e52af3   1970-01-01 00:00 +0000   test
   |    Master2
   |
   o  0   fe1cc974d811   1970-01-01 00:00 +0000   test
        Master1

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