hg inc - single branch view by default

[anatoly techtonik]

On Sun, Dec 14, 2014 at 9:13 PM, Arne Babenhauserheide <arne_bab at web.de> wrote:
> 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 .

Also need to isolate changes in one branch for logging and pulling.

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

So, you don't use "hg pull" + "hg log", because log command to select
all changes from the current revision to the tip is complicated? Or is there
other reason?

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

The first one - "child of the greatest common ancestor", but spelled in
modern urban slang so that it could be used on IRC conveniently.

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

Yes, from my own point of view. I admit that Mercurial is more simple for
non-branched workflow, but once you start collaborating and need to
adjust your changes after review, it is a nightmare.

The best we can get is documented here:
http://scons.org/wiki/SconsMercurialWorkflows#TL.3BDR

And I believe the only way to strip the former changesets after rebase is
through the admin interface of Bitbucket. Can't test it right now.

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

People don't want to think and waste time on routines, and finding
balance is hard. Evolve extension has a good chance to fix that though
- preserve history without loosing flexibility.

-- 
anatoly t.