0

I guess I must have misunderstood the author of this post when he said:

hg pull -r X -f repo  # ... will give me all changesets up to X

Because when I did that (in a freshly-created repository), I only got those changesets that were ancestors of the branch that revision X is on.

What I wanted was all the changesets that had been committed to the remote repo up to and including X, chronologically. In other words, in addition to the branch that X is on (and its ancestors), I also wanted all other branches (including closed branches) committed before X that hadn't been merged to X's branch.

How would I express the command to do that?

BTW, in this particular repo, there are closed branches that have names that are identical to currently open/active branches, so if the solution involves enumerating all the branch names (which would be tedious, but do-able), it would still need to get the closed occurrences of such branches as well as the open ones.

(For completeness I suppose I should also say that I ran the command from the command-line of TortoiseHG 2.7 on Windows, in case the behavior of hg pull that I've described above isn't what I should have expected.)

Community
  • 1
  • 1
Hephaestus
  • 1,982
  • 3
  • 27
  • 35

1 Answers1

2

You can't do that on pull in a single command. "Chronologically" means a lot less than you think it might. Anyone can do a commit with any timestamp they want, so the dates aren't good selectors. If you mean "with an earlier revision number" those too can change from repo to repo, so pulling all revisions with a revision number lower than N could give different results for different invocations.

If you want to try the revision-number-based version anyway, you'd probably have your best luck pulling everything to a trash repo locally and then pushing only what you want to a new local repository:

hg clone http://remotehost/path local-clone   # clones everything
hg init another-local-clone
hg push --repository local-clone --rev '0:X' another-local-clone

after that another-local-clone will have all the changesets whose revision numbers is X or lower in local-clone, which is (but isn't guaranteed to be) the same as the remote clone

If that seems awkward it's because "committed before" isn't a terribly useful concept in DVCS land -- it assumes a linearity that neither git not Mercurial consider important.

Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
  • I would like to add that even the successor of a commit can have a commit date before its parent revision. Which is not uncommon when someone reorders commits with the mq-extension. – Rudi Nov 19 '13 at 14:45
  • 1
    @Rudi precisely. ancestor/dependent are meaningful relations w/r/t changesets and "earlier" in either date or revision number is not. That's why `-r` does ancestors and date/revision number is awkward -- it's not terribly useful once you really understand what ancestry gets you. – Ry4an Brase Nov 19 '13 at 18:17
  • @Ry4an, thanks for the explanation. It makes sense, although it does call into question why `hg log` accepts a date range if dates aren't meaningful. I like your suggestion about pulling everything into a dummy repository and then pushing the desired revisions to another repository, and will probably use that if a situation like this comes up again. – Hephaestus Nov 19 '13 at 21:26
  • It's not a great answer but I'd guess log supports date ranges because they were easy to add (since it's acting on a local repository) and available in svn/cvs. Whereas adding them to `pull -r` would mean supporting them at the network protocol level -- pull does a lot of work to send only the minimum changesets necessary to fulfill a pull-request. You don't want to transfer what the user already has, so the sides have to negotiate to arrive at the right set to transfer. – Ry4an Brase Nov 20 '13 at 15:25