I am pretty new to HG and when I initially set it up I didn't setup my username for my local repositories. My commits display the current logged in user and machine name. i.e. adam#mypc and after setting my username I now have adam.
I would like to know if it is possible to change the previous commits that say adam#mypc to display adam.
I have multiple PCs that I work from and I'd like to keep all of the commits under the same username.
Thanks in advance.
The name of the committer isn't set at push time, it's set at commit time, and it's an unchangeable part of the changeset itself. You could re-write the changesets with new names (easiest would be using the convert command with an --authormap) but it will change hashes of those changesets and invalidate any clones out there. Going forward you can set that value as the username in the [ui] section of your ~/.hgrc file to make sure they're the same across all your machines.
Related
I use Mercurial on 2 different computers changing the same repository. If I want to keep tabs on which changes have happened on which machine, how should I record this?
I came up with the idea of using different user names on the two machines ([ui] -->
username variable in the hg config file), but does a more appropriate mechanism/variable exists for this?
This looks like a good idea; user names are exactly to identify the committer, here the computer. The alternative would be to work on different branches on each computer and merge in default often. However, the latter is more error-prone.
For a couple of years, you've been able to expand shell variables inside .hg/hgrc files.
So I just do something like this in my .bash_profile:
export HGUSER=$(hostname)
Then inside .hg/hgrc:
username=${HGUSER}
The BIG ADVANTAGE of this technique is that now you can put the EXACT SAME .hg/hgrc on ALL the machines. The same is true of .bash_profile: it can be the same on all machines. This helps a lot when you're automating machine configurations!
Note: the HGUSER environment variable is an old way of telling Mercurial your username, so, technically, setting HGUSER in .bash_profile ought to solve the problem on its own, but I believe its use is deprecated/discouraged, and I recommend defining username in .hg/hgrc explicitly, as I've shown above.
I'm trying to make a crontab that pulls and makes a repository every day for me, but whenever i do that and the repository merges the crontab gets stuck.
Is there a way to pull without prompting a merge and without deleting my code?
Is there a way to pull without prompting a merge
Just hg pull by itself does not merge, nor does it ask the user for anything. The local repository will be added to, but the local working directory will not be touched. Nothing will be deleted.
If your .hgrc file is using a [defaults] section, you might be silently adding the -u/--update option without realizing it. That option tries to automatically do an update. If that's the case, then don't use defaults sections.
If this doesn't answer your question, then show us exactly what commands your cron entry is running, what the output is, where it "gets stuck" (is SSH asking for authentication credentials?), and which part you're trying to avoid.
The literal answer to how do you pull without merging is you hg fetch which gets the new remote changesets but doesn't update any files in your working directory. It sounds like what you're really asking though is "how do I update to tip and throw away any local changes?". If that's what you're going for you'd do:
hg fetch # gets new changesets
hg update --clean # update to latest files THROWING AWAY LOCAL CHANGES
Is that what you're going for?
User A commited and pushed File A to the repo incrementing the version to 10. In the meantime, User B commited File B and started pushing out to the repo. User B got a message about 'pushing changes will create a new head, merge when possible'. User B did not know what to do at that time.
User B is me. What should I have done? I just freaked out and re-cloned the repo. My local copy was at version 9 at the time of my commit. So I wanted to update mine to 10 and then push mine out.
I am using Mercurial Hg.
Thanks.
You have to pull changes and merge them (In details you can read about it here: http://hginit.com/04.html)
Also - don't refer to revision number, it makes sense only for single repository. As long as you have several copies of the one - the better is to refer to the commit by its hash.
I am looking for a way to create an alias for a user that has commited to a mercurial repository. For example, if there is a user named user1 I'd like every commit done by him to be under the name user2.
If you're talking about changing the name that was already used for some commits, you can do that using hg convert with a source and destination type of hg and a --authors mapping file. However, in doing so you change the hash of every changeset, and if anyone has already cloned your repo you'll be hosing them.
If you're talking about commits to come, then just make them whatever you want using the -u option to hg commit.
I have some files I'd like to add to have them as a "backup". The thing is, I'd like to commit them only one time, and then, I'd like for Mercurial to don't track them anymore ( don't notify me if they're changed, and don't commit them on other commits ).
Basically, something like this:
hg add my_folder
hg commit -m "added first version of my_folder"
Then, after a while, the contents of that folder might change. And if I commit other files, the new version of that folder will get commited as well. This is something I'd like to avoid. Is it possible, without specifying directly which files I want to commit?
I've never seen any option in Mercurial that might allow that... but why not simply copy them elsewhere ?
I mean, what's the point of using a Version Tracking System if you don't need versioning on these items anyway ?
We ran into a similar case with binary documents ('.doc', images, etc...) and finally decided to commit them on a separate repository, dedicated to those.
I think the traditional way of doing this is to commit files named something like "file.ext.default", and just inform users that they should copy the defaults and modify the copies.
VCSs aren't backup sysytems. consider using a proper backup mechanism.
having said that you should be able to do this using hooks, there are many ways you could do this but ACLs would be an obvious one assuming a remote server