Note: I am relatively new to Git / GitHub. I understand my way around, but I am confused with this corner case
Background
I created an IntelliJ color scheme git repo and pushed it to github online. The directory structure was ad hoc and made up of only output. This was actually fine and worked well.
I noticed that people would not get updates from me this way, and decided to create a JetBrain Repo plugin. This also works well; however, my github location and plugin location on my PC are different.
Issue
I looked over Change Git repository directory location. but was not sure if this fit my usecase.
Since my github is just output files and my plugin files are all input files, can I simply just copy over my .git files (along with README files and such) , and expect it to work correctly?
The linked SO question seems to relate to JUST moving the same directory structure and files over to another location. I am dealing with different directory structure, different files, and directory location; however, it IS the same project.
Update
Before, my workflow was:
Modify Color Scheme in IDE
Export settings from IntelliJ
Place in \Documents\GitHub\ChroMATERIAL
Windows GitHub Client: \Documents\GitHub\ChroMATERIAL merge
GitHub
Now it is
Modify Color Scheme in IDE
Run project and autogenerate output in \IdeaProjects\ChroMATERIAL
Place output in \Documents\GitHub\ChroMATERIAL
Windows GitHub Client: \Documents\GitHub\ChroMATERIAL merge
GitHub
What I want
Modify Color Scheme in IDE
Run project in \IdeaProjects\ChroMATERIAL
Windows GitHub Client: \IdeaProjects\ChroMATERIAL merge
GitHub
I'm assuming that the generated output matches the structure you need for your Github repository. If so you could easily move your .git folder from
\Documents\Github\ChroMATERIAL
to
\IdeaProjects\ChroMATERIAL
What you should check:
Will the generated output directory be cleared if you clean the project into Intellij? If so you should stick to your current workflow since you could easily delete your local copy.
The other thing which could be a problem is the Github Desktop Client since I don't know how it behaves nor how or if it must be configured in a special way to reflect your changes. (if you just call it from the inside of the repository it should not be a problem at all)
For your explanation:
Git uses relative paths. So it is irrelevant where the repository lives inside your system. The important part is the structure inside the repository since this will be cloned to the remote repository.
I recommend that you copy your .git folder rather than move it. If something goes wrong you can easily revert.
Related
My project previously was in the Git source control (cloudforge.com). Now I want to exchange it to SVN source control. (Why not, my team members are not familiar/feel-comfort in Git). But when I want to checkout it already shows that it is yet in the Git source control.
I can't delete my project from git. It shows this error
But I have configured this project into svn by other Mac mini and able to checkout and commit.
My Question:
Why I can't checkout this project from this Mac as I can do it from other Mac?
OR
How can I delete my project from the first screenshot? Because there I can't find any option to delete.
Are you wanting to import your complete git repository into a Subversion repository, including history and log information? Or are you simply wanting to take a snapshot of your current project and make a Subversion repo out of it?
If you want to import the full history, then this may or may not be possible. Git supports branching/merging schemes that Subversion can't handle. It's only possible for fairly simple, linear project histories. See this other question for more details and options.
If you only want to move your current code snapshot into a different repository type, then the process should be relatively straightforward. All of git's metadata is stored in a normally-hidden folder in the root of your working copy named .git. Most IDE's flag a project as being connected to a git repository based on whether this folder is present and whether it has the expected contents. I'm not 100% certain about xcode, but here's what I typically do with other IDEs:
Make a copy of the working copy directory
Delete the hidden .git directory from the copy (plus any metadata files created by your IDE)
Import the copy into the IDE as a new project
At this point, your working copy will have no metadata and the IDE shouldn't associate it with any particular repository or version control system. You should now be able to import it into a Subversion repository using the same process that you would for a new project.
I've got a repository. When downloading this repo, instead of cloning it, it seems that I accidentally simply downloaded the source instead. Now I've come to commit my changes and noticed that the folder I'm working in is, in fact, not a repository at all but just some random folder.
I've found various ways of initializing a new repo from existing contents. But how can I initialize an existing repo from my existing contents? I added the remote repo as a remote in the GitHub for Windows client, but it doesn't seem to have had the desired effect.
Just to be clear, the intended outcome is as if I had cloned it properly in the first place- history, diffs of the changes I've made from the latest in the repo, the works.
I've tried some solutions involving git clone, like "Clone into a new folder and then just copy and paste the .git folder". However, this seems to have the effect that Git thinks that I deleted and re-added every line of every file in the repository instead of the changes I really made.
From what we talked about in the comments, you should copy over the actual data to the properly cloned repository as opposed to the .git folder. This way, Git has a chance to pick up the changes without introducing any aberrant or unusual state issues.
Apple has introduced a new project-related type of file in Xcode 5: "xccheckout".
This file is located in the ".xcodeproj/project.xcworkspace/xcshareddata/" directory, and it seems that it is related to the project's version control system.
An example file is here: http://pastebin.com/5EP63iRa
I suppose that this type of file should be ignored under VCS, but I'm not sure.
So here are the questions:
Should "xccheckout" be ignored?
What is its purpose?
You should check in an Xcode 5 .xccheckout file; in general, files in xcshareddata should be committed.
An .xccheckout file contains metadata about what repositories are used in a workspace. For a single project in a single repository that doesn't make much difference. But if you're using a workspace that has multiple projects from different repositories, the presence of an .xccheckout file in the workspace allows Xcode to know what all of the components that make up a workspace are and where to get them.
The *.xccheckout file contains VCS metadata, and should therefore not be checked into the VCS.
On the other hand: checking in this file will probably not create merge difficulties or other problems.
If you want to ignore this file (which I recommend) you should add this line to your project's .gitignore:
*.xccheckout
Abizern's solution will not work for projects inside a workspace. Because, when you use a workspace, the path to the *.xccheckout file will be: <workspace-name>.xcworkspace/xcshareddata/<workspace-name>.xcchekout. And it actually ignores more than you would want.
Edit:
This file exists for managing Xcode's knowledge of the possibly many VCS systems in your project, see Chris Hanson answer. For > 99% of the projects the .xccheckout file is configuration overkill.
It depends. The file contains references to the remote repository you are using. If you are using a centralized VCS such as Perforce or Subversion, everyone's remote repository will be the same and so you can and should check the file in.
If you are using a distributed VCS such as Mercurial or git, but using it as though it were a CVCS (in other words, everyone cloned from a shared repository directly to their personal workspace on their machine) then you still might want to check it in.
However, if you are using a DVCS with everyone having their own remote clone, for example using GitHub in it's standard usage pattern, you DO NOT want to check this file in. If you did then your Pull Requests will be asking for your repository settings to get copied into everyone else's xccheckout file, but your repository settings will be different from everyone else's because you are all using different remote repositories.
Yes, the Project.xccheckout file should be committed to your repository. Xcode uses this file to tell others who open the workspace the entire list of source control repositories used by the workspace and the location of the working copy relative to the workspace, whether those repositories are Git, SVN, or both.
When you open the workspace, Xcode uses the Project.xccheckout file to notify the user that there are other repositories forming part of the workspace, and asks which should be checked out. When checking out additional repositories, Xcode places the working copies in the same workspace-relative folder structure as they were when the Project.xccheckout file was generated.
As Chris Hanson said, it probably doesn't matter for a single-repository, one-project workspace, but for more complex affairs it'll be very handy indeed.
You can find out more about this in the WWDC 2013 session video Understanding Source Control in Xcode; the relevant portion starts at about 15 minutes.
This is what I have in my .gitignore for Xcode.
#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/
It keeps anything that relates to the local state of the way the projects looks for me out of the repository.
The xccheckout file is under here so it is not tracked on my system by default.
Xcode has gotten better and separating out what needs to be shared and what needs to be kept locally. For example; these lines will ignore the default build schemes, which is fine because you can mark specific build schemes as shared, and they are put in a directory that is not ignored.
Breakpoints are ignored, but you can mark specific breakpoints as being shared across projects and they are also placed in a directory that is not ignored.
I want to use Git for some personal projects I work on. I'm new to git and don't know how to start...
Should I first create the project (say an ASP.NET MVC application) in Visual Studio and then turn the folder that is created into a repository, or should I create a repository first and then create the project inside that folder?
Also, are there any best-practises for how to structure the folders inside the "repository root folder"?
These are my two questions right now, but any pointers to articles etc for best-practises using Git and Visual Studio are welcome!
Git repositories are so lightweight that it doesn't really matter whether you create the project and then create the repo or create the repo and add the folders. You will anyway be doing a git add and git commit after the folders have been created.
But, for me, I usually create the project from VS and restructure the folders so that at the root there is the src folder and the .sln and project files are within the src folder. VS would typically create the root folder with the project name which I rename to src. Then I create the repo, add the standard .gitignore and .gitattributes and commit the repo.
See my preferred structure here: https://github.com/manojlds/cmd
Of course, you can have whatever structure you want.
For using in VS you can use Git extensions. It integrates into the IDE and provides nice GUI over the basic Git operations.
As for the folder structure, it depends so much on the project, so no answer can be given here. There's no better practice than organizing based on the way you work!
As for the moment of repo creation, just create it as early as possible, so I'd say first create it and then add your project.
Organize your files and folders however makes since to your project and workflow, git doesn't care how the files are organized.
Since Visual Studio complains when I try to create a project in an existing folder, I follow the following steps.
Create a bare remote repository.
Clone empty repository locally.
add .gitignore, etc. and make initial commit.
Create VS project in a different folder.
Then I do one of the following.
copy the files from the .git repository into the VS solution folder -- which changes the location of the local repo.
close VS, copy solution files to local repository and then reopen VS.
I really should take the time to automate it, but I spend more time working on existing projects than starting anew so it hasn't been much of an annoyance yet.
I've tried all the visual git tools, including those that integrate with VS, but always end up using PowerShell instead -- just a matter of preference. Give them a try, they may work well with your workflow.
There is a project that uses CVSNT/WinCVS for Version Control. This is the central repository. Locally checked out folders contain hidden sub-folder called "CVS".
I tried to install CVSNT server locally and use second instance of WinCVS to manage(version control) local temporary changes before committing to the central repository.
But that is not working because when checking out from the second(local) repository it still uses "CVS" sub-folder name for its working files.
Anybody knows if it is possible to configure CVSNT server and/or Client to use different name for this sub-folder? And if yes, how?
So far I'm using TortoiseSVN. It creates folders too, but they called ".svn" so there is no interference. It is integrated in Windows shell, which I don't like.
A sandbox is tied to a given repository (which is regitered in one of the files in the hidden CVS folders). You can't use the same sandbox to commit locally and remote (are you tring to mimic a DVCS? Use one of them if you need them). You can't change the folder name (but changing the CVS source files...), but beware WInCVS use them as well because they contains informations about the files status.
You have two options:
The CVS way: create your own development branch, commit to that, merge with the main branch when your code is ready. Of course the CVS server has to be reachable all the time.
The DIY way: create two sandbox, one from the local repository, one from the remote one, move files between them as you need. This is a more error prone way, IMHO.
Of course you can try to use two different VCS, but you will end up with a lot of headaches then. Better to use Git, Mercurial or the like that do what you need without any special configuration.