I am attempting to dump a mysql database and add the .sql dump file to the staging area using a pre-commit hook so it can then be included in the commit (on Windows Server 2012 R2/IIS). The following code dumps the database nicely, but after I commit it still shows the be.sql file in the staging area...sometimes(?) - it seems to be adding the file to staging AFTER committing(?). This is a pre-commit hook so I have no idea why it may be adding the file after the commit takes place:
#!/bin/bash
# Dump Database
/c/Program\ Files\ \(x86\)/MySQL/MySQL\ Server\ 5\.7/bin/mysqldump.exe -u root --skip-extended-insert be > /c/inetpub/wwwroot/directory/be/be.sql
# Add Database
cd /c/inetpub/wwwroot/directory/be
git add be.sql
The behavior is a bit strange - I will see be.sql is still in the staging area so I will make a commit. If I git status afterwards the tree is clean. If I commit again and git status it will display the be.sql file in the staging index as modified (I didn't modify it). And back and forth it goes. I just want it to dump the .sql file, add the .sql file to the staging index, THEN commit so every time the staging index is clean. Any ideas as to why this is happening would be greatly appreciated.
Using:
git commit -m "Message" --allow-empty
when making the commit appears to have worked. It seems as if git needs other staged changes in order for the hook to work. So it was basically not making the commit, but still dumping the be.sql file, which would then show up in the staging index as modified the next time around because the date had changed. In order to allow the commit to fully go through regardless of whether or not there were other staged changes I used the --allow-empty option, which allows a commit with nothing in the staged index.
Related
I have accidentally run hg strip, and deleted a stack of commits. I have not done anything in the repo since. Is there a way for me to bring back this stack of commits, to undo the hg strip I just ran?
As long as you didn't run the strip with the --no-backup option, the stripped changesets can be found in the repository under .hg\strip-backup. If you sort the directory content by date the latest one is likely the one you need to restore. Restore it with hg unbundle <filename>.
It is possible to hg pull from a strip backup file as an alternative to using hg unbundle.
As noted in a comment on another answer to this question, hg unbundle has fewer options and only works with bundles, but can unbundle more than one bundle at a time. Whereas hg pull can pull from a single source (share/web/bundle) and has other options.
Here's an example of using hg pull based on an external post by Isaac Jurado:
Usually the backup is placed in REPO/.hg/strip-backup/. See the
example below:
$ hg glog
# changeset: 2:d9f98bd00d5b tip
| three
o changeset: 1:e1634a4bde50
| two
o changeset: 0:eb14457d75fa
one
$ hg strip 1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
saved backup bundle to
/Users/hchapman/ttt/.hg/strip-backup/e1634a4bde50-backup.hg
And then, what one would do to recover those changesets would be:
$ hg pull $(hg root)/.hg/strip-backup/e1634a4bde50-backup.hg
Here is a worked example of unbundle from an external post. I've cleaned it up slightly to make it a little more general:
Recovering stripped files when using Mercurial
If you accidentally strip a patch and do not have a backup for it, you
can still recover your files using Mercurial. To recover your files:
Open a Microsoft Windows Command Prompt window.
Navigate to the project folder where you stripped the files.
Run the dir command
Navigate to the .hg folder where Mercurial stores all relevant project
files.
Run the dir command again.
Navigate to the strip-backup folder where Mercurial stores the backup
bundles of stripped patches.
Run the dir command again. Multiple files display in the directory
that use the <hash>-hg format. They are the backup bundles of stripped
patches.
Use Windows Explorer to find the required file. Open the strip-backup
folder in Windows Explorer, and sort by Date modified descending.
Unless the necessary backup bundle is already known, [it is recommended to]
restore the bundles in reverse chronological order starting
from the most recent bundle.
Navigate back to the project folder.
To restore a bundle, run hg unbundle .hg\strip-backup\<bundle_file_name>. ... You may want to add it to the
PATH environment variable to make it accessible globally.
Synchronize the project [using hg pull] to see the restored patch. If
the restored patch is not the one needed, then continue restoring the
patches in reverse chronological order until the required patch is
retrieved.
Note: You may restore the backup bundles in any order, instead of
using reverse chronological order. However, it may not be safe to do
so. You may end up attempting to restore a backup bundle, which has a
dependency on another backup bundle that has not been restored. In
this case, you will get an error.
I have a situation where I renamed a few files I was tracking in a mercurial repo without using hg rename command (just doing it via the file system).
This occured several revisions ago
Now I want to return to a revision prior to the file renames, fix a bug, and then rebuild that old revision
problem i have is that i am getting error messages along the lines of:
remote changed file.txt which local deleted
use (c)hanged version or leave (d)eleted?
Is there a way I can fix the mistake I made when renaming the files all those revisions ago?
Depends on whether you committed the deletion of the files, but I assume you didn't and it doesn't seem so.
Then you can simply revert them in order to restore them to your working dir: hg revert file.txt. After that you can update to the previous revision without this question popping up. Alternatively just update to the previous revision you want to fix and accept the (c)changed version from remote.
If you want the rename to be permanent and also tracked by the repository, then commit that rename. Use hg addremove, possibly check with --dry-run first what it does so that no unwanted changes are added and commit the renaming of the files. Then go and update to the old revision and do whatever changes you want to commit there.
I have a file (some kind of database) which is updated as developers test their code and pushed to a central mercurial repository.
I would like everyone to reuse this file and therefore whenever there is a pull / update from our central repository the local version should be replaced by the one stored centrally. In other words I would like to do a hg update -C for that file only, and having it done automatically upon a pull.
Is this possible to do with mercurial?
Developers can add a hook that does this, but you can't make them (unless you have control over their machines).
Something like this in a clone's .hg/hgrc file will delete the local file so the update replaces it fresh:
[hooks]
preupdate = rm path/to/databasefile
Keep in mind, of course, that update will put in place the version of the file as it appeared in the changeset to which the user is updating. So if you do hg update --rev 0 you'll get the very first version of that file, not the one in the most recent revision.
As an aside, usually if there's a file that changes a lot and is unumergeable you're better off having it be an untracked/ignored file that's fetched out of band -- for example, have your launch script download the latest version.
I created a backup of my mercurial repository using
hg bundle --all name.hg
Now, how would i restore my repository using the backup file? Say if my whole repository is corrupted and all i have is just this *.hg file., Is it possible to restore my repository(assuming that is what backup is supposed to be for., but did i miss any step while backing up the repository ?)
Could someone please help me with this.
Thanks in advance
To quote the help page:
The bundle file can then be transferred using conventional means
and applied to another repository with the unbundle or pull
command. This is useful when direct push and pull are not
available or when exporting an entire repository is undesirable.
So you would be creating a new empty repository and pull from your backup file.
hg unbundle [-u] FILE...
apply one or more changegroup files
Apply one or more compressed changegroup files generated by the
bundle command.
options:
-u --update update to new tip if changesets were unbundled
Note that you can also use regular file system tools to backup your repository. Bundles are useful when you need to transfer a set of changes somewhere else (or when disk space for the backup is an issue, because they are compressed and smaller than the on-disk repo itself).
Another possibility is simply using hg clone:
hg clone name.hg name/
I want to commit separately different parts of the same file.
I want to commit line 2 first with the message (changeset 1) and the 4th line with the message (changeset 2). How do I do it?
I am using Mercurial Distributed SCM (version 3.5.2+20151001)
You can do this with the interactive option to commit.
First add the following to your ~/.hgrc file:
[ui]
interface = curses
Then use:
hg commit -i
This will tell commit to allow you to interactively select what files or (by drilling into the file) select sub file changes.
You can use this multiple times, selecting individual changes in the files.
Note: without the addition to your .hgrc, hg commit -i will ask you for each file and not allow you to drill into and select individual file changes.
The interactive option is also being implemented in other mercurial commands such as restore (you can select what changes are to be restored) and the new experimental amend command. It is very powerful and easy to use.