two branches, cherrypicking when merging.

[Steve Fink]

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

> >>> "Steve" == Steve Fink <sphink at gmail.com> writes:
>
>    > I'm sure named branches are great for some people, for something.
>    > For me, I want to be able to just start changing stuff, and decide
>    > later which topological head each part of my changes belongs to.
>
> However when I analyze a graph with bookmarks and I am not on the tip it
> is difficult to know to which branch a particular part of the graph
> belongs. For named branches that task is easy.
>

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.


>
>
>    > If a nondefault named branch gets recorded when I commit something,
>    > it's just as likely as not to be a lie. So I'd rather stick to
>    > telling truths: I am modifying whatever it is that I have checked
>    > out, I'm recording independent pieces, then I'm moving them to the
>    > appropriate topological head and removing them (if necessary) from
>    > whatever I have checked out. No lies, just accurate recordings of
>    > intermediate state.
>
>
>    > Though it really isn't semantically different when using named
> branches.
>    > They just make me feel like I'm promising too much when I use them.
>
>
> That is strange: I feel the other way around. I find the use of bookmarks
> and especially the use of rebase as obscuring/lieing.
>

Really? Ok, I can agree with the bookmark part -- if I'm on a bookmark and
I make an unrelated commit, it'll advance the bookmark (and thus be a lie).
But rebase feels like an accurate reflection of my intention.

I suppose it'd be better if I could commit --noadvance when on a bookmark.
Or maybe even commit --onto a bookmark (or other base rev), though that is
a pretty funky operation. (When editing files, I am in truth working off of
my working directory's parent revision, so commit --onto would just be
another fallible rebase.)


>
> The feature I use most of rebase is the collapse option in order to
> avoid clutter (and of course ammend for commit), but that feature I have
> also in histedit, whose interface I find more user friendly. The
> «transplant» feature of rebase I consider as obscuring things. A merge
> is a merge is a merge, while rebase rewrites the histroy and lies to me.
>

But if you're cherrypicking a commit from out of one named branch and onto
another, then it's not just a merge. 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20161111/62e75089/attachment-0002.html>