two branches, cherrypicking when merging.

[Uwe Brauer]

    > On Sun, Nov 6, 2016 at 6:06 AM, Uwe Brauer <oub at mat.ucm.es> wrote:

    > That is a valid point. You could work around it with tooling (eg display
    > the bookmark names of all descendants of the changeset in question, or
    > something like hg log -r 'REV and (descendants(REV) and bookmark())'), but
    > that's a pretty unsatisfying answer. I somehow don't seem to run into that
    > problem in practice, but I'm not sure why not, and if I did I would find it
    > to be a very persuasive argument for using named branches. Hm.

That is a very interesting point. I also contribute to repositories
which run git and I use the hg-git plugin in order to communicate.
However I cannot use named branches there, only bookmarks.

So I run into the problem of not always understanding the resulting
graph on that very reason.

I tried to play around a bit with your suggestion but I am not
completely convinced.

Interestingly enough I just learned
(https://felipec.wordpress.com/2012/05/26/no-mercurial-branches-are-still-not-better-than-git-ones-response-to-jhws-more-on-mercurial-vs-git-with-graphs/)
that git has the possibility to display the graph in way that bookmarks
look as if they were named branches for mercurial.

git log --graph --decorate --pretty=short | git name-rev --stdin | more

does the trick.

I am not aware of a similar feature in mercurial. If there were, that
would be great because it would ease the use of bookmarks very much. But
then with such a feature implemented, named branches would be really
obsolete. That is why I think such a feature will not be implemented any
time soon, if at all.


    > But if you're cherrypicking a commit from out of one named branch and onto
    > another, then it's not just a merge.

You are absolutely right, point taken, I was lying to myself.


    > I guess I think of transplant as a lie with respect to how things
    > happen, but as the truth with respect to the state I want to end
    > up in. (And with evolve, the final, immutable state reflects the
    > history accurately -- I made the commit in a weird place,
    > obsoleted it, and put it somewhere else.)
    > I also use histedit for collapsing, fwiw. chistedit specifically, if we're
    > talking about friendliness of interfaces.

    > (and in response to your next message, yes sorry, I did mean commit -i not
    > record.)

    > It's a little disturbing that I can agree fully with your general way of
    > thinking about things, yet come up with different conclusions with respect
    > to the exact workflow. I think it probably means that there are two
    > different but valid semantics, and neither is perfectly matched/supported
    > by the available toolset. Hopefully the new 'topics' work will be more
    > right than any of the existing approaches?

Well that is what free software is about :-D

No seriously I think it depends very much to which sort of repo you
contribute. I think if there were many contributors and a lot of commits
one would like to minimize clutter in the history, so the fold/collapse
feature comes in handy. Moreover if you contribute to a repo but neither
have write access nor are you the maintainer, rebase makes a lot of
sense.

But if you are working with a small repo which say 3 collaborators then
folding/collapsing and rebasing would obscure things, at least for me.