Given changesets A & B, is there a command to tell if B is a descendant of A?
Assume that B is a descendant of A, but there are many changesets in between. I'm just trying to get a yes/no answer about this relationship.
I believe the answer should be:
hg log -r "A:: and B"
Or in TortoiseHg (using version 2.8, the parentheses don't seem to be mandatory):
(A:: and B)
To interpret the result, you should get the log for B if it is indeed a descendant, and nothing (no match) if it is not.
Sorry, but I could not simply comment on the original answer - lack of reputation.
Answer: Use a revset
hg log -r "A and B::"
if you use tortosehg, then use the following in the search window. The parens are key
(A and B::)
Related
I'm looking for a way to make Mercurial output a table like this:
File Most recent revision changing the file Date of that revision
==== ====================================== =====================
foo.py 44159adb0312 2018-09-16 12:24
... ... ...
This is just like github does it on the "Code" overview page. (screenshot from torvalds/linux):
"Most recent" could refer the date or to the DAG hierarchy relative to the current changeset, or maybe to the current branch. Perhaps the latter is more useful, but in my particular use case, it doesn't make a difference.
I'd also like to be able to provide a list of files or a subdirectory for which I want the table. (I don't necessarily want it for everything)
I am aware that I could do it using a small script, looping over hg log -l 1 <file>, but I was wondering if there is a more efficient / more natural solution.
You won't get around looping over all files. Yet with hg manifest you get that list of files. Then template the output as needed:
for f in $(hg ma); do hg log -l1 $f -T"$f\t\t{rev}:{node|short}\t\t{date|isodate}"; done
This gives output like
.hgignore 38289:f9c426385853 2018-06-09 13:34 +0900
.hgsigs 38289:f9c426385853 2018-06-09 13:34 +0900
.hgtags 38289:f9c426385853 2018-06-09 13:34 +0900
You might want to twiddle more with the output formatting. See the mercurial wiki for a complete overview of output templating.
Git will follow the commit DAG, because that's all it has. In Mercurial, you have (many) more options because you have more data.
Probably the ideal option here is follow(file, .) (combined with first or last as appropriate). But as hg help revset will tell you, you have the following options (I've shrunk the list to the obvious applicable ones):
ancestors(set[, depth])
Use this with the set being . to get ancestors of the current commit, for instance, if you want to do DAG-following a la Git. Or, use ::., which is basically the same.
branch(string or set)
Use this with . to get all commits in the current branch. Combine with other restrictors (e.g., parents) to avoid looking at later commits in the current branch if you're not at the tip of the current branch.
file(pattern)
Use this with a glob pattern to find changesets that affect a given file.
filelog(pattern)
Like file but faster, trading off some accuracy for speed (see documentation for further details).
follow([file[, startrev]])
To quote the documentation:
An alias for "::." (ancestors of the working directory's first parent).
If file pattern is specified, the histories of files matching given
pattern in the revision given by startrev are followed, including
copies.
modifies(pattern)
Use this (with any pattern, not just glob) to find changesets that modify some file or directory. I think this is limited to M type modifications, not addition or removal of files, as there is also adds(pattern) and removes(pattern). Use all three, or-ed together, to find any add/modify/remove operations.
first(set, [n])
last(set, [n])
limit(set[, n[, offset]])
Use this to extract a particular entry out of the revset.
When searching forwards (the default), last(follow(file, .)) seems to work nicely to locate the correct revision. As you noted, you have to do this once per file—it will definitely go faster if you write your own Mercurial plug-in to do this without reloading the rest of the system all the time.
Somehow more efficient / more natural solution can be:
create template|style for desired log output (I can't predict, which way will be better for you)
create alias for hg log -l 1 --template ... or hg log -l 1 --style ...
EDIT
A lot later, more correct solution (from recent discoveries) with hg grep
hg grep "." "set:**.py" --files-with-matches -d -q -T"{files % '{file} {date|age}\n'}"
Part of output in test-repo
hggit/__init__.py 7 weeks ago
hggit/git_handler.py 7 weeks ago
hggit/gitdirstate.py 7 weeks ago
…
You have to modify fileset in order to get results only for part of your tree (for all branches) and, maybe, template in order to fulfill your needs.
I didn't have fileset for selecting "files in branch X" just now, I think, it will be something using revs() predicate
"revs(revs, pattern)"
Evaluate set in the specified revisions. If the
revset match multiple revs, this will return file matching pattern in
any of the revision.
because some not published predicates (according to examples, see # "set:revs('wdir()'..." for referencing working directory) can be used for defining revset and I can't discover/predict the correct form for branch predicate
As hg help grep says:
By default, grep prints the most recent revision number for each file in
which it finds a match. To get it to print every revision that contains a
change in match status ("-" for a match that becomes a non-match, or "+"
for a non-match that becomes a match), use the --all flag.
This works as advertised: When I run hg grep --all pattern, I get a list of hits marked with :+: or :-::
plaintext.py:8055:+: ...
plaintext.py:4690:-: ...
otherfile.py:4690:-: ...
plaintext.py:4630:+: ...
plaintext.py:4630:+: ...
The problem is when I try to restrict the search to a branch or revset:
hg grep --all -r 'branch(default)' pattern
The above will no longer print the revisions in which there is a change of status. Lots of revisions that match are printed (not just the most recent or most ancient one), and many revisions that removed a match (marked with :-:) are no longer printed. (Some :-:-revisions are still printed; I don't understand when this happens.)
This seems like it could be a bug, but what do I know. I'm using mercurial 4.2 (on OS X).
I could live with filtering the output of unrestricted hg grep --all; but the default format does not include the branch (and I do know know enough to write a template that includes all the current information plus the branch).
I think you're running into this bug:
https://bz.mercurial-scm.org/show_bug.cgi?id=3885
Unfortunately "hg grep" is notoriously buggy and likely needs lots of work to get into a place where it's more usable.
I have a few odd issues with a svn repository I'm trying to convert to hg. Our repository looks more or less like this.
proj_root ___ trunk
\ \___ tags
\_____ branches __A
\ \__B
\_____Q __ C
\___ D
Ideally I could specify --config convert.svn.branches=branches;branches/Q or somesuch nonesense. (Q does not contain a branch in itself, just the two "sub branches".
I just finished converting a repository in which Q only had one subdirectory, and the solution there was easy. rename C/ . in a --filemap option, but that fails rather dramatically for this case (the Q branch interleaves C and D).
Ideally, I could simply ignore Q entirely in one pass, and then do a second conversion with the convert.svn.branches option set to branches/Q, but I cannot get the following syntax in the filemap to work:
exclude "Q C D"
nor
exclude "C D"
My hope was that excluding C and D would prevent any files from being imported on that branch, and since I have a specified filemap, the resulting empty commits would be removed. I can't get the exclude directive to exclude any directories, no matter the various syntax options I've tried.
Edit: The end result I'd like to have is a mercurial repo with trunk as the normal tip, and named branches A, B, C and D... that silly Q thing can just go away during the conversion, if I can figure out how.
For some reason when I tried this yesterday, it wasn't working, but today it works...
a filemap of
exclude "C"
exclude "D"
seems to be working properly now... I'm having an odd issue with the first conversion I'm doing crashing, but that's an issue to take up with the devs (unrelated)
In git, you can do refer to revisions by something like master^^, meaning two revisions before master. Can you do the same in Mercurial in some way (or with some extension)? For example, if I want to do "the revision before tip", something like tip^.
edit: Rafa mentions hg parents which works for 1 level deep. How do I do it for arbitrary levels deep.
For commands that have options to specify a revision, use -r -2 for the revision prior to the tip, -r -3 for the revision before that, etc.
From hg help revs:
A plain integer is treated as a revision number. Negative integers are treated as sequential offsets from the tip, with -1 denoting the tip, -2 denoting the revision prior to the tip, and so forth.
There is also the ParentrevspecExtension that allows you use syntax like: tip^ for the parent of tip, tip^^ for its parent, etc.
As mentionned by Niall C., when the revisions are linear, it is possible to use the negative specification to go back starting at tip (only works with linear history, obviously).
Starting with Mercurial 1.6, there is something similar to Parentrevspec, but in core to designate complex revision specification: revsets.
For example, "p1(tip)" is the first parent of "tip", etc.
You can do "hg parents -r revision"
I wonder whether there is a mercurial command/extension that just tests whether a given changeset is in a branch. The command would be something like:
hg contains [-r branch] changeset_id
and should check whether the given changeset is in the current/given branch, returning just "Yes" or "No".
I know about the "debugancestor" command, but a "Yes/No" answer is way easier to read.
And if there is, is it possible to check for transplanted changesets as well?
EDIT: The scenario is located in a repo where named branches have multiple heads. Lets say a branch is named "dev-X", having more than 1 head and a longer history, too long at least to track it with various graph visualizations.
I want to figure out whether a changeset X in branch "dev-X" was merged into another head of "dev-X". Therefore I cannot use branch names but only changeset numbers/hashes to specify a branch.
And to top it all, I'm trying to find out whether changeset X was transplanted there, possibly taking more than 1 transplantation step. I know that the necessary info is stored in mercurial (I've seen it when tampering with the mercurial internals), it's just not accessible via the command line interface.
How about this:
hg log -r changeset_id -b branchname
That will give some output if changeid_id includes changes on branch branchname, otherwise no output is returned.
You could wrap it in a bash function if you want:
function contains() {
if [ "$(hg log -r $1 -b $2)" == "" ]
then
echo no
else
echo yes
fi
}
which does this:
$ contains 0 default
yes
$ contains 0 other
no
using 1.6 and later with the power of revision sets all you need is
hg log --rev "ancestors(.) and <revNum>"
eg
hg log --rev "ancestors(.) and 1234"
blank means no, output means yes, its in your history. Some of the other solutions posted here wont work if the changeset was created in a named branch, even if it was merged at some point later.
As mentioned in the comment above I gave it a shot, this is what came out:
http://bitbucket.org/resi/hg-contains/
It should be pretty easy to transform the results from debugancestor into a yes or a no (but there's definitely no built-in way to do that; write a script already!). Be aware that the answer might be wrong if the branch has more than one branch head, though.
(Writing an extension to add a command to do this should also be nigh-trivial, BTW.)
You could always just print out the name of the branch for that revision (it'll be empty if it's default) and then test that against whatever you want (in bash or in a scripting language of some sort):
hg log --template '{branches}' -r <revision name/number>
I've tested most of approaches above, did not work. The extension 'contains' somehow takes wrong revision (I think its a bug), the hg log --rev "ancestors(.) and 1234" work, but I found even more simple approach to do this:
hg merge -P <changeset>
Will show you if anything unmerged remains (it will also include changesets which are not merged parents of the changeset in question)