Mercurial/Git flow - When are new heads created? - mercurial

Question

We have a course where we study Mercurial. I have a question regarding Mercurial but I believe Git acts the exact same way here.
To answer this question I used the Mercurial Workbench and followed the graph after each command.
This is the question:
For the following sequence of mercurial operations, explain which line(s)
cause the number of heads to change in any of the referenced repositories (say which
repository is affected, and why). Assume the main repository initially has a single
head, with some existing data:
(I have bolded what I think are lines where new heads are headed)
/home/user> hg clone http://remoteserver/mainrepository clone1
/home/user> hg clone http://remoteserver/mainrepository clone2
/home/user> cd clone1
/home/user/clone1> hg tag initial
/home/user/clone1> echo one > a.txt # Create a new file “a.txt” containing “one”
/home/user/clone1> echo two > b.txt # Create a new file “b.txt” containing “two”
/home/user/clone1> hg add a.txt
/home/user/clone1> hg commit -m ”Added a file”
/home/user/clone1> hg tag file-one
/home/user/clone1> hg push -f ../clone2
/home/user/clone1> cd ../clone2
/home/user/clone2> echo three > c.txt # Create a new file “c.txt” containing
“three”
/home/user/clone2> hg add c.txt
/home/user/clone2> hg commit -m ”Added another file”
/home/user/clone2> hg push -f ../clone1
/home/user/clone2> cd ../clone1
/home/user/clone1> hg up initial
/home/user/clone1> hg add b.txt
/home/user/clone1> hg commit -m ”Added yet another file”
/home/user/clone1> hg up file-one
/home/user/clone1> hg push -f ../clone2
I came to this conclusion:
on row 14, a new head is created on clone2
on row 15, a new head is created on clone1
on row 19, a new head is created on clone1
on row 21, a new head is created on clone2
We end up with 3 heads in clone1 and 3 heads in clone2.
My question is:
Is this correct?
Can you explain to me what happens at each step a new row is added?
I tried to come up with my own reasons but I need an expert opinion on this.
Thank you

Answer 1

For (1): yes, that's correct. For (2), I'm not sure what you're asking ("at each step a new row is added"—what does the word row mean here?). [Edit per comments] let's look at steps 14, 15, 19, and 21 with respect to previous steps.
At step 14, you run hg commit -m "Added another file". The current commit is not an existing tip commit, because at step 12 you moved into the "clone2" directory / clone, whose current commit is unchanged from the time you made the clone (at step 2). That is, if the current commit was numeric-ID 0 and hash-ID a1234567.... at step 2, that is still the current commit, even though step 10 added more commits to that repository. (The current branch is probably default, although this is less important since both clone1 and clone2 are on the same branch and the commits added to clone1 are now present in clone2, on that same branch. The key item is that the current commit in clone2 is not the head of the current branch in clone2, thanks to the pushed-in commits.)
In a more typical situation, such as that at step 7, you'd be on a head commit (a commit with no children) when you make the new commit. Making the new commit creates that new commit with the current commit as its parent, so that the commit that was a head (had no children) is no longer a head (has a child); and the new commit itself, being new, has no children and is therefore a head. The count of heads is therefore adjusted both -1 (loss of previous head) and +1 (gain of new head via new commit).
But the new commit you make at step 14 has a not-a-head-anymore commit as its parent. Its "headness" was erased earlier by the git push at step 10, when it acquired a child commit. Now it has two children, which leaves it not-a-head; and the new child commit, being a new commit, has no children, making it a head. The head count is thus adjusted +1 with no offsetting -1.
At step 15, you run hg push -f ../clone1. This puts the new commit you just made at step 14 into clone1. Since the new commit you made is a head, clone1 gains a new head.
Step 19 is similar, but we're back in clone1 (due to step 16). The current commit is not an existing head, thanks to step 17 (hg up initial which uses the tag to find the commit to switch-to). You make a new commit, which is automatically a new head; but the commit to which you add this new commit as a new child is not itself a head, so the head count goes up one. Step 21 simply pushes this new commit into clone2: it's new to clone2, so it is a new head, but it does not transform any existing head into a non-head.
You haven't gotten here yet, but...
Note that when you use hg branch <newbranch> and then hg commit, you create a new child for whatever commit was current at the time, but that new child is in a different branch. The new commit, which becomes the current commit, is the new head of the new (now existing) branch, and the fact that it's a child of the commit that used to be current is irrelevant, since "head-ness" is determined by whether there are child commits in the same branch.
More generally (pre-edit text continues below)
... I believe Git acts the exact same way here
It does in terms of commits, but not in terms of heads.
Mercurial defines head as any commit with no outgoing arcs into (child commits in) the same branch. Mercurial's branches are very different from Git's, and Git more or less defines a head as "any commit that has a branch name pointing directly to it" (though Git calls these tip commits, and refers to the branch name itself as a "head").
Git's branches have no permanence: they exist only because the branch name itself exists, and the branch name exists only as long as you don't tell Git to delete it. As soon as you delete the name, the branch ceases to exist. The commits stick around until there are no more references to them, at which point the garbage collector (once it runs) discards them. Some references are squirreled away in reflogs and there's a separate reflog for each branch (deleted when the branch is deleted) plus one for the special name HEAD (never deleted), so even though the branch's reflog references vanish, the HEAD reflog references tend to keep deleted-branch commits alive for a while.
If those (in-Git) commits are reachable from some other branch, they continue to stick around because of that. Meanwhile, every commit in Git is, in general, reachable from N branches simultaneously (N being any nonnegative integer, and usually N ≥ 1). We say that those commits are contained within those branches. By contrast, every commit in Mercurial is on exactly one branch, with its branch having been chosen at commit-time, and it never changes.
In other words, we can say that in Mercurial, a branch's existence depends on the commits that are on the branch; but in Git, a commit's existence depends on the (branch and other) names that contain that commit. Any name will do, including tag names—Git has a bigger namespace here than Mercurial, since its tags are stored externally (which makes them unversioned, with all that this implies).
To make this work in Mercurial, "head-ness" is an automatic property of a commit, and to make this work in Git, "head-ness" (or branch-tip-ness) is managed manually instead. To make it mostly-automatic, git commit will automatically update the current branch (whose name is stored in HEAD) to point to the new commit just made.
Both VCSes add new commits the same way: they take whatever is in the proposed commit—stored in Git's index, or in Mercurial's work-state as shown by hg summary—and package that into a real commit, whose parent is the current commit. In Mercurial, having made that commit, we're done: it's automatically a head as it has no children. In Git, having made the new commit, our final task is to write the commit's ID into the current branch name, so that the branch name now points to the new tip commit.