[Scons-dev] Mercurial remote tracking

[Russel Winder]

On Sun, 2016-01-31 at 21:57 +0200, anatoly techtonik wrote:
> 
[…]
> So back to your first message, Qt is not guilty in that person who
> coded the interface doesn't have a sufficient design skills and if
> he used GTK+ the interface is likely to be ugly as well.

I understand your point, but it is slightly off at a tangent from my
original complaint. HgView is a Qt application that does not understand
Gtk themes. So my theme is light on dark, where HgView some dark on
light as is disruptive because of that.

The fact that I think the HgView could be better even as a Qt
application is also true but less of an issue.

In the git world there is gitk which, being a Tk application works but
looks hideous. gitg is a Gtk variant that has much better look on
GNOME. Arguably though neither are actually good tools for working with
Git.

[…]
> Catching magical bugs from merges that join code that was too far
> away causes much more extra work than just rebasing your branch.
> What kind of extra work can be caused by rebase?

An unrebased repository should pass the tests. Doing a pull request and
merge should not cause extra problems, there should be no weird merge
issues. Rebasing can make a nicer changeset: witness the mess of my
original changes to the D tooling some while ago. The problem of rebase
is the reordering of changes that can lead to new and sometimes
spurious of ten critical new merge conflicts.

> > I think the only use
> > case for rebase (other than with the svn plugin) is to create
> > changesets for pull requests from a repository that has never been
> > published.
> 
> I don't see the connection. You send pull request from your branch,
> and this branch is not merged, not reviewed, may be dropped at all.
> In Git world people don't base his work on such branches. Not that
> much in Mercurial, so "rebases are evil" is a Mercurial way of doing
> things.

?

I do not follow the text here, sorry.

> > I tend to publish repositories and take pull requests, so
> > when creating the final pull request, to rebase would be to
> > invalidate
> > rather than simply amend, history.
> 
> There is a logical disconnection in your post. You say you take pull
> requests, but then say that rebase invalidates history only when pull
> requests are created. There are two logical outcomes:

Where is the disconnect?

> 1. You don't use rebases, because you don't create pull requests
> 2. You wound not use rebase, because it "invalidates" history

I am not sure how this relates.

> An interesting observation is that amend is not "invalidation" of
> history, so when you erase previous change and commit message
> it is not invalidation?
> 
> If you care about history, use Mercurial.

Only if you care about persistence of the names of the branches and
branch structures over all merges. This is the core Git vs. Mercurial
debate really. Everything else is secondary.

> > […]
> 
> Google doesn't know what is "transient in-repo branch". You say
> that persistent branches are a royal pain, so you prefer to dispose
> of branch (and lose history of what branch was merged, right?). If
> you don't rebasing, you need HG bookmarks. You history will be
> save and sound with them.

What it comes down to is that Mercurial preserves the names of branches
for eternity and this does not work for people used to using Git. There
is history and history. The changesets and the labels of the changesets
are two separate domain. For reasonable workflows, history preservation
of changesets is more important than history preservations of labels.


-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20160201/f024c536/attachment-0001.pgp>