Raymond: bzr is dying; Emacs needs to move [LWN.net]

Raymond: bzr is dying; Emacs needs to move

Posted Jan 13, 2014 15:41 UTC (Mon) by mathstuf (subscriber, #69389)
In reply to: Raymond: bzr is dying; Emacs needs to move by eliz
Parent article: Raymond: bzr is dying; Emacs needs to move

So…if you pull from someone else and check out their branch, you see their commits on the right even if they merged your branch into theirs (where they'd see your commits on the right)? I don't know if I like the drawing of the history changing depending on user.email configuration (unless I'm missing some detail here).

to post comments

Raymond: bzr is dying; Emacs needs to move

Posted Jan 14, 2014 0:26 UTC (Tue) by mchapman (subscriber, #66589) [Link] (7 responses)

> So…if you pull from someone else and check out their branch, you see their commits on the right even if they merged your branch into theirs (where they'd see your commits on the right)?

No, you wouldn't. It doesn't matter who performs a merge: if B is merged into A, then A will be the left-most parent of the merge commit. The problem here is in calling the branches "theirs" or "ours". That may fit in with the way people think about the merge, but it's almost meaningless as far as Git is concerned. The merge behaves identically no matter who does it, no matter who created the branches, and no matter where the branches came from. With most merge strategies, it doesn't matter which branch is "theirs" or "ours"; the result of the merge will be identical.

(Why "almost meaningless"? There are a couple of merge strategies that differentiate between an "our" branch and "theirs" branch. But this is just an arbitrary naming: the branch-to-be-merged is always called the "theirs" branch. It has nothing to do with where the branches came from.)

Raymond: bzr is dying; Emacs needs to move

Posted Jan 14, 2014 0:52 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (6 responses)

I know git's behavior; I was wondering if my bzr understanding was correct :) . I don't think what I stated is correct (due to "pull" being used); if you *merge* from someone else, the history may be rewritten to keep your contributions on the left-parent (I think).

Raymond: bzr is dying; Emacs needs to move

Posted Jan 14, 2014 12:04 UTC (Tue) by eliz (guest, #94829) [Link] (5 responses)

> if you *merge* from someone else, the history may be rewritten to keep your contributions on the left-parent

It depends on what you mean by "history may be rewritten". Specifically, what do you mean by "history" that might be rewritten?

If you mean the history DAG, then it will NOT be rewritten, assuming you take bzr's POV, which is that there's no common history DAG. There's my DAG, and there's your DAG. They are made of the same commits (excluding the merge commits, which are somewhat different), but their topology is different. So when I merge from you, "my DAG" is never rewritten, it is just extended by adding your commits that I didn't have.

Also, the additions to "my DAG" made by a merge are always off my "mainline", which is a linear sequence of my commits in this branch. ("In this branch" because the branch from which I merged might also be mine.) The only commit made by a merge that _is_ on my mainline in the branch to which I merge is the merge commit, which adds one more revision to the mainline of that branch.

P.S. And yes, in bzr, "pull" is different from "git pull": it completely overwrites "my DAG" with the DAG of the branch from which I pull, thus making "my DAG" identical to "yours". This is of course possible only if the destination branch is a subset of the source branch (but I can "bzr pull --overwrite" to do that even if the destination branch diverged from the source). IOW, "bzr pull" will never merge, and is the same as "git pull --ff-only".

Raymond: bzr is dying; Emacs needs to move

Posted Jan 14, 2014 18:42 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (4 responses)

> Specifically, what do you mean by "history" that might be rewritten?

Hmm…if I merge remote/mainline into local/mainline, if I look at remote/mainline's commit in my DAG (second parent of local/mainline), does it look the same as if I were to look at the DAG of remote/mainline directly?

I think I'm getting confused where you say the "topology is rewritten" which makes me think that you're relabeling left-parent ancestry when merging or depending on which repository you're in when you query the history. I don't really see how it can be completely rewritten; maybe parents get reordered, but that's about it AFAICS (I can't say the newest commit is an ancestor of the second commit ever made I assume). I guess what I'm looking for are the transformation rules which bzr applies to history when "history is rewritten" (and the situations in which bzr will do so).

When folks blame/criticize/laud git for making it easy to "rewrite history", they're usually just referring to moving from a log of changes in the temporal domain into a log of changes which are incremental, logical, and easier to bisect[1] and review. What I'm hearing from bzr is that it rewrites the arrows between locations in history according to…some rules which (from my reading) tend to depend on which repository/branch I'm working in. Which sounds much weirder and I'm lacking a rationale/use case to adequately justify such behavior.

[1]I guess other tools missing bisect is a reason they're usually so touchy about not squashing typo fixes and such into the commit which introduced them (if they're on the same branch) since they don't have to worry about arbitrary commits being viable. Personally, I'll take bisect any day of the week.

Raymond: bzr is dying; Emacs needs to move

Posted Jan 14, 2014 19:13 UTC (Tue) by eliz (guest, #94829) [Link] (3 responses)

> if I merge remote/mainline into local/mainline, if I look at remote/mainline's commit in my DAG (second parent of local/mainline), does it look the same as if I were to look at the DAG of remote/mainline directly?

No, it doesn't look the same. It looks "rotated", such that the commits done locally in local/mainline are always on the left and arranged linearly, while commits from remote/mainline look like a branch that forked from local mainline and then converged with it. Of course, ancestry of each commit is not changed in any way, but the order of the parents does change.

(The above is, of course, assuming that when you merge, these two branches were divergent. Otherwise, bzr will simply do the equivalent of pull and fast-forward, and the resulting DAG will be identical to that on remote.)

There are examples of how the two DAGs will look like in the discussion from 7 years ago whose links I posted earlier, or maybe in some of their followups. If you cannot find an example, I could try digging one out.

Raymond: bzr is dying; Emacs needs to move

Posted Jan 14, 2014 19:27 UTC (Tue) by eliz (guest, #94829) [Link] (2 responses)

Here the example starts:

https://lists.ubuntu.com/archives/bazaar/2006q4/018270.html

And here it is continued to show what happens after a merge in both branches:

https://lists.ubuntu.com/archives/bazaar/2006q4/018307.html

I hope this explains what I meant by "different" and "rotated" DAGs.

Raymond: bzr is dying; Emacs needs to move

Posted Jan 14, 2014 22:35 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

OK, now I understand *what* is happening. Still don't understand the reasoning. I could see some of the reasoning being to keep old numerical IDs the same, but that sounds like the tail wagging the dog to me (numerical IDs don't sound like a good enough upside to have to pay the cost of this history mismatch).

So if A *merges* 'g' back, bzr would see 'e' and 'f' as its parents (and already in the history of the current commit), see that 'f' is on the mainline, rewrite 'g's parent ordering to make 'f' the first parent, then make 'h' as part of A's mainline (with 'g' as a second parent). At least now I see why bzr doesn't do octopus merging (What if 'g' had 'c' and 'f' as parents? Which gets to be "first parent" then?).

As a git user, this is unexpected since now "first parent of e" and "first parent of f" are different based on who you ask.

In any case, we are quite a bit into the weeds for the topic at hand. I do know that if I have to deal with bzr in the future, there will be fewer "WTF‽" moments :) .

Raymond: bzr is dying; Emacs needs to move

Posted Jan 15, 2014 5:43 UTC (Wed) by eliz (guest, #94829) [Link]

> OK, now I understand *what* is happening. Still don't understand the reasoning.

Well, I didn't design that stuff, so I can only try to guess the reasons. If you want the definitive answer, I suggest to ask on the Bazaar mailing list, where bzr's designers still lurk.

My take on the reasoning is that bzr really _wants_ to distinguish between "my" history and "yours", i.e. it wants the history in each branch to reflect the sequence of operations in that branch. Therefore, commits made in the branch and commits merged from another branch are treated differently, and shown as such in the DAG.

IOW, the interpretations of "history" in bzr and in git are subtly, but fundamentally different. For bzr, it is the actual sequence of events that added revisions to the branch, in addition to the ancestry information. For git (IIUC), it is _solely_ the ancestry, i.e. the parent-child relationships between the commits, and the "historic" aspect shows only in the direction of the DAG edges.

> I could see some of the reasoning being to keep old numerical IDs the same, but that sounds like the tail wagging the dog to me

Same here: I think the numerical revnos are the (logical) consequence, not the root cause. But again, this is just my take.

> So if A *merges* 'g' back, bzr would see 'e' and 'f' as its parents (and already in the history of the current commit), see that 'f' is on the mainline, rewrite 'g's parent ordering to make 'f' the first parent, then make 'h' as part of A's mainline

No, I think bzr will just say "nothing to merge" and refuse to merge, because A already has all the commits that are in B. (Merge commits don't count for that purpose.)

> this is unexpected since now "first parent of e" and "first parent of f" are different based on who you ask

Right, and this is very fundamental to how bzr works: the order of parents depends on the branch where you look at a merge commit. This is bzr's branch-centric nature clearly showing.