On 22/08/19 09:41, Jörg Knobloch wrote:

I started off using bookmarks. I've since given bothering with names,
and just use anonymous branches, but I think all the rebasing (and
histedit) stuff is all still applicable - bookmarks just let you give a
human name to a rev (and the name will automatically track the tip of
that branch as you check stuff in).

I actually started writing up my anonymous-branches workflow as an extra
section for the docs... but maybe I should just expand the bookmarks
section instead.
Stuff like:

• keeping local changes up-to-date (rebasing)

  • dealing with rebase failures
  • rebasing non-landed changesets which were on top of ones which are
    now landed
  • aborting a failed rebase

• tidying up patches (histedit stuff)

  • merging multi-changeset patches into a single patch
  • reordering changesets
  • splitting up changesets (moving hunks between changesets)

• rolling back a histedit/rebase gone wrong (backup bundles)

What have I missed?

Rebase works the same way - the rejected bits go into '.rej' files for
manual examination.
The repo goes into a 'rebase-in-progress' state until it marked as fixed
manually (--continue) or reverted (--abort).

I just leave orphan little branches lying around. The patch appears in
the main branch and life goes on. If I have multi-part patches, I'll
snip off the non-landed part and create a new little branch (using rebase).
I think there's a way to hide changesets (that's what rebase and
histedit do I think - nothing is ever really deleted), but I've never
bothered.

I'm happy to have a go at it. It's a hard topic to write about
understandably, so I think it'll take a lot of feedback and revision to
get right.

Ben.

Hi Jörg,

On 8/21/19 5:41 PM, Jörg Knobloch wrote:

I should clarify what I said briefly in the meeting yesterday. I'm still
using the "bookmarks way" even though I've gotten out of the habit of
using the specific "bookmarks" feature.  Evolve works alongside
"bookmarks" as part of the "bookmarks way" of working.

I wrote that doc as a quick start guide with links to more in depth
docs.  I'm happy to add to it if needed.  One can always add more
documentation.

I can help people with them.

I thought we already discussed why we recommend them (at least once). 
In brief, they are what Mozilla/Firefox and what Mercurial people
recommend for new devs, and it is the way of working with Mercurial that
is closest to the git workflows that many devs know.

Yep, "hg rebase" is how I do it.  I usually just do "hg rebase -s 1111
-d 4444" and use the numbers that identify the changesets. (This is the
part where I've gotten out of using "bookmarks" in the narrow sense of
the feature.  I may be missing something about how to do this better
using bookmarks.)

Much like git, mercurial guides you through resolving the conflicts.  It
tells you which files have conflicts, you open them and resolve the
conflicts (it presents both versions of the conflicting code and you
edit it as needed to manually resolve it).  Then you mark the files as
fixed with the command it mentions and then do "hg rebase --continue"
which it also mentions.

It can seem scary at first but it's not once you do it a few times. 
Mercurial usually generates backup files when there are conflicts as an
extra precaution against losing anything.  I've never needed them.

You delete them after they've landed.  I haven't had any issues with
this.  I'd like to look more into best practices for this.

I can be the resident "bookmarks" guru and add to the docs and/or field
questions as needed.

Which bug is this?

-Paul

On 22/08/19 12:47, Paul Morris wrote:

Ahh, interesting - you do the same as me! (although for some reason I
always go for hashes rather than revision numbers - probably a git
reflex ;-)

Maybe the section should be called "rebase-based-workflow" (well,
something like that)?
And relegate coverage of bookmarks to a little subsection, saying how
they build on the workflow by letting you assign more friendly names?

Ben.

On 22-08-2019 00:41, Jörg Knobloch wrote:

I'm not sure what you're suggesting.

Yes mq is used a lot, but I think it's mostly out of old habits.
Recommending it to new people probably isn't such a great way forwards.
With good documentation of the workflow through better means, I don't
see why we'd promote mq.

 -Magnus

On 22 Aug 2019 02:47, Paul Morris wrote:

https://bugzilla.mozilla.org/show_bug.cgi?id=1547325

On 8/21/19 8:59 PM, Ben Campbell wrote:

Glad I'm not the only one!  I checked and looks like the following is
what we could do instead. It matches the behavior of git rebase.  I'll
start using bookmarks again and see how this goes.  I can then add it to
the docs.

-Paul

hg rebase -b mybookmark -d tip

-b --base REV     rebase everything from branching point of specified
                           changeset

https://stackoverflow.com/questions/30880099/rebasing-my-bookmark-on-top-of-another-bookmark-in-mercurial

Hi Jörg,

I'm glad to hear you are interested in bookmarks. Others have already
made great comments on bookmarks so I'm going to keep it brief.

On 8/21/19 11:41 PM, Jörg Knobloch wrote:

I use mq only to create empty changesets for use with try. If mach try
would work as expected I'd not need mq at all.

I use both bookmarks and evolve, these don't have to be separate. The
other thing I use extensively is the hg wip command, which is your hg
qseries command on steroids.

I'd love to hear which parts are dangerous or whats missing. Possibly we
have to link to other documentation as well, if we want to cover all the
caveats we'd be mirroring the hg docs. Version control systems can be
dangerous, but the advantage of not using mq is that in theory as long
as you've committed it, it is still there somewhere.

When I pull, I do this when I want to get my current bookmark/branch
rebased on comm:

hg pull comm
hg rebase -d comm

This will potentially move multiple bookmarks on top of to comm if they
are all on the same path. Sometimes I want to rebase the specific
changeset I am on to comm:

hg pull comm

hg rebase -s . -d comm (I think, this is from memory. I tend to get it
wrong once in a while)

If there are conflicts it will fire up your configured merge editor. You
can set that to be via command line if you like, but I think that is a
matter of personal preference.

With evolve, changesets stick around forever but get put into the
"obsolete" state. hg prune will allow you to mark changesets obsolete.
Generally though you won't have to worry  about removing them much. You
upload the patch for review, it gets pushed, and when you do hg rebase
your local patch goes away. If there are differences between what is
pushed and what you have locally, you can still use hg prune to get rid
of whats left.

For those who are using hg histedit, with changeset evolution I haven't
had may cases where I still needed to use histedit. For example, instead
of using hg histedit to make changes to an older commit, you can just hg
up -r revision, make your changes, hg amend, then hg evolve -a and you
are back to the original tip.

This doc is also good reading for evolve:
https://www.mercurial-scm.org/doc/evolution/user-guide.html . And this
one for bookmarks: https://www.mercurial-scm.org/wiki/Bookmarks . Maybe
we shouldn't be including version control info and instead linking to
other docs completely

Philipp

On 22 Aug 2019 17:02, Philipp Kewisch wrote:

Maybe I exaggerated, but I certainly got the discussion going ;-) -
Thanks for all your tips.

Missing on the page: Well, the word "rebase" doesn't appear on the page,
so that a serious omission, don't you think? Perhaps a mention of
"prune" wouldn't go astray either.

Jörg.

P.S.: I even learned something from the queues page: hg qpush --move.