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

[Matt Harbison]

On Mon, 15 May 2017 14:37:53 -0400, Uwe Brauer <oub at mat.ucm.es> wrote:

>>>> "Uwe" == Uwe Brauer <oub at mat.ucm.es> writes:
>
>    >> On Fri, 12 May 2017 11:21:16 -0400, Uwe Brauer <oub at mat.ucm.es>  
> wrote:
>
>    >> What I was getting at is, while it's possible, it doesn't make  
> sense
>    >> to commit there. I can't think of any time I've ever updated to a
>    >> hidden commit. (Or other command for that matter, other than to
>    >> extdiff against a successor.)
>
>    > But what are you doing if your patch is rejected?
>
> By rejected I meant not _approved_.
>
> The maintainer is telling me «sorry but this sucks, do this and that.»
>
> Since I have rebased and pushed what shall I do? strip the last rebased
> rev?
> And then checkout the hidden branch?
>
> What do you in such a situation?

I commit right on the branch where I want the final result to be.  I'll  
commit a series of very rough changes there.  As I see that I botched  
things, checkout whatever previous commit needs fixing, make the change,  
and then evolve the rest of the series.  When new commits are available  
upstream, I'll rebase on top of it, and continue working.  I generally  
have more than one patch to submit (my impression is that you submit one  
commit at a time), so I'll actively try to fix past commits after I get  
things working.

The hidden commit graph can get *very* complicated when you do this.  You  
said you wanted an understandable branch history, so I didn't recommend  
this for you.  I do recommend that you think about why you want the  
history of your hacking for a commit.

It does seem entirely reasonable that you skip the named branches, commit  
whatever series of hacking that you need to implement the feature, fold  
that down to one commit after you get done polishing, and submit that.  If  
you need to rework, just commit another series on top of what you  
previously submitted, and fold it all when you are ready to retry.

> This issue has always been mysterious to be in the workflow with
> mercurial (or git). What is the best practice with a not approved patch.

I'm not sure it happens in push-based workflows.  Mercurial commits are  
generally submitted as patches.

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