1

I know that when you update to a previous revision, you create a new branch on your next commit. What happens when you clone an earlier revision? Will your next commit (or push) create a new branch?

The reason I ask is because our Tip is currently broken, so until it gets fixed, I was planning to do the following:

hg clone -r <prev_rev> <Tip>
# make changes
hg commit -m "my changes" -u me
# wait for Tip to get fixed
hg pull 
hg merge
hg push

Will this work? Or will it end up creating a new branch or a dangling head? I would like to avoid doing either of these things.

ktm5124
  • 11,861
  • 21
  • 74
  • 119
  • 2
    Mercurial branches are created by name, so if you don't say `hg branch ` and then `hg commit`, you have never created a new *branch*. However, creating a new commit that has no descendants, as this commit will do, will create a new head. You can merge the new head with the new tip-head later using the command sequence you showed, though in some situations it may be better to use `hg histedit` to edit history to put your new commit(s) atop the new, fixed tip commit instead. This is mainly a style issue, to be decided by you and your team. – torek Nov 02 '18 at 01:46
  • torek is correct. That BTW is not an uncommon thing to do. You will not have multiple heads until you pull changesets from the parent repository. You would then have a head with the pull changesets and another with your local changesets. The phase for the pulled changes will be set to public while the phase for you local changes should be set to draft or secret. Rebase can use this information to migrate your local changes above the pulled changesets (returning you to a single head). – Craig Nov 02 '18 at 18:47
  • @torek I have always understood that any head IS a branch. There is no distinction, except that some branches may have names. But the name is not a very important distinction in terms of how most HG operations actually function. – StayOnTarget Nov 06 '18 at 12:30
  • 1
    @DaveInCaz: that's true in Git, but not in Mercurial: *branch* in Mercurial is defined as a named entity containing commits, while *branch* in Git is ... poorly defined (see https://stackoverflow.com/q/25068543/1256452), but one of the meanings is "anything with a named tip" (not quite the same as a Mercurial head). – torek Nov 06 '18 at 19:39
  • @torek I don't think that is correct... I think "branch" in HG is used more loosely than that. Example: some of the documentation https://www.mercurial-scm.org/wiki/BranchingExplained uses the term "branch" for unnamed scenarios. – StayOnTarget Nov 06 '18 at 20:00
  • 1
    @DaveInCaz: That's an example of someone coming from Git, trying to use Git terms for Mercurial. Note that it's the wiki (so anyone can contribute to it). Of course if you're a descriptivist rather than a prescriptivist, you'll side with the "it means whatever people mean it to mean" group. :-) (see https://english.blogoverflow.com/2012/10/prescriptivism-and-descriptivism/) – torek Nov 06 '18 at 20:09
  • @torek yes maybe that was not the best example. Here's another: http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html (Note that I didn't mean to imply that HG and git branch concepts were the same. Just that an hg "branch" can take multiple forms. – StayOnTarget Nov 06 '18 at 21:21

1 Answers1

0

Yes, that will create a branch, at least in the sense of having a "fork" in the history of the repository.

The branch will not be assigned a new branch name, but that in itself is not usually important in terms of understanding what the history will look like in a repository.

If your original repo was:

A-B-C-D

Then you do a hg clone -r C... and a new commit, you will end up with:

A-B-C-(D)
     \
      E

Now, since you have cloned only up to C, that specific local repository may not include D yet. But when you eventually synchronize it with another that will have to be dealt with. If you PULL, then you will get D in that clone. If you try to push HG will warn you about creating a new remote head for which the usual approach is to merge.

There is nothing wrong with this approach. If you need to work around an issue in tip for the time being, this is a reasonable way to do it. But you don't really need a new clone, you could just hg update C and work from there, which might be easier.

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81