I have a file that has two independent modifications. I would only like to commit one of them.
Is there any way to only check in part of a file (without me modifying or shelving/unshelving it)?
Essentially, create a temp file on commit that then gets checked in instead of the file on disk?
No, the only way is to shelve what changes you have, revert back or the previous version and apply the changes that you want to commit. After committing them, revert back to the shelved version.
Related
In one of the file of my project there is the code of the protection dongle. Normally before committing I set the code to 0, but once I forgot to do that and now the code is stored the local git archive. I don't want to discharge all the history (I made some other commits after), but I only want to remove that specific file from that specific commit (I know its SHA) leaving all the other committed file in the same commit.
Is it possible? If yes, how can I do it?
I followed the steps indicated here: https://sethrobertson.github.io/GitFixUm/fixup.html#change_single_deep_simple (my case should be "Changing a single commit involving only simple commits") but I don't know how to remove the file with the code.
Following the link Remove sensitive files and their commits from Git history I got here https://help.github.com/articles/remove-sensitive-data/ where there is the tool named BFG. It could be maybe brute force, anyway it replaced all the occourences of the secret code.
In VS/TFS 2013, in the History screen, when you right click a changeset and select "Rollback Entire Changeset", TFS immediately clobbers all your recent local changes, and attempts to merge where it has merge conflicts. Deleting files, undoing work.
I made this mistake just now, and I'm looking for a solution that allows me to undo the rollback operation.
Note that I haven't committed anything yet. However TFS has already deleted local files and undone work, and saved those changes to disk.
In the Merge screen, I was able to select "Undo Rollback" for any file that had merge conflicts. But for those files that didn't have merge conflicts, they were automatically resolved, and I don't have the option of undoing the rollback.
Is there a way to cancel the rest of this rollback operation without undoing all my local changes?
Is there a way to revert files that were Auto Resolved by the rollback merging into the local changes?
Is there a place on my hard drive where TFS stores the previous version(s) of files it's about to commit?
Next time, I'll remember to make a shelveset before attempting a rollback. This sucks.
Thank you.
No, there is no easy to undo the local uncommitted changes 😩.
I always do rollback and branch operations in a separate workspace to avoid conflict.
I work in Visual Studio on C# project.
I edit some files it that project simultaneously. After some work is done i want to divide all changes to "groups" of changes and commit each group changes to separate commit. Its okay when it comes to files - i include one files, exclude others and all is fine.
But problem appears when some changes are in the single common text file. I'd like to split them to different check-ins by TFS itslf, but as far as i know it is not possible.
So tell me please, is there any way to split changes to distinguish them due development process? For example when i start editing common file i press something button or issue a command. Later, when i have to add changes regarding to another check-in to that file, before these changes are really done, i press another button (another command) and since this moment changes are recording as needed to be commited to another check-in.
I hope you understand what i mean. Sorry for my bad English.
If you are going to make a quick change to a file that has work in progress, you should shelve the changes and revert to the source control version (uncheck the "preserve pending changes" box). Then you can make the changes and check in the file. After that, unshelve your changes (your work in progress) from earlier, VS will merge the changes with your checking and you can carry on.
Since it sounds like you have already made the changes and the file contains code you are ready to check in and code you don't, one thing you can do is to shelve the changes now (but do "preserve pending changes"). Then you can delete any code that aren't ready and check in the file. After check in, you can unshelve your changes.
You might want to consider using branches to isolate your long-running changes; although that has its own set of problems.
You could create another workspace on your computer, and use each workspace for a different task. That way, you can work simultaneously on different tasks on the same file without affecting each-other. When you check-in from one workspace, do a "get latest" on the other workspace and merge the changes there before you check-in the other work.
We have multiple developers working on a single Web Application/Project. For that purposes we use AnkhSVN.
One of the developers made some changes and committed the project. Few days later another developed in the team made some changes and made a commit also.
After that, the first developer's changes disappeared. The second developer's changes overridden the first developer's changes.
How to restore? How to keep both updates?
Please be specific. The resolution of this topic is very important.
Actually you cannot commit changes when you are not up to date. I would guess that the second committer did something bad... So the problem is now to get the two changes to merge "posthumously".
To recover I would try (assuming that I correctly understood what you did; and it is educated speculation, because I havent tried it):
copy the current state (without the .svn-folders!) into a temporary folder - this should be the changes of committer 2 to the initial state
roll back to the revision before the first one committed ("update to revision") - i.e. to the version they both have (probably) started from
copy over the changes from the temporary folder
Update to the revision after the first one committed. This should try to merge the changes, and will possibly bring up some conflicts which you will need to resolve manually (this is probably where number 2 made a mistake).
After this you should have both changes in the working copy.
clear the temporary folder and copy the current state (without .svn folders again)
now we are getting ugly: update to HEAD revision and copy back the changes
Check that you have something that makes sense (compile) and commit.
Remember that you cannot really loose anything unless you corrupt the repo - this is version control after all... :-)
I ended up having a few Tortoise and/or Subversion malfunctions, and somehow ended up with several versions of the same project:
...\Projects\
MyProject
MyProject(1)
MyProject(2)
MyProject(2) is the one that is the "true" one, and is thus the one I want to keep.
I cut and pasted both MyProject and MyProject(1) to a "holding tank" for eventual deletion, so that I now have:
...\Projects\
MyProject(2)
Now I want to change the name MyProject(2) to MyProject, but I'm afraid to - Tortoise/Subversion is so picky about everything (IOW, it works as intended) that I'm afraid that if I change the name, everything will get all hosed up.
Am I being unduly paranoid? Should I just go ahead and rename it, or does Tortoise/SVN have some "refactor" ability that will make that a safe operation, or...?
You are not being truly paranoid, once you commit, you have that commit forever, it's worthwhile to take the time to make sure your commit is right. Otherwise, you'll still have to spend that same amount of time to do the "fix" commit.
You probably "saved" through the gui some set of items multiple times, and the "window manager" has an option to not overwrite files by adding (1) and the like. If so, odds are good that only one of the branches is actually under revision control. Do a
svn status
in a few directories to determine if these sub-directories have only been copied in place on your system, have been copied and added on your system, or have been copied, added and committed to the repository.
If they have only been copied in place, discover which "copy" is the best, and move the contents of that copy to the "correct" location, and delete the others. Then svn add whatever is necessary and commit.
If they have been copied and added, discover which "copy" is the best, svn revert everything you do not intend to commit, move the contents of the "best" copy to the correct locations, and delete the unneeded files. Then svn add whatever is necessary and commit.
If they have been copied, added, and commited, then svn delete stuff that's "in the way", svn commit, svn move the right stuff into it's correct location, svn commit, svn delete the other unneeded files, and svn commit.
There are many other variations on how to fix this (some much better than I have demonstrated), but hopefully the above examples will get you thinking along the right paths. My examples involve more steps, to keep things simple.