I made a commit to the default path in my hgrc before I'd updated the path to my new domain. Now, if I then change the path and try to push, it seems as though it's trying to push to the old path (hg complains of some HTML - the same HTML produced by the landing page for my old domain). Any ideas on how I can undo this commit?
Mercurial uses one place, and one place only, to determine where to push, and that is the hgrc file in your .hg directory in your repository.
So, to fix this, simply open up the hgrc file in that directory in your favorite text editor and examine the [paths] section, since you're allowed to try to push somewhere at all, that section is bound to be there.
In that section you will most likely have the following:
[paths]
default = http://olddomain.com/
Simply change the url there, and attempt the push again.
Note that there is nothing recorded in the changeset that identifies the place where you intend to push, so there is no need to undo the changeset or otherwise fix it, the information you need to edit is completely separate.
Related
I would like to know if I right click on an unstaged file and click on discard, will that remove the file from my folder or will it just "undo" the changes I made but leave the file alone. Also will it affect my files on bitbucket. I'm worried that if I discard the file it will delete it and then I would have problems pulling my files down from bitbucket.
I'm sorry if these are silly questions.
discard will only remove the local file changes that you have made to a specific file. This will put the file back to the state it was in the last commit. remove completely removes the file from version control which will result in git no longer watching the file. This would result in changes made to the file not being reflected in your Sourcetree.
I feel like this question must have been asked before, but I'm not finding it on here. I have a file that I want in a GitHub repo, in this case a file in which the user would paste their API keys after cloning. I want this blank file to be cloned down, but I don't want it to be tracked or pushed. I already have it listed in the .gitignore file that is contained in the repo, yet after pulling and modifying the file, git status still shows the file as being tracked and having changes that need to be committed. How can I get around this?
You could do something like this via Github Enterprise's pre-receive hooks functionality.
From the readme, you can create a pre-receive hook that:
Prevents sensitive data from being added to the repository by blocking keywords, patterns or filetypes.
It is possible in GitKraken to revert changes of a single file to an earlier commit instead of reverting an entire commit?
Answer
A revert in the git-sense of it can only be performed on a commit. It introduces a new commit that exactly negates the reverted commits' changes. See here. GitKraken supports this: right click on a commit, Revert <branch> to this commit.
What you want to accomplish, however, can be done via git checkout. I do not think GitKraken supports this funtionality for a single file yet. You can, however, use the command line.
Reset single file via command line
git checkout <commit> <file>
Check out a previous version of a file. This turns the <file> that
resides in the working directory into an exact copy of the one from
<commit> and adds it to the staging area.
Documentation can be found here.
git checkout HEAD~1 <filename> will thus reset a single file to the commit before the current HEAD.
You can accomplish this in the GitKraken UI, but it's a little roundabout:
Revert the most recent commit(s) back to where the file was deleted, but when GitKraken asks if you want to immediately commit the reversion, click no.
Unstage all changes
Stage only the add for the file you're trying to restore
Right click in Unstaged, and Discard all
This should leave you with only an add for the one file you wanted to restore. Commit that, and now you've got your one file back.
Note that this can work across numerous commits, not just one... but since it's going to have to roll back everything from all of those commits, and then discard all of the rollbacks (except one) it can be quite slow if involves massive changes. In situations like this, it is probably better to use the git CI as suggested in kowsky's answer.
Although it doesn't strictly involves using git commands, GitKraken offers the possibility to visualize the content of any project file at any given commit.
When acting on a single file, it might be much easier to copy/paste the targeted commit file's content than using complicated git commands that might very well end up messing your whole project's commit history.
To achieve this, simply:
Open your git project in GitKraken
Click on the desired commit in the commit history line
In the right panel, check the View all files checkbox
Locate the desired project file and click on it
The file content will be displayed in the main panel
You can now copy/paste the content
Simple and efficient when you only need to revert a very limited number of files...
GitKraken 7.3.0 (probably older versions too) does allow for effectively running git checkout on a single file in the UI: Right click on the file under "unstaged files" and select "discard changes". Works on folders as well.
(This answer was previously a comment to the accepted answer)
You can make an UNDO to the last commit edit it and after that make a Force push to overwrite that. Works very well
Hope GitKraken can do this, as "TortoiseGit" does.
Sometimes need arises to update a library or file that has previously been put into .hgignore.
Normally, I would delete its entry from ignore list, commit/push a change and put ignore entry back.
Is this a good practice or there is some better/elegant way to deal with such a situation in Mercurial?
From the hgignore man page
The Mercurial system uses a file called .hgignore in the root directory of a repository to control its behavior when it searches for files that it is not currently tracking.
This library is obviously tracked. At some point you did hg add <library>. hgignore is no longer part of the equation for this file. In the future just update your library and commit.
hgignore is used for things like stopping mercurial talking about certain files when you do an hg status or adding them on hg addremove. It doesn't stop mercurial noticing if a tracked file changes.
You don't need to remove the entry from .hgignore; you can just hg add the file.
However, when you use a GUI, this GUI might use the .hgignore entries to show you a filtered list of files you can add. In this case, you would either have to add the file maqnually with hg add, or remove the entry temporarily from the .hgignore file.
There are certain files in my repository that I want to be able to edit locally. But I never want to push any changes to those files to the server. Is it possible for me to set that up?
EDIT: to clarify, I do want to pull changes that others have made. But I don't want to push my changes.
It's not easily possible. Mercurial doesn't push and pull files it pushes and pulls changesets. Your only route would be to never commit those files. Ignoring them isn't an option because they're already tracked (added) and tracked always overrides ignored.
You could explicitly exclude them on commits like.
hg commit -X a-file-I-changed -X another-file
And since you'll eventually forget to do that you could set up an alias in your hgrc:
[alias]
mycommit = -X a-file-I-changed -X another-file
However, I'm going to go out on a limb and guess you're talking about a configuration file like a database settings file. The best way to handle that is to commit not database.conf (or whatever it's called) but instead database.conf.sample and then have your launch script copy database.conf.sample to database.conf if it doesn't already exist. That's the normal practice.
If your change is substantial consider making it a patch in a Mercurial Queue. You can pop your change, pull their changes, and then push your change back on to the working dir. If it's a change you couldn't bear to lose you can make make the queue a repository of its own, and then clone that repository elsewhere.
A Ry4an writes, you can exclude the file when you commit. A colleague of mine has made a simple extension that will automate this in simple cases:
https://www.mercurial-scm.org/wiki/ExcludeExtension
https://bitbucket.org/aragost/exclude/
The non-simple case is a merge -- Mercurial wont let you exclude files when you commit a merge. For now, you'll have to move the modified file aside, revert it, and then move it back after the merge. Patches are welcome to handle this case!