I have in my .hg/hgrc the following configuration:
[paths]
default = ssh://remote//path/to/pull/repo
default:pushurl = ssh://remote//path/to/push/repo
And as expected, default is used when pull-ing and in-ing and default:pushurl is used when push-ing:
$ hg pull
pulling from ssh://remote//path/to/pull/repo
$ hg in
comparing with ssh://remote//path/to/pull/repo
$ hg push
pushing to ssh://remote//path/to/push/repo
Though, when using the outgoing command, the default path is used, not the default:pushurl:
$ hg outgoing
comparing with ssh://remote//path/to/pull/repo
This Mercurial BugTracker issue exists for some time now and there are arguments to both cases. If addressed, the issue would seem to have a simple fix, so my question is:
Is this behavior actually a feature or a bug?
This is a bug. It looks like the last word on this was a patch sent to mercurial-devel that had some test failures:
https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-November/108236.html
I suspect that if someone fixed those failures and resent the patch that it would be merged.
Related
Question title is pretty much the question. Here's a look at what I get:
I am trying to export a mercurial repository to git, but to a different directory. hg gexport works just fine without the --cwd parameter, but I don't want that -- I want to change the working directory to another one, but strangely, it says unknown command when I use that command line switch.
Any ideas?
Real hgexport is not native hg command, it's part of hggit extension
According to wiki, this part ("Using hg-git to interact with a hg repository with git") is outdated and may not reflect current state of extension
>hg gexport --cwd $PATH work in my own tests without errors (so-so, see below) with command-line expanded accordingly to requirements
hg gexport --cwd i:\Work\Personal!whyhq\ -R i:\Work\Personal!whyhq\site
without -R gexport will not find source hg-repo after cdto target location
And last, but not least: even properly used, hgexport in current hggit
hg id
15457fc67631 0.8.13
do nothing (nothing changed on target). I suppose, for getting git-repo from hg you have to use trivial hg push <git-URL> today (yes, it work, with minimal tricks on your side: branch_bookmark_suffix = $STRING in .hgrc)
Side note
If you have hggit extension enabled (globally or per-repository) hg-repo is mirrored automagically into bare git-repo (at least it seems so) in .hg/git directory, you can just copy&rename it
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)
Is there any Mercurial command or Python API that could yield the repo name? This will help developing cross-repo scripts.
The only related solution that I found is to parse the .hg/hgrc [paths] section 'default' config option.
[paths]
default = ssh://server//path/tools
There must be a more elegant solution, I think.
There is no real concept of a "repository name" in Mercurial (a repository doesn't "know" or care about its own name). I think you mean "last past component of the default pull path"?
If so, then parsing the output of hg path default would be the most direct way to get that information.
However, you should note that the default path can (and often is) changed: think of cloning a local clone time for testing:
$ hg clone http://server/lib-foo
$ hg clone lib-foo lib-foo-test
$ hg clone lib-foo-test lib-foo-more-testing
The lib-foo-more-testing clone has a default push path back to lib-foo-test.
This means that parsing hg paths default wont be much more reliable than using basename $(hg root) — both can be completely different from the (base)name of the repository that was originally cloned.
If what you really want is to get an "identity" for a repository, then you should instead use
$ hg log -r 0 --template "{node}"
The first changeset hash in a repository will normally uniquely identify the repository and it will be stable even when clones change names. (If a repository has two or more roots, then the zeroth changeset can in principle differ between clones. People will have to actively try to make it differ, though.)
If you want to get last segment of path for remote default alias, processing output of hg path default will be better choice
If you want to get local directory name of you mercurial repository, I haven't good solution, except checking code of Notify extension (in which, after some tricks, you can get project-name)
Occasionally when performing a rebase using the MercurialEclipse plugin my repository gets thrown into an odd state. It will become stuck in a "rebasing" state, yet when I try to abort the rebase (e.g. "hg rebase -a") I get this error message:
abort: unknown revision 'xxxx'!
Where xxxx is a revision hash. Usually at this point I've abandoned all hope of performing the rebase -- I just want to get back to a happier time when my repository was not screwed up. So far my solution has been to nuke my project directory and clone it again. Is there a less drastic solution?
Just remove the .hg/rebasestate and your repo will work.
The patch described in this thread calls the internal function clearstate which just unlinks this file.
In situations similar to this, I usually do:
$ hg check
$ hg verify
$ hg up -C default
Instead of default, use whatever branch you're working on. This takes time, but so does re-cloning the repo.
It usually helps.
according to Mercurial's commit help message:
If a list of files is omitted, all changes reported by "hg status" will be
committed.
Is there an easy way to change this behavior?
I'd like Mercurial not to commit any changes, unless the files are explicitly specified.
edit
I am on Linux and I am using the command line.
This seems to do the trick:
$ hg commit -X *
nothing changed
It doesn't do anything because all files are excluded, but if you give any files, those will be included.
You could alias it:
[alias]
xcommit = commit -X *
then:
$ hg status
M a
M b
$ hg xcommit -m 'no files specified'
nothing changed
$ hg xcommit -m 'picking a' a
$ hg status
M b
Personally I wouldn't want to get used to this type of workflow. It's usually just as easy to:
work in smaller chunks so your changes reflect a single changeset
for the times when you forget and you're on a coding spree, use something like hg record
for the really few times when the above two don't fit, use -I/-X for that single commit
if you are using GUI like tortoiseHg you can select the files you need to commit. http://tortoisehg.bitbucket.io/