Hi i want to revert all changes to the files with a specific filename in a local repository.
In this case AssemblyInfo.vb, i'm using the TortoiseSVN cli.
I have the following directory structure
Root
Project 1
File1.txt
My Project
AssemblyInfo.vb
Project 2
File2.txt
My Project
AssemblyInfo.vb
Now while standing in Root i run the command svn.exe revert --recursive AssemblyInfo.vb and the output i get is:
Skipped 'AssemblyInfo.vb'
I have tried to add double and single * before the filename with no success, does --recursive/-R work or what am i missing?
svn help revert gives the following output:
revert: Restore pristine working copy state (undo local changes).
usage: revert PATH...
Revert changes in the working copy at or within PATH, and remove
conflict markers as well, if any.
This subcommand does not revert already committed changes.
For information about undoing already committed changes, search
the output of 'svn help merge' for 'undo'.
Valid options:
--targets ARG : pass contents of file ARG as additional args
-R [--recursive] : descend recursively, same as --depth=infinity
--depth ARG : limit operation by depth ARG ('empty', 'files',
'immediates', or 'infinity')
-q [--quiet] : print nothing, or only summary information
--changelist [--cl] ARG : operate only on members of changelist ARG
Global options:
--username ARG : specify a username ARG
--password ARG : specify a password ARG (caution: on many operating
systems, other users will be able to see this)
--no-auth-cache : do not cache authentication tokens
--non-interactive : do no interactive prompting (default is to prompt
only if standard input is a terminal device)
--force-interactive : do interactive prompting even if standard input
is not a terminal device
--trust-server-cert : deprecated; same as
--trust-server-cert-failures=unknown-ca
--trust-server-cert-failures ARG : with --non-interactive, accept SSL server
certificates with failures; ARG is comma-separated
list of 'unknown-ca' (Unknown Authority),
'cn-mismatch' (Hostname mismatch), 'expired'
(Expired certificate), 'not-yet-valid' (Not yet
valid certificate) and 'other' (all other not
separately classified certificate errors).
--config-dir ARG : read user configuration files from directory ARG
--config-option ARG : set user configuration option in the format:
FILE:SECTION:OPTION=[VALUE]
For example:
servers:global:http-library=serf
If i run svn.exe revert --recursive AssemblyInfo.vb in a directory that directly contains a modified AssemblyInfo.vb it works as intended.
svn revert is designed to help fix mistakes, not cause problems by "helping" users to accidentally or unintentionally remove their local and uncommitted changes.
If you want to revert all the changes in your SVN working copy or in a directory and all its childs, you could run svn revert . -R. But you must not run this command if your working copy has a mixture of valid uncommitted changes that you don't want to lose and the changes that you want to revert to unmodified state.
Reverting local changes is an irreversible operation. Therefore, reverting local changes in SVN working copy via svn revert must be done cautiously. Assume that you are working on a task and haven't yet committed some important changes you've been working on a couple of hours. But at the same time you have some changes in a file or directory that you want to revert. Carelessly running svn revert . -R at the root of working copy will revert all the uncommitted changes in the working copy.
Citing SVNBook | svn revert
svn revert is inherently dangerous, since its entire purpose is to
throw away data—namely, your uncommitted changes. Once you've
reverted, Subversion provides no way to get back those uncommitted
changes.
If you provide no targets to svn revert, it will do nothing. To
protect you from accidentally losing changes in your working copy, svn revert requires you to explicitly provide at least one target.
Now while standing in Root i run the command svn.exe revert
--recursive AssemblyInfo.vb and the output i get is:
svn revert does not work this way. By default, it runs with --depth=empty to ensure that it won't revert more than the user intended. But runningsvn revert with -R is the same as running it with --depth=infinity. Generally speaking, in this particular case --recursive is an alias for --depth=infinity and its purpose is to help users revert all the local modifications (e.g. after invalid merge).
When you run svn revert with --recursive, the tool expects you to specify a path to a directory in your working copy and the operation will revert ALL the changes that are in this directory and its childs. There will be no effect if the command's target is a file.
What you look for is --targets and a bit of scripting. For example, run the following commands in PowerShell console (I'm sure that it could be done more elegantly in PowerShell than in this example):
(dir -Path "files.html" -Recurse -File).FullName | Out-File -Encoding ASCII mytargets.txt
svn revert --targets mytargets.txt
dir is an alias of Get-ChildItem cmdlet in PowerShell. In this case it grabs the list of all files with name files.html and writes the full paths to mytargets.txt file. Then it runs svn revert that reads paths from mytargets.txt and revert local modifications made to the files.
I advise this approach instead of piping the output to svn revert because you can (and should) review the list of items that svn revert will process. This helps you ensure that you won't revert more that you actually intended.
On Linux this can be done using combination of find and xargs commands from findutils:
find -name AssemblyInfo.vb | xargs svn revert
On Windows you can probably install and use Cygwin which contain these utilities.
Related
I have a git repository folder on a usb taken from a linux machine.
That repo had two folders with a colon (:) in their folder name (the linux distro allowed those)
All the folders in the repo were deleted and this deletion was then staged but not committed.
This repo was then copied to the aforementioned usb.
I am now on a windows machine and would like to restore the deleted files/folders.
I tried to use these commands:
"git restore ." which restored all the files which were not having a : in their name or their folder name.
"git restore --staged ." which give me this error: "error: invalid path '<foldernamewitha:>/<filename>.<ext>'"
I guess this is because windows does not allow : in names of file/folders. Is there any way around this?
Use an OS that permits : in filesystem paths or rename the paths. Them's your options.
If you're stuck on Windows you can brute-force this with core commands, find a workable replacement for the colons. Perhaps you could use url encoding?
git ls-tree -r # | sed 's,:,%3A,g' | git update-index --index-info
index-info docs
but you'd then have to reverse the process on OS's without those limitations, and no code looking for the unmangled names would find these files, so this only gets you one more step along the way to whatever you're trying to do. It's possible "just don't use Windows for whatever this is" would be best, also possible that's not an option; if this step doesn't get you there you're going to have to explain what you're trying to do here.
edit: one possibility: are you trying to reset just the paths that don't have colons in them? s,:,%3A,g to /:/d in the above sed.
I'm working on a python project and want to rename a (package) folder to small letters, let's say from Myackage to mypackage. As git is case-sensitive and Windows is not, I followed the solutions taken from here and espacially here.
My procedure was as follows:
git mv Mypackage tmp
git mv tmp mypackage
git commit -m "Change capitalization of package name"
This changes the folder Myackage to mypackage with success (for both, git and Windows). But if I switch to another branch, I expect the folder to change back to Mypackage (with capital letter!), as it was before. Background is, that all the imports of the package are also case-sensitve in python and i need this renamng acompanied with adaptions of the imports.
I've tried both, core.ignorecase set to true and false, but no matter what I try, if I checkout an older branch, the folder remains in form of small letters (mypackage) and I run into issues within python.
UPDATE:
I've set up a small example with only one Folder and one file and could succesfully change the capitalization of the folder. It also shows the desired behaviour, that upon branch switch the capitalization of the folder in Windows changes, yet still this won't work for my python project.
Could it be, that, e.g., submodules, play a role here?
UPDATE 2:
I've checked the case sensitivity attribute for both cases via:
fsutil.exe file queryCaseSensitiveInfo .
Both folders claim, that case-sensitivity is deactivated. Still for one project folder name capitalization changes, but for the other folder not.
The attribute case sensitivity is available on Windows 10 but after April 2018 Update and only affect the specific folder to which you apply it. It isn’t automatically inherited by that folder’s subfolders. However, if you use WSL to create folders it's enabled by default and available in that way to Windows. [1]
Although you can use the Git Unite [2] tool to match the case of the current folders with the git index.
If you use the rename approach, try using it with git commands like in "Rename files and folders with git"[3]
git mv foldername tempname && git mv tempname folderName
I found a way to reproduce your behavior :
if my CaSeD folder contains some extra files (untracked files for example), git will not change the case of my folder name when I jump between commits.
Is this the case in your setup ?
If this is your issue : you could go with a post-checkout hook, which forcibly renames the folders according to what is stored in HEAD after a checkout.
One way to get the full list of paths to directories from commit HEAD is :
git ls-tree --name-only -d -r HEAD
If you match this list with a similar list extracted from your local file system (ls -r ? find . -type d ? some python function from os.* ?), you can spot what folders need to be recapitalized.
I am having issues with the command-line client of svn - svn-win32.
Current situation:
We have a directory with multiple subfolders, like so
file1
folder/archives/file2
folder/archives/file3
Situation1:
A new file is added via checkout.
Everything behaves as it should.
Situation2:
An existing file is modified via checkout.
Result: Existing file remains, and is marked as "modified".
Desired result: Existing file fully overwritten, local changes lost.
How do i achieve the desired result?
svn revert -r pathname
svn up
did not help.
svn revert requires a path be passed in; use svn revert -r . to discard all changes in the current directory and everything below, or specify a directory or file if you want to revert that path and everything below it. Then you can run svn update.
I recently updated Git to version 2.7.2.windows.1 (I am running Windows 7 64-bit). Since the update, I have been unable to run git add with the -p option on files within a certain directory (or its subdirectories) whose name is _ (an underscore).
git status correctly reports that my file has changes:
PS C:\Users\Carl\www\dl> git status
On branch develop
Your branch is up-to-date with 'origin/develop'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: _/php/class.Menu.php
And I can add the entire file with a simple git add, or by specifying the file by name. But if I try to include the -p or --patch option (both variations produce the same results), Git reports that there are no changes:
PS C:\Users\Carl\www\dl> git add -p .\_\php\class.Menu.php
No changes.
This only happens for files within the _ directory, but it doesn't matter whether I cd into that directory to run the git add command without having to explicitly specify a path with an underscore in it; it still doesn't work:
PS C:\Users\Carl\www\dl\_\php> git add -p .\class.Menu.php
No changes.
I had initially thought this problem was related to a similar one I encountered recently on files within the _ directory, which I asked about here. However, that problem appears to have been related to Posix path conversion in MinGW, whereas this problem occurs whether I use Git Bash, Windows PowerShell, or cmd.exe.
As I said in that previous question, I believe underscores to be valid in file/directory names. Additionally, I am not the owner of the project so I cannot rename the directory or move the file.
Is this a bug in Git? Are there any additional steps I can take to determine what the underlying issue is?
Well, I was able to reproduce this, and seems that it is the same POSIX-to-Windows path conversion. ProcessMonitor shows that git (actually, perl run by git) looks for a file C:\Program Files\Git\php\class.Menu.php.
To work this around (at least, that worked for me), according to documentation, you can set the environment variable MSYS_NO_PATHCONV temporarily, like so (in git bash):
MSYS_NO_PATHCONV=1 git add -p _/php/class.Menu.php
(I don't know how to set env variables in windows' cmd/powershell, but that should be possible, too.)
You shouldn't enable MSYS_NO_PATHCONV globally/permanently (e.g. using export in git bash or modifying windows' user/system environment variables in system settings), because that can lead to unwanted effects, and it'll probably break much more things than it'll fix (see this SO comment). Actually, git-windows folks warn against even temporary enabling MSYS_NO_PATHCONV.
Having said that, I'm starting to think that OP's problem is a git-for-windows bug and should be reported as such (might have something to do with the fact that git-add is a binary, but git-add--interactive is a perl script).
Another listed workaround is to double the first slash, like git add -p _//php/class.Menu.php (or does that mean the parameter must start with a double slash?), but that doesn't seem to work due to complex intermediate path conversions, that happen between the invocation of git add and the real file access.
I'd try without that .. Also I've never passed a filename to git add -p. I just make my change and run that as is. I would also check to make sure any changes you're making are in fact being applied to that specific file, and the file is being touched.
I have an XML file that we consider binary in git. This file is externally modified and committed.
I don't care about who edited it and what's new in the file. I just want to have the latest file version at every pull. At this time, at every git pull I have a merge conflict.
I just want that this file is overwritten on every git pull, without manually doing stuff like git fetch/checkout/reset every time I have to sync my repo.
Careful: I want to overwrite just that file, not every file.
Thanks
I thought you could use Git Hooks, but I don't see one running before a pull...
A possible workaround would be to make a script to delete this file and chain with the needed git pull...
This answer shows how to always select the local version for conflicted merges on a specific file. However, midway through the answer, the author describes also how to always use the remote version.
Essentially, you have to use git attributes to specify a specific merge driver for that specific file, with:
echo binaryfile.xml merge=keepTheirs > dir/with/binary/file/.gitattributes
git config merge.keepTheirs.name "always keep their file during merge"
git config merge.keepTheirs.driver "keepTheirs.sh %O %A %B"
git add -A
git commit -m "commit file for git attributes"
and then create keepTheirs.sh in your $PATH:
cp -f "$3" "$2"
exit 0
Please refer to that answer for a detailed explanation.
If the changes to your files are not actual changes, you should not submit them. This will clutter your version history and cause numerous problems.
From your statement I’m not quite sure which is the case, but there are 2 possibilities:
The file in question is a local storage file, the contents of which are not relevant for your actual sourcecode. In this case the file should be part of your .gitignore.
This file is actually part of your source and will thus have relevant changes in the future. By setting up the merge settings like you are planning to do, you will cause trouble once this file actually changes. Because merges will then be destructive.
In this case the solution is a little bit more complicated (apart from getting a fix for the crappy tool that changes stuff it doesn’t actually change …). What you are probably looking for is the assume unchanged functionality of git. You can access it with this command:
git update-index --assume-unchanged <file>
git docu (git help update-index):
You can set "assume unchanged" bit to
paths you have not changed to cause git not to do this check. Note that setting this bit on a path does not mean git will check the
contents of the file to see if it has changed — it makes git to omit any checking and assume it has not changed. When you make changes
to working tree files, you have to explicitly tell git about it by dropping "assume unchanged" bit, either before or after you modify
them.