After performing a hg backout, the console outputs something like this:
changeset 3:a2b2d103c5ee backs out changeset 2:487a64ab45d0
The message suggests that backout metadata is recorded somewhere within Mercurial. Is this true? Given a revision, can I determine whether it was the result of a backout and determine which revision it backs out?
No, I don't think that's possible. The message you're seeing is only displayed when you run the command, there is no metadata recorded that will give you that information later. This is because "hg backout" is really nothing more than a shortcut for a series of individual steps, more details here: https://www.mercurial-scm.org/wiki/Backout#Inner_Workings
You could run those steps yourself and get the same result, and Mercurial would not know the difference.
Related
I was surprised when coming back to Mercurial after using Git for quite a few years when I did an hg pull -u: Mercurial fetched the new patches, did a merge without conflict, but still asked for a commit.
Is there a way to automatically commit when a hg pull -u did not create any conflict?
Currently, the revlog is polluted with many "Merge..." commit messages, and I'd really prefer to not see them (although the merge itself should be kept in history in case the automated process makes the wrong decisions).
Nope, I don't think so. This is a fundamental difference between git and hg. Mercurial wants you to make sure the merge was correct, possibly by running your test suite, before committing.
If you don't like merge commits, maybe you should be rebasing your work instead of merging? It's common practice to keep history linear by rebasing feature branches instead of merging.
If you are rebasing a lot, it helps if you make use of the phase system by pushing WIP work to a non-publishing repository and then once code passes review and gets accepted, it gets rebased and then pushed to a publishing repository. You might also find the evolve extension useful, especially if you are working collaboratively with a team, as that will propagate the history editing operations between developers.
you could use an alias for that:
alias hg_pull='hg pull -u && hg commit -m "No Merge Conflict"'
Running hg_pull from your repo should do more or less what you wish.
If anything goes wrong at "hg pull -u" step, the commit is not triggered.
Let me know if something is unclear!
With repos laying around waiting to be checked in, people merging branches at random time, and general mayhem, I need to figure out exactly what(which changesets) was at the tip of main branch at the time of release (label/revision). And I have to do it retroactively and automatically.
It seems like a basic thing that should be able to be achievable with hg log, but I can't figure out how. Please help!
With #planetmaker advice, I've tried the following, and it seems to be working!
hg log -r "branch(default) and ::HashNumber"
The answer to your problem lies in the use of revsets. Checkout hg help revset for a complete list of what you can do with them.
If you are interested in the changeset last changeset in BRANCHNAME prior to a certain time: hg log -r"last(date(<2012-01-01)) and branch(BRANCHNAME)" (hg help dates for options how to define the date, including exact time).
Now, if you want to use this information in a script you do not want the full log output, but just the revision or hash itself. Use the template capability to format output. Thus amend the log call appropriately:
hg log -r"last(date(<2012-01-01)) and branch(BRANCHNAME)" --template="{node|short}\n"
in order to only get the hash. Or use {rev} for the numerical changeset version (which is local to that very repo only, though); see hg help templates for a full list of what you can output.
So we work in "named" branches with what we do, but it's now come to light that this "name" we use should also be used in the commit message to help with tracking etc.
If we're using TortoiseHG or Mercurial, is there a way to automatically append/preappend the brnachname to the commit message?
I've looked around and can't find anything that matches exactly what we need :(
So for example:
hg commit "did a change" in the "RR-3498" branch will become something like
"RR-3498 did a change"
or
"did a change RR-3498"
Thanks
this "name" we use should also be used in the commit message
Branch name must NOT be used (I can not emphasize more strongly here) in commit message - it's redundant, duplicate information, which require additional actions for extracting from log message for processing
Branch-name in Mercurial is permanent meta-data, always stored in each changeset.
If you use Mercurial for "tracking", then the most of usable commands (I can imagine only hg log for now) are templateable, and you can output branch name easy. If you use some external tool, you can on preparing data for it from Mercurial combine "clean" commit-message and branch-name of changesets
Don't forget about MYOB principle
You can write a hook for this.
That said, this requirement sounds like from a pointed-hair manager.
I recently let the IDE replace a trivial text in the entire project, and recognized that mistake only after committing other changes to Mercurial. I panicked and (knowing very little about Mercurial, now after having read the definitive guide starting to get to know it better) tried every command that seemed to make my mistake "go away". It goes without saying that this was a move I am not proud of.
Of the things I remember to have tried was hg update tip and hg rollback. Since I'm using Mercurial on my local machine only and do not pull or push from any other repository, I think these commands did not cause my main problem: There are a lot of files missing now -exactly the files I let the IDE make the wrong replacements in.
What bothers me is that I have done hg status --change REV to find all files changed in a revision, and the deleted files do not show up there.
PHPStorm has a local history, which shows which files are now missing. That (only that?) enables me to hunt down the individual files and revert to their last known revision:
hg log -l 1 path/to/foo.txt
hg revert -r <my revision> path/to/foo.txt
... but that is way too time-consuming for the hundreds of files that got changed. Please tell me there's a better way. The PHPStorm history is nice and can restore the files as well, but it will restore them to the point where they had already been erroneously changed.
Your help is greatly appreciated, and I vow to learn & appreciate Mercurial as more than just a context menu item starting today.
If you are willing to lose the changes that were committed with or since the error, you may be able to go back to the revision just before the error, and start working from there. Use hg log to find out which revision you need, and hg update --rev XX to go to that revision. If you're not sure which revision you want, update to various revisions and take a look.
Once you have updated to the correct revision, you can just continue working from there. The next time you commit, you will automatically create a new branch on which you'll be working, which will not have the error in it. If you want, you can go back to the original branch and close it.
You might even be able to get back any correct commits that happened after you committed the error up to the revision you rolled back to. On the old branch, identify the revision after the error, and do a diff between that revision and the tip of that branch. Then, see if you can apply the diff as a patch on your new branch. You will still lose any changes that were in the same commit as the error, though.
If I do 'hg status' and see the following:
R flash/AC_OETags.js
it seems to mean that there is no file there, but there has been one at some point that has been removed.
How do I 'commit' this change so it stops showing up when I do 'hg status'?
==UPDATE==
The answer seems to be to commit the file. Actually, there are ~100 files with status R because I removed an entire directory tree. Anyone know how to commit all files in a directory tree in one go?
I don't want to do just hg commit, because there are other changes too.
The “R” means “Removed” so the next time we commit in Mercurial this file will be removed. (The history of the file will remain in the repository, so of course we can always get it back).
therefore run your hg commit command and all will be well
Thanks to hginit.com for that titbit - its my Mercurial bible
You can commit just that file:
hg commit flash/AC_OETags.js
however having "masses of other uncommitted files" is terrible process. You need to come up with a workflow that lets you commit frequently.
You can use the repository explorer from TortoiseHg to easily manage the files you want to include in a commit.
Also, removing a directory probably warrants a changeset in itself. You should get into the habit of committing more often (one concept, one commit... and it's local anyway). Furthermore, as long as you haven't pushed your changes to anyone (or anyone pulled from you) you could still use hg rebase --collapse to regroup some changesets if you think you have separated too much (this is a more advanced feature that I suggest you try on a test repository first as you could break things if you're not careful)