I'm trying to convert an existing SVN repository to GIT using git-svn clone but versioned files with special characters in the filename like "ö" are showing as "ö" after migration. Obviously, git-svn saves the filenames "as is" - I assume that SVN stores filenames in UTF-8 (as done with the logs), but my Windows uses windows-1252 encoding.
Is it possible to force git-svn to change the filename encoding? Didn't find anything in the manuals.
Unfortunately there seems to be a issue with msysgit: http://code.google.com/p/msysgit/issues/detail?id=80
Although, git in Cygwin doesn't have this issue.
Related
Intellij: how to keep existing end-of-line styles when saving?
We have a file with mixed EOL styles (from hex viewer, how happened?)
0A \n
0D 0A \r\n
When saving the existing file with one-line change, many lines are changed on disk (from svn diff).
svn diff
Noted that some lines are added (no deletions). svn diff has a bug.
svn stores file diff(s) in repository. If svn diff has a bug, will the repository be actually corrupted?
svn diff -x "-w --ignore-eol-style"
gave me correct result.
My question is that: how to keep existing EOL styles (mixed in the file) when saving and prevent generating invisible diffs?
Here is a related issue on YouTrack:
https://youtrack.jetbrains.com/issue/IDEA-171699/Keep-differents-lines-separators-in-the-file
Feel free to watch it in order to be notified once it has updates. See this article if you are not familiar with YouTrack.
I'm tracking a file (*.sra) in libgit2, and after making a change libgit2 identified the file as binary and wouldn't diff it for me. I discovered that the file was encoded in UTF-16.
Can libgit2 be taught to recognize that this file is text and handle it appropriately?
I'm using git, it can set 'working-tree-encoding' attribute to merge it,when conflict .
From what I can tell from reading gitattributes, libgit2 does not support working-tree-encoding:
Alternative Git implementations (e.g. JGit or libgit2) and older Git versions (as of March 2018) do not support the working-tree-encoding attribute. If you decide to use the working-tree-encoding attribute in your repository, then it is strongly recommended to ensure that all clients working with the repository support it.
I have am trying to unzip a file via SSH, I require a case sensitive unzip.
My server is using Debian Unzip 6.
It shouldn't be doing this, but it is converting all my file names to lower case, causing my Joomla site to buckle.
There are far too many files to rename manually or to FTP if I want to finish in my lifetime.
I have a zip called bv2.zip placed in the directory I want to extract in...
I have cd'd into my directory and simply issued: unzip bv2.zip .... filenames all go to lowercase...
I have also tried absolute paths to no avail, the UNZIP help and manual states that case sensitivity is enabled by default with this version, but obviously not...
Any ideas??
what does unzip -v file.zip show? The docs say
by default unzip lists and
extracts such filenames exactly as they're stored (excepting
truncation, conversion of unsupported characters, etc.)
It'd be worth checking how they are stored. If the creating zip program is storing them all as lowercase, then that's where you need to look for a way to actually store unaltered filenames.
Finally, just to be sure, check that there's no alias or environment variable on your Debian server forcing use of the -L option. Look at output of the following commands, run on the Debian server's terminal:
alias
(there should be no weird alias for unzip)
echo $UNZIP
(Any flags contained in this environment variable will be used by unzip as if they'd been added to the command invocation).
I was facing same problem in my 1&1 hosting. I have solved it by defining a new alias, by typing:
alias unzip='unzip'
The problem was unzip -L was aliased.
Now I have unzipped prestashop backup and it works like a charm
Regards
Are you sure your .zip file didn't have all lowercase names to begin with? Maybe whatever program you used to create the zip file is converting the names to lowercase.
The "-L" (convert all filenames to lowercase) and "U" (convert all filenames to upper case) options control this behavior:
http://www.mkssoftware.com/docs/man1/unzip.1.asp
This would ONLY be an issue if the files in the .zip were from a case-insensitive filesystem (like MS-DOS or VAX/VMS). It should not be an issue if the files were .zipped up on ANY contemporary filesystem (Unix, MacOS, Windows 95 or higher) with ANY contemporary version of Zip or WinZip.
Soooo ......
Is there any chance these are DOS files?
Or did you use a DOS version of PKZip?
Or were the files simply lower case to begin with?
If I tell git to ignore x amount of files and never add them to the repository, will those files also make it into the svn:ignore property? And if so, how can I keep .gitignore local to only my local git repository?
EDIT Sorry about the duplicate, I searched on here and couldn't find anything on it.
No, git will not do anything with svn:ignore.
From the documentation:
We ignore all SVN properties except svn:executable. Any unhandled properties are logged to $GIT_DIR/svn//unhandled.log
Also this other StackOverflow question is very similar.
If you want the .gitignore local to your repo, don't commit it.
Similar question:
How can you indicate files to ignore in svn when using git and the git-svn bridge
git-svn does neither .gitignore — svn:ignore, nor git attributes — svn properties conversion.
You may consider using SubGit instead. It does properly handle ignore, properties, merge-tracking data, etc. Among other things it works on a server-side, so one can use any Git client available to send changes to Subversion repository.
See documentation and comparison with git-svn.
I've started using git-svn for an SVN-based project, so that I can make local commits.
However, the SVN repository contains a lot of directories that I don't need to work with. When I solely used SVN, I was able to partly check-out stuff with:
svn co <repos-url> --depth empty
and then update the needed directories:
svn up <repos-dir>/<subdir>
As far as I've understood, partly checking out a project isn't an option with Git, so I'm looking for alternative way of saving some space. Any suggestions?
Edit: what I am thinking myself is something in the lines of creating a branch thatonly contains the files I need. I'd then want to be able to push the changes to these files without pushing any removal of the files I don't need. But I am not too deply into the way Git works to figure out if this is possible?
Are the extra directories really that big? One advantage of Git is that you do most of your work from your local harddrive (you commit to your own branch, not to the server) so it's fast even when there are many files.