I know how to use hg blame to find what exact commit changed a line in a file, but I can't find a similar way to find when the executable bit on a file was changed.
First note that as changes in the exec bit don't affect the file contents, like deletions, they will not necessarily be shown by 'hg log filename'. (Unix nerds can compare the ctime/mtime rules for files and directories with respect to rm/chmod to understand this distinction.) So you will need to use something like:
$ hg log --deleted file
to show all changesets that touch a file, include exec changes, deletions, and duplicates. This is not enabled by default for various reasons including that it can be an order of magnitude slower.
Finding exec bits while perusing the log will also mean looking at git-style patches as standard patch(1)-compatible patches don't know about exec bits. So the total command might look something like:
$ hg log --removed -pg contrib/simplemerge | grep "^new mode" -B 10
+ import os
sys.exit(main(sys.argv))
changeset: 4363:2e3c54fb79a3
user: Alexis S. L. Carvalho <alexis#cecm.usp.br>
date: Mon Apr 16 20:17:39 2007 -0300
summary: actually port simplemerge to hg
diff --git a/contrib/simplemerge b/contrib/simplemerge
old mode 100644
new mode 100755
That reads: "search all git patches on simplemerge for lines starting with 'new mode' and show the previous 10 lines".
Another alternative is to use bisect. This can be used for finding basically any sort of change you can test for. For instance, if you're looking for where the X bit is set:
$ hg bisect -g 1000 # some past revision without the X bit
$ hg bisect -b tip # some recent revision with the X bit
Testing changeset 8114:ad3ba2de2cba (14179 changesets remaining, ~13 tests)
993 files updated, 0 files merged, 716 files removed, 0 files unresolved
$ hg bisect -c "[ ! -x contrib/simplemerge ]" # shell expression returns 0 (good) if no x bit
Changeset 8114:ad3ba2de2cba: bad
Changeset 4566:087b3ae4f08a: bad
Changeset 2797:a3c6e7888abf: good
Changeset 3678:7e622c9a9707: good
Changeset 4121:d250076824e3: good
Changeset 4345:ec64f263e49a: good
Changeset 4454:28778dc77a4b: bad
Changeset 4403:15289406f89c: bad
Changeset 4371:d7ad1e42a368: bad
Changeset 4355:10edaed7f909: good
Changeset 4366:390d110a57b8: bad
Changeset 4363:2e3c54fb79a3: bad
Changeset 4361:99c853a1408c: good
Changeset 4362:465b9ea02868: good
The first bad revision is:
changeset: 4363:2e3c54fb79a3
user: Alexis S. L. Carvalho <alexis#cecm.usp.br>
date: Mon Apr 16 20:17:39 2007 -0300
summary: actually port simplemerge to hg
Here we've automated the test with a standard Bourne shell expression to check a file's exec bit and Mercurial then runs through checking out revisions and testing them for us.
There may not be a simple build-in method a la hg blame (or maybe there is, and I just don't know it!), but you should be able to use a brute-force approach to hunt down the changeset by looking at the diffs.
First, you need to enable git-style diffs, because hg's normal diff output does not show changes in file modes. To do this, add to your hgrc the following:
[diff]
git = True
Then, you can look at all the diffs for the file you're interested in and find the commit that changed the mode, by running:
hg log -p file_of_interest
If you're on a *nix system, it helps to pipe to less or grep to easily search through the output. The mode changes should be displayed just below the beginning of the patch line that starts with:
diff --git a/file_of_interest b/file_of_interest
old mode ....
new mode ....
So, for instance, you might be looking for a mode change from 644 (no exec) to 755 (exec bit set), in which case you'd see something like:
old mode 100644
new mode 100755
Once you find the diff you're after that contains the mode change you're after, you can search backwards to get the commit hash.
Not quite as simple as hg blame, but it should work to some degree. Hope that helps.
Related
I have two hg branches (dev and stable) that aren't merging like I'd expect.
On stable: I grafted in a one-line commit from dev.
On dev: Changed that one line that was grafted, committed change.
On stable: merged dev into stable (no conflicts).
However after this merge stable still has the grafted version of the line (step 1). Not the latest changes to that same line from dev (step 2). Why is this?
The file looks like:
This
file
to
be
merged
Changesets:
Changes "to" to "might" on dev
Grafts changeset 1 to stable
Changes "might" back to "to" on dev
Merges dev into stable. Result is "might" (not "to" like I'd expect to see from changeset 3).
Sorry about the delay here: As soon as you shrank the reproducer to the five commits, I knew what was going on, but I wanted to write my own reproducer before answering, and the priority of this dropped a lot. 😀 The script I used, mktest.hg, to create the commits, the graft, and the merge, appears at the end of this answer.
The key issue here is the way merge actually works in Mercurial. It uses the same algorithm as Git does: that is, it completely ignores any of the branch information, and completely ignores any timing information. It looks only at three specific commits, as found by examining the commit graph, as shown in your image. Here's a text variant via my own reproducer:
$ cd test-hg-graft/
$ cat file.txt
This
file
might
be
merged
$ hg lga
# 4:b027441200d2:draft stable tip Chris Torek
|\ merge dev into stable (9 minutes ago)
| |
| o 3:01c6cc386a08:draft stable Chris Torek
| | back to "to" on stable (9 minutes ago)
| |
| o 2:ad954507e465:draft stable Chris Torek
| | s/to/might/ (9 minutes ago)
| |
o | 1:f7521e4f0941:draft dev Chris Torek
|/ s/to/might/ (9 minutes ago)
|
o 0:a163d2c4874b:draft stable Chris Torek
initial (9 minutes ago)
The lga alias is one I stole borrowed copied from someone else:
lga = log -G --style ~/.hgstuff/map-cmdline.lg
where map-cmdline.lg is in the link above. It's just log -G (aka glog) with a more-compact format.
What's going on
When we run:
hg merge dev
Mercurial locates three specific commits:
The current commit on stable, -r3 in this case (the SHA ID will vary), is one of the two endpoint commits.
The target commit on dev is the result of resolving dev to a revision. We can do this ourselves with hg id -r dev for instance:
$ hg id -r dev
f7521e4f0941 (dev)
$ hg id -n -r dev
1
Note that we can do the same thing with # to identify our current revision, although hg summary spills everything out more conveniently.
Last (or in some sense first, though we need the other two to get here), Mercurial locates a merge base commit from these two commits. The merge base is the first commit in the graph that is reachable from both of the other inputs to the merge. In our particular case, that's rev zero, since we split the branches apart right after -r0.
Technically, the merge base is the output of a Lowest Common Ancestor algorithm as run on the Directed Acyclic Graph. See Wikipedia for some examples. There can be more than one LCA; Mercurial picks one at (apparent) random for this case. In our case there is only one LCA though.
Having found the merge base, Mercurial now runs the equivalent of two diff operations:
hg diff -r 0 -r 3
to see what we changed, and:
hg diff -r 0 -r 1
to see what they changed, since the merge base snapshot.1 If we do this ourselves, we see what Mercurial sees:
$ hg diff -r 0 -r 3
$ hg diff -r 0 -r 1
diff --git a/file.txt b/file.txt
--- a/file.txt
+++ b/file.txt
## -1,5 +1,5 ##
This
file
-to
+might
be
merged
(I have my hg diff configured with git = true so that I get diffs that I can feed to Git—long ago I was doing a lot of conversion work here.)
As far as Mercurial is concerned, then, we did nothing on our branch. So it combines do nothing with make this change to file.txt and comes up with this one change to file.txt. That one change is applied to the files from the merge base commit. The resulting files—well, file, singular, in this case—are the ones that are ready to go into the final merge commit, even though they're not the ones you wanted.
Because Mercurial has more information than Git—in particular, which branch something happened on—it would be possible for Mercurial to behave differently from Git here. But in fact, both do the same thing with this kind of operation. They both find a merge base snapshot, compare the snapshot to the two input commit snapshots, and apply the resulting combined changeset to the files from the merge base. Mercurial can do a better job of catching file renames (since it knows them, vs Git, which just has to guess) and could do a different job of merging here, but doesn't.
1Some might object that Mercurial stores changesets, not snapshots. This is true—or rather, sort of true: every once in a while, Mercurial stores a new copy of a file, instead of a change for it. But as long as we have all the commits needed, storing changes vs storing snapshots is pretty much irrelevant. Given two adjacent snapshots, we can find a changeset, and given one snapshot and a changeset to move forward or backward, we can compute a new snapshot. That's how we can extract a snapshot in Mercurial (which stores changesets), or show a changeset in Git (which stores snapshots).
Script: mktest.hg
#! /bin/sh
d=test-hg-graft
test "$1" = replay && rm -rf $d
if test -e $d; then
echo "fatal: $d already exists" 1>&2
exit 1
fi
set -e
mkdir $d
cd $d
hg init
hg branch stable
cat << END > file.txt
This
file
to
be
merged
END
hg add file.txt
hg commit -m initial
hg branch dev
ed file.txt << END
3s/to/might/
w
q
END
hg commit -m 's/to/might/'
hg checkout stable
hg graft -r 1 # pick up s/to/might/; graft makes its own commit
ed file.txt << END
3s/might/to/
w
q
END
hg commit -m 'back to "to" on stable'
hg merge dev
hg commit -m "merge dev into stable"
So, there is a project that I forked, and then I worked on it in my own branch, and pushed to my own fork. So let's say the last/tip of the original project was revision 5000; when I started working in my branch I made revision 5001, and now at the end, my branch tip is at revision 5050.
Now, if I use
hg export 5001:5050
... I get all the changesets in a single patch, which is however signed. This is great, but it makes reading for review difficult.
If i use:
hg diff -r 5000:5050
... or just hg diff -r 5000, I get all of the changes from all the changesets "collapsed" or "compressed" into a single changeset - this is great for reading for review, but does not include any signing, as in:
# HG changeset patch
# User username <user#e.mail>
# Date 1545633736 -3600
# Mon Dec 24 07:42:16 2018 +0100
...
... and does not include binary files, like hg export --git does.
So, is it possible to get an output like hg export --git R1+1:R2 (which includes signatures and binary files) - however, where all changes are collapsed like in hg diff -r R1:R2?
Note that I just want to generate a patch file, I do not want to mess with the history neither in my local copy of the fork, nor with the fork on the server - I mention this because I've seen With Mercurial, how can I "compress" a series of changesets into one before pushing?, and a lot of answers there talk about history rewriting and such...
EDIT: sort of got this with running these two commands in bash:
hg export | head -9 > ../mybranch.5050.patch
hg diff --git -r 5000 >> ../mybranch.5050.patch
... however, clearly the hg export header will be wrong, so I'd bet hg import will refuse it... So it would still be nice to know, if there is a way to get something like this, that hg import would accept...
I have been using the mercurial and Beyond Compare 4 tools together for about 2 weeks now and feel fairly confident in my usage, however I still seem to have a problem when comparing incoming changesets against my current local codebase. The problem is emphasized when I attempting a complicated merge.
Just to clarify, I am avoiding the use of tools such as TortoiseHg,
although I do have it installed. I am searching for feedback via cmd line operations only.
My current templated method to pull down the incoming changesets via the following ( as an [alias] )
hg in --verbose -T "\nchangeset: \t{rev}\nbranch: \t{branch}\nuser: \t\t{author}\ndate: \t\t{date(date,'%m-%d-%Y %I:%M%p')}\ndescription: \n\t{desc|fill76|tabindent}\n\n{files % ' \t{file}\n'}\n----------\n"
As an example, here is a simplified (and cleverly abstracted) block returned ::
changeset: 4685
branch: Feature-WI209825
user: Jack Handy <jhandy#anon.com>
date: 01-19-2015 10:19AM
description:
Display monkey swinging from vines while whistling dixie
Zoo/MonkeyCage/Resources/Localization.Designer.cs
Zoo/MonkeyCage/Resources/Localization.resx
Zoo/MonkeyCage/Utility/Extensions.cs
If I were to be comparing changes locally, I would simply use the following command ::
hg bcomp -r 4685 -r default <optional file name>
and then I would get an instance of Beyond Compare with a folder structure and files and I could just navigate accordingly to view the changes...however, when I attempt to do this with a changeset that has yet to be pulled into my local repository, I can't.
How do I diff incoming changesets with my local repository?
---- UPDATE --------------------------------
I pursued the idea of bundling the incoming changes and then trying to use BC4 to diff the bundle to any given branch/revision on my local repo.
hg in --bundle "C:\Sandboxes\Temp\temp.hg"
This creates a compressed file archive containing all the new changes.
Now I simply need to diff this bundle with my local, however am having difficulty optimizing this. Currently, I am using variations on the following command:
hg -R "C:\Sandboxes\Temp\temp.hg" bcomp -r default
Alas, I am still having difficulty perfecting this...any insight is appreciated.
I don't see how you can, since your local repository doesn't yet have that changeset, so mercurial can't create a local copy of the revision, as it doesn't have visibility of what the change actually is.
The -p flag to hg incoming will show you the patch for each revision, but that isn't what you want.
Why not just pull the remote changes anyway? It wont hurt unless you actually update. You can then do your diff in the normal way.
hg diff is a local operation.
But you can simply call hg incoming -p in order to obtain a diff view of what you're going to pull. See hg help incoming for more options and refinement (e.g. if you need to diff against a specific rev etc)
I've got a repository. In the middle of its life-cycle I deleted a lot of unnecessary files from it (I decided to keep them unversioned).
hg remove
hg commit
The repo grows bigger and bigger.
And I decided to get rid of old revisions the from initial one to the revision where lot of files were removed (let's name it X).
Other words I want combine these revisions (from the initial to the X) into one initial revision.
But same time to keep the history of the following revisions (X+1, etc..) as they are.
I googled for the solution, but failed.
And found nothing clever than do this:
hg init newrepo
cd oldrepo
hg archive -r X newrepo
hg export -r X+1: -o "~/patches/%R-%h.diff"
cd newrepo
hg commit -A -m 'initial release (after archiving)'
hg import ~/patches/*.diff
And damn it, after few successfully applied patches
I receive:
Hunk #1 FAILED at xxx
Hunk #2 FAILED at xxx
2 out of 2 hunks FAILED -- saving rejects to file xxx.rej
abort: patch failed to apply
What I do wrong?
I've got 1 repo without branches (to be more exact to the revision X all branches were merged).
The second solution was
* hg convert to svn
* hg convert to mercurial from revisiob X+1
Failed with python backtrace (probably it was caused by our repo has about 3K files).
To filter out files from repository, you want to use hg convert (Mercurial to Mercurial) with --filemap argument (see documentation for more details). Keep in mind the affected changeset IDs (and those of all their descendants) will change.
Take a look at the Collapse extension which seems to do what you want.
You can fold changesets with MQ, or use histedit extension
In Git the current revision hash is stored in
.git/refs/heads/master
Is there an equivalent in Mercurial that doesn't require me making a call to hg log -l1? I know I can get the current branch in .hg/branch.
This is to "display" the current hg hash on screen when browsing a web page.
$ hg parents --template="{node}\n"
52b8cee1e59c91b9147635b7f44a3a8896ee0b00
$ hexdump -n 20 -e '1/1 "%02x"' .hg/dirstate
52b8cee1e59c91b9147635b7f44a3a8896ee0b00
But why can't you just call hg parents --template="{node}\n"?
hg id --debug -i -r .
I'm not a mercurial expert, but taking the sledgehammer approach and doing a grep for the current revision hash in .hg yields only one possible, and that is .hg/branchheads.cache.
I believe this caches all the heads of the repository, so it may have multiple entries. By default, I think it will always have two entries, one for the default branch and one for the tip revision number.
I think that branchheads.cache is rebuilt whenever new changesets arrive, so it should always have the correct current revision hash in it.