hg inc - single branch view by default

anatoly techtonik techtonik at gmail.com
Sun Dec 14 14:24:05 UTC 2014


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.

> 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.

> 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. 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).

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

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.

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.

-- 
anatoly t.



More information about the Mercurial mailing list