I'm developing an (Qt) application which should run under Windows and Linux. So, I want to be able to develop under Windows and Linux, too.
Therefore I have stored my project (as git repo) on a NTFS partition which I mount under Linux (Ubuntu 13.10). To avoid the rights problem of the compiled executable I set the shadow build directory to my home folder under Linux.
This approach work quit good so far. But there are some effects that make me worry: If I stage some changed files (with smartgit), smartgit doesn't reflect that I have stage them. They are still displayed as unstaged
Similar thing when commiting: After the commit, the commited changes are still display as if they where not commit. But in the log I can see they are commited. Closing an reopen the repo "solves" this issues or is a workaround at least.
But I have concerns that I break my repo using it on a NTFS partition under Linux. Or is there no risk that my repo is getting corrupted one day using it that way?
This answer has been given by Fco P. on the askubuntu question mirror. This happens because Windows and Linux deal with file permissions differently. Use
git config core.filemode false
to disable git tracking file permissions and solve this issue.
Related
I have my main project hosted in GitHub. Everything is good and works.
Now I'm trying to create a Solaris port. I make myself an OpenSolaris VM installed Solaris Studio as compiler/IDE and built.
Everything works fine.
Now what I'm thinking is that since Solaris Studio is completely different IDE/compiler from MSVC/Anjuta/Xcode, I should create a different repository (NOT A FORK) and push Solaris stuff there.
The only problem is - code synchronization.
If I make the change in my main repository and push it to remote, I want my second repository to be updated as well with the changes to the *.cpp/.h files.
Is there exist some kind of hook to do that?
Or maybe I'm better off with creating a fork? But then changes to the build system will be overwritten.
Please advise.
This is the current structure for the main project:
Project folder -> main app folder (*.cpp, *.h, *.sln, Makefile.am/Makefile.in, xcodeproj folder)
|
----> library 1 folder (*.cpp, *.h, *.sln, Makefile.am/Makefile.in, xcodeproj folder)
Or maybe I'm better off with creating a fork? But then changes to the build system will be overwritten.
I wouldn't even bother with a fork.
I would just make sure the build system is isolated in its own folder, which allows you to have in one repository two build configuration folders:
one for a default environment
one dedicated to a Solaris environment
That way, you can go on contributing to the code, from either one of those environments, without having to deal with any synchronization issue.
I have a PC where I have both a Linux and a windows installation. I use a cloud service so I have access to my important files in both places, and they are synced.
Say I created a git repository, and pushed it to GitHub on windows. Now I suddenly feel the need to switch to my Linux installation to do some stuff. My cloud service does not sync the .git folder, since it's hidden in default by windows. (Would it lead to problems between os'es if i would sync it?). Therefore, Even though I have the same project (with exactly the same files) as on windows, Linux does not automatically recognize the VCS settings of the current project.
I found a somewhat dirty workaround, on Linux I
Initialize an empty rep: git init
Add a remote branch:git remote add Project_name https://github.com/Psychotechnopath/Project_name.git
Fetch the contents of the remote branch git fetch --all
Reset the head onto the remote master branch git reset --hard Project_name/master
Is this the best way to do it (e.g. respecting the git workflow), or are there more elegant ways?
I have mostly-successfully done this on the same filesystem; in my case I mounted the ntfs filesystem from Linux. Two things you have to be careful of:
don't make filenames that are the same on a case-insensitive file system but different on a case-sensitive one
pay special attention to your line endings, you may need to do some work in .gitattributes here
push often in case you find a git bug
If you don't mind having the world's slowest Linux system, you can also just run Linux under Windows via Window Services for Linux, WSL. (Not WSL 2, that's containers). In that case, you can access your windows repo from linux via the /mnt/c/ filesystem.
I have been working on some code on my mac and want to start working on it on my linux desktop. The project is managed under git. Before the copy, I made sure everything was committed. I then copied the folder containing everything from my mac onto a usb drive, then copied the folder from the usb drive to the linux box. After the copy, everything looks like it is where it should be, but if I do a git status all the files show up as modified. I'm guessing this is because the timestamps on the files have changed. Is their a way to retain the old timestamps so the files dont appear modified? Or to tell git to not worry about changes since the last commit? I'd prefer not to do a git commit -a immediately after the transfer as I dont really want the move of boxes in my git history.
The easiest thing to do is to use clone (rather than copying worktrees around) to share repos.
If you cannot directly clone / fetch / push / pull between the two machines, then you could create a "bundle file" and copy that, instead of copying the actual repo. (See the git bundle` docs or search for existing questions/answers about how to share a repo in this way.)
When crossing operating systems, there are still potential issues. e.g. You'd want to think about how you want to handle line endings if crossing between OS's that have different default line ending rules - but mac and linux shouldn't have that issue anyway.
I am wondering what happens in SVN when a file is updated directly instead of using SVN? The main reason I am asking is that there was a problem updating the SVN on my machine (windows) when the server (linux) had 2 names that were the same, but different case. I resolved this on the server, but didn't do it through SVN since it won't update correct, but I still get the issue. Do I need to run some kind of command to update it?
Thanks.
EDIT:
I deleted the comflicting file in the working direcotry and wanted to know if doing things directory in the working directory get tracked at all or what needs to be done to resync.
When SVN gets blocked because the repository is more "up to date" than the local checkout, one brain dead foolproof solution is:
Move (or remove) the files that are causing the conflict at the command line (don't use SVN tools to do this, and don't use the GUI if you have tortoise installed).
svn update the repository, which will restore the current copy of the files from the subversion server.
Decide what to do with your cached copies of the old files. Either manually merge them back into the repository, discard them, or remake the changes in the new svn managed files (depending on your needs).
Note that if you move the files into a directory using tortoise, make sure that you move it into a directory that's not associated with ANY SVN project. It's not fun trying to undo the helpful changes tortoise does in thinking your wanting a SVN move to accompany the file system move.
There is no need to run any special commands. If you updated the sources, the next time you will run svn update subversion will seamlessly merge the changes and you will get an uptodate working copy.
If you changed some files, they will appear modified or conflicted depending on the changes made by you and other users.
This is maybe unusual so let me set the scene:
We have an SVN repo containing our project history - an embedded system based on Linux. The SVN repo contains Linux kernel, U-Boot, busybox etc. sources and all our in-house apps, filesystem and such.
The Linux kernel we have is old and crusty and I am working on porting to the mainline, which is under active development for our platform(s). I am doing the kernel-side work under git and trading patches with "The Community".
I could get things working and take a snapshot of the kernel sources and dump it into SVN, but I'd like to keep the ability to get updates, have local branches and manage patches with git. I could keep two copies of the kernel, one managed by each SCM, but that would be a bit messy. There are also risks of developing and testing using kernel sources managed under git, and forgetting to put those changes into SVN resulting in broken SVN versions where the non-kernel sources are out of sync.
Migrating the entire project to git isn't an option. Managing just the kernel source with git and having a bunch of glue scripts and stored hashes in SVN is possible but it's nicer to have a unified history / diffing ability from SVN for the whole project.
What I'm considering is trying to manage the kernel sources under both SVN and git simultaneously, in the same directory.
As a kernel dev I'd mostly use git and do an SVN commit for internal use when things look good. For other internal users they would be able to get the entire, consistent sources with one SVN checkout, see a unified history, and they could make changes to the kernel sources under SVN. Later I or another git-using person can SVN update to those changes and commit them to git as appropriate.
Some funning around getting git to ignore .svn files and vice versa will have to be done. Also I'm not quite sure how one would take a plain SVN checkout and tell git to start managing the kernel subtree as well, but I'm sure git has some obscure swiss-army-knife options to do it.
So that's my idea du jour. It means most co-workers don't have to worry about git, and we can quietly ignore git and fork away later as needed.
The question here really is, has anyone done something like this, how did it work out, or what alternate solutions did you come up with?
I've done this regularly, and it works great.
The only major thing I needed to do was add the .git folder to the subversion ignore list, and the .svn/ folders to the .gitignore file.