hg inc - single branch view by default

Sun Dec 14 18:13:27 UTC 2014

Am Sonntag, 14. Dezember 2014, 17:24:05 schrieb anatoly techtonik:
> On Sun, Dec 14, 2014 at 1:36 PM, Arne Babenhauserheide <arne_bab at web.de> wrote:
> > Am Samstag, 13. Dezember 2014, 14:42:08 schrieb anatoly techtonik:
> >> People have limited attention span. While working with multiple branch
> >> repository, would it be more efficient to concentrate on a single
> >> branch at a time and request all other branches only when it is
> >> needed?
> >>
> >> I often find myself confused when reviewing hg inc output, because I
> >> fail to spot the tag branch: in changeset header. If I knew that I am
> >> only reviewing single branch, that I can request full changes and knew
> >> what other branches were changes - that would help me a lot to get
> >> what's happening.
> >
> > Wouldn’t this be fullfilled quite well for advanced users with an option like --focus-branch?
> 
> It then should be mode, not just a single option.

Are there other commands for which you’d need that? If not, an alias
would fullfil that usecase.

[alias]
# focus incoming on the current branch
inb = incoming --focus-branch .

> > For my own use, that would complicate my work a lot, because I often
> > pull and merge other named branches, and I need to know their exact
> > changes.

> Yea, right. The same problem here. I want to pull and inspect branches
> only when I need them. I want to be aware that something goes on in
> remote repository, but not to filter details through my head.

That’s different from what I do. I always pull all changes to
synchronize, then I check the local history with graphlog.

Incoming is just the precursor for a pull in my case (as such I would
be happy to have bundling of incoming happen automatically and
transparently, so on my next pull I can simply get the changes
locally).

> > The new behaviour for bookmarked heads is already pretty
> > confusing for me (hg complains regularly that there are no other
> > bookmarked heads, because I just don’t need bookmarks all the time).
> 
> Mercurial language is insufficient for me. For example, I don't have a
> word to speak about changesets that are forked into different line on the
> same branch. 

I call them under a different head.

> You can use bookmark, but that's a different meaning with
> different mechanics. Instead of trying to imitate Git with Bookmarks, the
> better way IMO is to define a new set of concepts to play with and build
> future versions around these. Two concepts, to be exact:
> 
> - one word for linear set of changes that start after common ancestor
>   (we can't use branch, because branch is `painted tree` in Mercurial).
>   Note that the set doesn't include common ancestor (branch point).

It’s a bit more than painted tree: it’s painted tree plus UI
functionality to make it work well.

But yes, it’s hard to define a word, because having multiple heads on
a branch is a state which Mercurial tries to avoid (with all these
“creates new heads” warnings).

With bookmarks that changed, but we did not get new language for “line
of development with only one head and one root”.

> - one word for the changeset that is start of the above set

Something like the child of the greatest common ancestor?

Or do you mean the greatest common ancestor itself?

    hg log -r "ancestor(revs, ...)"

> Without such terminology I don't think anybody would be able to discuss
> the workflow they want to see. For example I'd like to have first-class
> "pull requests" with ids in Mercurial history that are freely rebased and
> anchored when merged. At this time id is set for it. In my imagination
> the history can be linear, but composed of named (colored) pull
> requests (which can be then reviewed and commented as additional
> feature).

> To me Mercurial looks like a lot like feature-creeped chemical compound
> with links too tight to fill a human friendly form. So you need to adjust it
> a little every time to squeeze into your bowl. It is like C4 - handling is
> tedious and involves a lot of wiring (merging), but operation is safe.

That does not fit my experience: Whenever I showed people how to use
Mercurial, I made two observations:

1) It did the job with little effort.

2) Per person I got less than 2 questions later on: They just kept
   using it and it worked.

But then, I showed them the very polished named branch workflow, and
most of them weren’t git-tainted before they started with hg.

I think what you’re describing is the power-user view (which turned
git into the mess it is).

> Comparing with chemical compounds, Git is like petroleum - you won't
> keep it at home, because you grandma hates the smell, but you can go
> really fast with proper GH engine and handling practice. Just be careful
> with that +remote control.

But that only goes for a limited number of usecases, though these are
the (only) ones git users expect when they try any VCS, while blowing
up your shack every once in a while (whenever you realize that it
doesn’t work exactly like you thought - or that someone else
mishandled it).

Git is actually more convenient for some parts of usecases, but I
never found a usecase where it did more good than damage. So we should
be careful whether by going down the git path we wouldn’t give up more
than we gain.

Best wishes,
Arne
--
singing a part of the history of free software: 

- http://infinite-hands.draketo.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 299 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20141214/9ead22bb/attachment.asc>