[Scons-dev] Mercurial remote tracking

[anatoly techtonik]

On Mon, Feb 1, 2016 at 12:40 PM, Russel Winder <russel at winder.org.uk> wrote:
> On Sun, 2016-01-31 at 21:57 +0200, anatoly techtonik wrote:
>
> […]
>> 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.

Merge or rebase, the sum of code is the same. If there is merge conflict - it
is good for the reason that you've given the signal that the code is modified.
It is much worse when some API function was removed in some other
commit and you try to call this function. Merge won't save you from this, but
rebase will get nicer changeset which is easier to review.

Merge - more work for reviewer if there are conflicts.
Rebase - more work for submitter.

Sometimes submitters fails at rebasing. I was able to learn rebase in Git
only today while doing this for Jison (and rebased to a wring branch that
contains generated content).

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

If your repository is not the main one, nobody cares if it is published or
not and nobody fetches from it on their own - only when you send pull
and ask people to fetch and merge your branch immediately. While
you work on your changes, I wouldn't expect anybody to pull from you
and expect that these changes won't be rebased - rebase is a common
thing in Git world and uncommon in Mercurial.

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

Below.

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

This relates to the previous block. "Take" vs "create" pull requests
is the point of confusion.

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

Except that Git allows to kill remote repository history with force
command. Also, HG bookmarks make names less persistent.

>> > […]
>>
>> 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.

I don't know what is "reasonable workflow" workflow. I agree that labels
should be parallel to changesets, but they still a part of history. If you
create feature branches named after features and bugs, you don't want to
lose information about them in annotate output.

BTW, does Git preserve branch names after merge? I've heard that you
need --no-ff  to preserve history, so by default it is just a lot stream of
commits

-- 
anatoly t.