I use svn to sync my text files or any important notes which i place in my mac filesystem to my server. So, when i modify the file i use Sublime to add or delete files which are under svn-control and thus gets unsync with svn commands.
How do i fix it other than running the svn commands? I know i should use svn commands to rename or add or remove the files, but how do i do without using svn command? In Windows, i believe tortise SVN make note of those changes and we just need to commit but is there any software for mac which does the samething?
$ svn status
? MySql/MySQL_Start_On_Different_OS
! OS/Software/Nginx_Atmosphere.txt
! OS/Software/Nginx_Caching.txt
! OS/Software/Nginx_RpmInstallation.txt
! OS/Software/Nginx_Windows.txt
Again, i know i can fix the above status by doing svn add or svn remove <filename>. Atleast was there any command or script that convert ! to remove and ? to add?
To the first part of your question: Since you mention TortoiseSVN, I think you are looking for a graphical user interface to svn that helps you with adding/deleting files. Here is a short overview of available clients for OS X. I have personally used Cornerstone and was content enough with it, although there are certainly cheaper options that sound like they fulfil your requirements just as well.
As to the part where you are looking for a scripting solution: Use
svn st | grep "^?" | awk '{print $2}' | xargs svn add
to add all files marked as unknown by svn (i.e. ?). Use
svn st | grep '^!' | awk '{print $2}' | xargs svn rm
to remove all files that were already marked as deleted by hand (e.g. !). Then commit to svn with
svn ci -m "Your commit message goes here."
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.
We are team of users, who work on Windows, our Remote is in Bitbucket (Linux/UNIX) and our application is being deployed to Linux machine. We didn't pay attention to line endings, until one day we found out, that .sh scripts on our laptops have CRLF line endings. We decided to set core.autocrlf to false, so there will be no differences between line endings on Remote and line endings on our Windows laptops. However, this option does not change CRLF in our local source code.
Is there any way, how to tell Git to update all files so CRLF will be changed to LF as it is on Remote? Some kind of re-download, that would download even unchanged files.
No, there is no way to tell git to change all your files for you. Git simply stores the files. But you can clone your repo, update your files locally, and then push the changes back.
From a unix-style shell you could use the commonly available tool dos2unix for easy conversions. Something like this might fly:
git clone bitbucket:path/to/repo foo
cd foo
find . -type f -name \*.sh -exec dos2unix {} {} \;
git add .
git commit -m 'convert line endings on .sh files'
git push
If you can't find dos2unix, you can duplicate the functionality with a number of other tools, for which answers are readily available already here or via your favourite search engine.
UPDATE
If what you're really asking is "how do I refresh a local copy of a repo, overwriting mis-matched files", then I believe the following may work:
git fetch --all
git reset --hard origin/master
Or if you're on a different branch:
git reset --hard origin/branchname
The git fetch re-downloads the latest from remote without a merge or rebase (which would be done if you were to git pull).
The git reset will reset the master branch to whataver was just fetched. The --hard option changes all the files in your working tree to match the files in origin/master (or whatever branch you specify).
NOTE: This overwrites local files. Make sure to stash any local changes, as this will overwrite anything that hasn't yet been pushed. Files that are not in the repo will be left untouched, but anything that is in the repo will be overwritten with whatever is fetched, and local (unpushed) commits will be lost.
I would go for grep + xargs + sed
grep -rlI "\r\n" * | xargs -I{} sed -i.bak -e 's/\r//g' {}
grep will list non binary file that have \r\n and sed will remove the \r
I didn't try, so it may need a bit of tweeking!
I would feel much more comfortable using git clean if I knew I could undo the deletion in case something goes wrong.
Does it support Recycle Bin in any way, shape or form? If no, are there any workarounds that anyone knows of, such as an external tool using git clean -n to print out the files, and then moving them to Recycle Bin?
No,
unfortunately!! git doesn't have this privilege. Whatever gone is gone!!
git clean -fdxn
Will do a dry run, and show you what files would be deleted if you ran
And one more thing, that if you have added files and somehow deleted those files. In this case, you can restore these files by using below command:
'git fsck --lost-found'
It's worth a try, but don't get your hopes up too much.
Put recycle.exe into your %PATH%
Run git config --global alias.recycle !git_recycle.sh
Put git_recycle.sh in your %PATH%:
#!/bin/bash
cd ${GIT_PREFIX:-.}
git clean -xdfn "$#" | sed 's/Would remove //' | xargs -d \\n --no-run-if-empty recycle
No.
If you're worried about losing files, you a "dry run" is really the only viable option:
git clean -n
or equivalently
git clean --dry-run
Git has no knowledge of the underlying desktop environment, and probably never will.
Git GUIs are capable of showing you these files, but why on earth would you want to move them to the recycle bin in the first place? Just think about what you're doing before removing files.
Alternatively, add the files to a seperate branch in your repository, although that probably defeats the purpose of deleting them in the first place.
If you use Git Bash on Windows the quickest way is probably
explorer .
This will open the Explorer in the cwd. Find the file, hit DEL to delete and close the window with CTRL+W.
There's not even a confirmation prompt if depending on your explorer settings.
I wanted to rename a folder from "Frameworks" to "frameworks", but git would not let me add the new lowercase name. I guess it treats filenames case insensitive, does it?
A git add frameworks/ -f didn't help
You can try:
"git mv -f foo.txt Foo.txt" (note: this is no longer needed since git 2.0.1)
to set ignorecase to false in the config file.
But the issue of case (on Windows for instance) is described in the msysgit issue 228 (again: this should now -- June 2014 -- work with git 2.0.1)
there is always an option to set ignorecase to false in the config file that will force Unix like Git semantics on top of NTFS.
Git supports this behavior but it is not the default - from NTFS point of view a.txt
and A.txt are the same thing - so Git tries to preserve that as most users would expect
As a better workaround, you can
git mv foo.txt foo.txt.tmp && git mv foo.txt.tmp Foo.txt
, which also changes the case of the file as stored on disk.
This blog post illustrates the same issue on MacOs during a rebase:
The default on Mac OS X file systems is that they are case-insensitive. FFFFFF.gif is the same as ffffff.gif.
If you delete the file in question, just from the file system, not from the Git index, mind you, you can merge the branch in question, and have it restore the file as if nothing happened.
The steps are pretty simple:
$ rm file/in/question.gif
$ git merge trunk
Anyhow, remember what git mv stands for:
mv oldname newname
git add newname
git rm oldname
, so if newname and oldname clash, you need to make them different (even if it is only for a short period of time), hence the git mv foo.txt foo.txt.tmp && git mv foo.txt.tmp Foo.txt
If you happen to host on Github, you can use the rename function on their website. Had to change the casing for 5 files and found it worked really well.
I was having a similar problem and couldn't get a new folder name (different case) to change on remote repos. I found that the easiest solution was just to move the file out of the repo and commit. Triggering a delete action. Then re-add and when I added, it came in with the proper case.
I have updated cvs a few times and want to get one of the older versions, is it possible to get different versions of the same file? Or should it be only the latest checked in version?
Switch to a certain revision number: cvs update -r 1.42 myfile
Switch to a certain tag: cvs update -r mytag
Switch to a certain date: cvs update -D 'last friday 12:00 PST'
If you haven't already checked out some version, you can pass -r or -D directly to cvs checkout.
These all switch your working copy to the revision or date you specified (this is called a “sticky tag”). To go back to the head revision, issue cvs update -A.
You can also retrieve a specific revision into a different file with the -p option: cvs update -p -r 1.42 myfile >myfile-1.42. This doesn't touch your working copy of myfile.
Yes - in the lingo of CVS it sounds like you have committed several versions (to the repository) and now you want to get one of the previous revs back... so you will be updating your sandbox. If it's a particularly interesting rev, you might want to TAG it so you can find it again without having to use the rev number.
In either case you might run a cvs command like so:
cvs update -r 1.14 foo.java
cvs update -r spiffy_tag foo.java
But know that if you run either of those, you will have a "sticky tag" in your local copy and cannot commit back from there. (Run "cvs status foo.java" to see the sticky)... so if you want to work on that rev and tune it up, you might want to create a branch first... then if you run:
cvs update -r my-branch foo.java
you will be able to commit changes back to the repo.