problems with the hg-git plugin and bookmarks

[Kevin Bullock]

> On Sep 8, 2016, at 03:00, Uwe Brauer <oub at mat.ucm.es> wrote:
> 
>> [quoted text edited for length] The rebase is entirely optional.
>> The most basic workflow for submitting upstream changes is:
> 
>> 1. Clone upstream repo.
>> 2. Write/edit code. Commit one or more times.
> 
> But in different branch/bookmark?

Since you're not going to be pushing to the upstream repo directly, that's entirely up to you. It's not necessary.

>> 3. Send patch using `hg email` or `hg export`. Note that you can
>> e-mail or export multiple commits as easily as a single commit.
> 
> But not rebeasing or merging my changes into master/default? If the
> relevant maintainer can deal with such a solution that is fine for me. I
> thought live is easier for him/her if I send the patch with respect to
> the most recent pull.

If you need to be sure your patch applies against the current upstream, then yes, you can rebase/graft onto the latest master before sending the patch.

>> If that says "nothing to rebase", then your changes are already
>> descended from the current master. (Note that I'm only using 'master'
>> because you've said you're interacting with an upstream Git repo; in
>> Mercurial bookmark terms we spell it '@').
> 
> And if not? That is if *there is* something to rebase, then  my branch is
> linearized, no? (I don't like that outcome, I want to keep my stuff
> in my branch). 

Again, then you may want to graft instead of rebasing. At that point, you'll have multiple copies of your change locally. That's a different kind of complexity to manage (which is the latest version of my change?).

But when your patch lands upstream, you'll encounter that anyway: it will very likely be in a different place in the history graph, and even if not, it's likely to have a different changeset hash (i.e. it will be a different commit with the same code changes).

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock