Mercurial -- specify that certain files should always be pulled but never pushed? - version-control

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!

Related

Revert merge in pending changes but keep local changes (Azure Devops)

I just accidentally merged to a branch that I had 40+ local changes on - so now my changes and the merge are together, which I definitely do not want, with a lot of the files having edit & merge changes. I want to completely revert out the merge, is there a way to do this? If not, I'm in trouble.
I haven't checked anything in, I just only want to keep my local changes that I made.
If you merge to a branch via pull request in Azure Devops, then you can revert the completed pull request directly.
In Target branch, select the branch where you want to undo the pull request changes.
In Topic branch name, select a new branch where the reverted changes are created, then select Revert.
Select Create pull request to merge the newly created branch in a second pull request to complete the revert. For details ,please refer to this document.
If I ignore something, you could attach detailed steps or flow for this issue , this would be much easier for me to understand and reply.
I agree with Leo BL. You can try to copy your current project folder into temporary folder. Then checkout the merge source branch and compare it with temporary folder by some diff/merge tool. However, that maybe difficult to cut your changes if they were in the same files with the merge operation.
Just a quick hint: Basically, this is a git question. So maybe you should consider giving it the git tag aswell, so you can reach a greater audience.
Regarding your question: What means local change? Is the stuff not committed at all? What does git status show?
Assuming the changes are not committed, you could use git stash. I recommend this SO question:
Cancel git merge but keep local changes
I would try it this way:
1. Backup the directory (so you have a backup if something goes wrong)
2. Stash your changes
3. Revert the merge
4. Load the stashed changes
—> You should be fine
sorry but you are in trouble. After the merge the files are replaced

How can I undo a hg push

Basically what has happened is this:
I moved a bunch of files from one directory to another directory.
I then committed my change and pushed it.
Then I notice that my "move" actually wasn't a move but Mercurial, I guess, actually copied the files I wanted to move and pasted them in the new directory and then deleted the original files.
The unintended result of this is that all the history is lost since it is no longer the old files but new ones.
So what I would like to know is how do I revert/rollback/backout this change?
I have read about all three ways but I'm still not sure which is the best way to approach this. I just want to backout my push so that I can move the files correctly without losing all the history.
You can't directly "undo" a push but there are ways to essentially negate its effects.
Option 1: The most straightforward option is if you have full control over all clones which have received the pushed commit which was in error. If so, use hg strip on all of them to remove the bad commit(s).
Option 2: If you cannot do that, you could delete the incorrectly added files and revert the deletion of the original files (example), and then just redo the operation as you originally intended.
Option 3: Update back to the commit prior to the bad one. Then use hg move to correctly relocate the files, and commit that which will create a new head (since you were working off a revision older than the current tip). Then merge this new head with the tip. That should cause the history to be retained.

Beginner help: How to remove commits to the master branch from history while keeping the changes made?

I'm new to github and have been working on a group project for school. Recently it turned out we were missing some stuff and nothing was organized (every file was just uploaded into the main directory) so I removed everything using a command in the github shell. Then I proceeded to make files and organize all the code and re-upload and store everything in there.
However, when I did this, I had to keep committing every time I made a new folder and stored a bunch of files in it. I would like to keep the changes made during those commits (because I created folders and re-uploaded the stuff), but I want to remove those commits from the history because they are cluttering up the project.
Is this possible, and if so can you please walk me through the steps. Also I'm new to github so I don't know much.
Here is a picture of the ones I want to remove from my history because they are cluttering up the screen (see red marks):
Thanks :)
EDIT: PLEASE NOTE: I don't want to revert the changes, I just want all those history to be removed because they are cluttering up the commit history.
You should use:
git rebase -i HEAD~14
To rebase and squash your unwanted commits. Just use p to mark the last commit and use f to mark the unwanted commits for squashing it with the previous commits. This will remove it from commit log keeping the changes.
More info: https://git-scm.com/book/gr/v2/%CE%94%CE%B9%CE%B1%CE%BA%CE%BB%CE%B1%CE%B4%CF%8E%CF%83%CE%B5%CE%B9%CF%82-%CF%83%CF%84%CE%BF-Git-Rebasing

Reverting one file in GitKraken

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.

Why does git stop commit when some other file was changed?

I've got a project on git, assume it has the following files:
HelloWorld.java
README.md
pom.xml
I edit/commit README.md using Github's editor; no problem. Then, in eclipse using eGit, I edit HelloWorld.java, but when I attempt to commit and push that file, I get an error: non-fast-forward. Unless I do Pull first I can't commit the java file. Why is this the case? Using SVN I never had such a problem. Why does Git not allow me to commit a file when some other, unrelated file in the project is changed? I read up on this but I still don't understand the rationale behind the issue.
BTW, I'm making all changes on master for now.
That is because git is making sure your repository is up to date with the master before you commit changes. The problem is with pushing not committing. You can't push to a repository that you haven't got all the changes for. What you can do is create a new branch with your changes and merge that with the master later if you want, that is the system git uses for what you want to do.
An SVN server will do some types of merges itself, particularly when the changes are to different files as in your case. Since SVN represents branches and tags as different parts of a single tree and a single repository can contain multiple, unrelated projects this is necessary.
But git will never do a merge on the server. And since a commit represents the entire tree, your situation is a merge even though no single file was modified by both sides that need to be merged.
Even though changes being restricted to different files guarantees that there won't be any textual conflicts between them, there can still be semantic conflicts. Imagine if you're working on a change to a library function which requires all callers to be modified, and before you push that change out another developer adds a new file which contains a new call to that function. If that new file is the only change the other developer made, SVN would allow you to commit your changes and handle the merge on the server even though that will cause the code to be broken. By requiring that all merges happen under developer control, git at least gives the opportunity for this type of conflict to be caught; even though in many cases a developer may just do an automatic merge and push the results without any checking.