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.
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!
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.
we're moving from Subversion to Mercurial now. In Subversion there was possibility to add custom column into log (e.g. bug id) and force user to fill this column on every commit.
Is it possible to implement such feature in Mercurial?
Yes it's possible.
But before you go and do that, why isn't it enough to require bug fix commit messages to uphold to a certain pattern?
i.e. util: rename the util.localpath that uses url to urllocalpath (issue2875) (taken from Mercurial's repo)
Then you can install a hook on your central repository that scans incoming commit messages, and does whatever is needed when that pattern is found.
Furthermore, why would you want to force this on every commit? Is this for a QA team that should only commit bug fixes? If that's the case, a pre-commit hook that greps the commit message for the pattern sounds appropriate.
If you still want the extra field: when Mercurial commits something, it is possible to pass it a dictionary of strings, which you can fill with anything. See the transplant extension on how you might do that. You would also need to wrap the commit command and add a new command line option to it.
But I strongly suggest you think twice before doing this, because aside from the time consuming work involved in coding, testing (and maintaining this between Mercurial releases), you would also need to ensure that it is deployed on every environment where Mercurial is used.
If I do a commit in Mercurial and then realise I haven't added enough information to the commit message, is there a way to just add another message or note without commiting anything else? What is the best way to get that extra info in there?
I realise I can sometimes rollback and commit again but that is not always possible. I don't want to rewrite history either, I just want to add information.
Unless you're willing to get into editing history using MQ or histedit (and in Mercurial that's not usual practice) or it was the latest commit (rollback) then you need to commit something else to be able to add another changeset with a different commit message.
Mercurial is built around the concept of an "immutable history" and it intentionally restricts tools that let you alter the past.
If this was your last commit then you could rollback and commit again (with the new message).
I am converting a CVS repository (actually a number of them) into a Mercurial setup, and was wondering if any one had experience with updating and correcting usernames in the changesets.
The issue is that over quite a long period of time a default user has been used fairly often to commit to the CVS repository, and the commit message has then been supplied with '(initials)' at the end to identify the actual person committing. And now that I am converting to Mercurial I would like to clean this up, by setting the correct username.
Having done some research this seems non-trivial and I was thinking that something along the lines of this:
convert to hg and tag/branch commits with a specific initial in the commit message, using --config convert.cvsps.mergeto='{{mergetobranch ([-\w]+)}}'
converting this new repository and then use the --authormap to edit the default user to the persons initials.
But I am unsure if it is possible to selectively convert out branches and then get it back into its original place in the history.
Any help or ideas would be greatly appreciated. I have of course fully control of all the repository clones since it is not published in any way.
You need to use the Convert extension. You can follow the answer from this post.
The Convert extension sadly doesn't provide a convenient way to have conditional author mappings, but it does permit performing the conversion incrementally. You can then perform your conversion in small steps, inside of which a single author map is valid. You can use also script the generation of these "fence post" commits.
I had a similar problem today, where I wanted to conditionally change the username in some old commits in a Mercurial repository. I've bundled up all of my steps into a convenient script, which you can find here. The downside is that it depends on some Mercurial specific behavior, but you can work around this by first converting with a basic, non conditional author map, and then running the conditional conversion on the that repository.
This question is rather old, but if you don't have too many clones out in the wild, it may still be worth your while to run the author-name correcting conversion. Remember: hg convert necessarily changes the hash for every changeset, so you have to deal with all the usual issues of EditingHistory. I suspect this is part of the reason why both of the usual ways of dealing with this, Mercurial Queues and the newer HistEdit Extension, don't play nice with merge changesets -- it's difficult and messy to redo a non-leaf merge, and the presence of merges often indicates that you've shared the repository, which means you should reconsider editing history.