Cannot add SQL file to Git repository? - sql

I need to add a SQL file to my Git repository. For some reason Tower or Git on the command line does not see that I've added a new file whenever it ends in .sql.
I've tried creating an empty .sql and removed everything in .gitignore, but it still doesn't see it.
Any ideas?

You probably have a global gitignore set up. This page on GitHub https://help.github.com/articles/ignoring-files recommends that SQL files are included in a global git ignore.
Follow instruction on that page to set your own global rules.

Related

Create repository in non-empty remote folder

It's been 14 years since I last worked with svn and appearently I have forgotten everything...
I have an existing web-project, consisting of a bunch of php, html, js and other files in a directory tree on a V-Server. Now I want to take these folders under version control and create a copy on my local machine using svn. So I installed subversion according to these instructions: https://www.linuxcloudvps.com/blog/how-to-install-svn-server-on-debian-9/
Using the already-present apache2.
But now I kinda hit a roadblock. If I try svnadmin create on the existing folder, it tells me that is is not empty and does nothing really. All the questions and answers I find here and elsewhere are either
a) focussing on an already existing folder on the local machine
b) assuming more prior knowledge than I have right now aka I don't understand them.
Is there a step-by-step guide for dummies anywhere on how to do this? Or can anyone tell me in laymans terms how to do this?
I can't believe this case never comes up or that it is really very complicated.
At the risk of failing to understand your exact needs, I think you can proceed as follows. I'll use this terms:
Code: it's the unversioned directory at V-Server where you currently have the bunch of php, html, js and other files
Repository: it's the first "special" directory you need to create in order to store your Subversion history and potentially share it with others. There must be one and there can only be one.
Working copy: it's the second "special" directory you need to create in order to work with your php, html, js... files once they are versioned and it'll be linked to a given path and revision of your repository. At a given time there can be zero, one or many of them.
Your code can become a working copy or not, that's up to you, but it can never become a repository:
$ svnadmin create /path/to/code
svnadmin: E200011: Repository creation failed
svnadmin: E200011: Could not create top-level directory
svnadmin: E200011: '/path/to/code' exists and is non-empty
Your repository requires an empty folder but it can be located anywhere you like, as long as you have access to it from the machine you're going to use in your daily work. Access means it's located in your PC (thus you use the file: protocol) or it's reachable through a server you've installed and configured (svn:, http: or https:).
$ svnadmin create /path/to/repo
$ 😎
Your working copies can be created wherever you need to work with your IDE. It can be an empty directory (the usual scenario) or a non-empty one. The checkout command retrieves your files from the repo and puts them in the working copy so, at a later stage, you're able to run a commit command to submit your new and changed files to the repository. As you can figure out it isn't a good idea to create a working copy in random directories because incoming files will mix with existing files. There's however a special situation when it can make sense: when the repository location is new and is still empty. In that case you can choose between two approaches:
If you want code to become a working copy, you can check out right into in and then make an initial commit to upload all files:
$ svn checkout file://path/to/repo /path/to/code
Checked out revision 0.
$ svn add /path/to/code --force
A code/index.php
$ svn commit /path/to/code -m "Import existing codebase"
$ Adding /path/to/code/index.php
$ Transmitting file data .done
$ Committing transaction...
$ Committed revision 1.
If you don't care about code once it's stored in the repository or you want your working copy elsewhere, you can import your files from code and create a working copy in a fresh directory:
$ svn import /path/to/code file://path/to/repo -m "Import existing codebase"
Adding code/index.php
Committing transaction...
Committed revision 1.
$ svn checkout file://path/to/repo fresh
A fresh/index.php
Checked out revision 1.

Git submodule is ignored

When I try to add a submodule via
git submodule add git#domian:repo.git contact
I get the following message:
The following path is ignored by one of your .gitignore files:
contact
Use -f if you really want to add it.
Here is my .gitignore:
# Ignore everything
*
# But not these files:
!*.py
!*.md
!*.gitignore
!.gitmodules
!contact/
It is resolved by using the suggested -f option, but I am curious why the !contact/ entry in .gitignore does not alleviate the problem.
A submodule is composed of a gitlink (a special entry 160000 in the Git repository index), and a remote URL+path in the .gitmodules.
So excluding !contact/ would still ignore the gitlink "contact" (which is not a folder contact/, but a special "file")
This would work better, and allow the git submodule add to proceed:
!contact
And if any other cause would still block the git submodule add, the next Git 2.26 (Q1 2020) will provide a more helpful error message.
I don't hit that error in your particular case (I have git version 2.21.0.windows.1).
I do hit that error when trying to add a submodule outside the parent repository, though (which apparently isn't supported):
$ git submodule add https://github.com/user/repo ../repo
The following path is ignored by one of your .gitignore files:
../repo
Use -f if you really want to add it.
Best guess is it's a bug...so adding !contact/ to your .gitignore doesn't fix it because it's not actually the .gitignore causing the problem.
What git version do you have? You can download the source code for your particular version, search for the error message (e.g. here it is in v2.21), and trace through the code to figure out what actually goes wrong.

IntelliJ: How to create a local Java project copy for backup?

I'm new to JavaFX 8 and the IntelliJ IDE. I have a JavaFX8 project that works but not as I would like. I'd like to try another approach but the substantial changes may not work. I don't want to loose code I have working.
To save code I have working, I've been creating a new project and then locally copying all the folders(.idea, out, src) and files except .iml, of the working project into the appropriate folders in the new project with the newly generated .iml.
This always seems to work but is it proper procedure?
I'm not on a team of developers and have yet to learn Git/GitHub.
Please advise. Thanks.
Maybe you should learn how to use a Version Control System like Git, then you can create a project repository and have different branches for things you want to try out. Keeping the working code in your master branch will prevent you loosing your working code. Also, when using a vcs you can always revert to versions of your code that have been working. The IntelliJ Idea IDE has perfect support for working with all different types of version control systems. If you don't want to learn any forms of vcs then there is no other way to "backup" your working code.
Is it proper procedure? It's probably not how most people would go about achieving what you want to achieve but it's certainly workable. If you wanted to stick with that for simplicity now, I'd copy the whole directory structure, delete the .idea and .iml files, and then create a new project in IntelliJ on that clean copy: IntelliJ will automatically set up folder structure based on the existing source without you having to go through any additional manual setup.
If you're willing to experiment with the git route, to achieve the basics of what you want to achieve is not very complicated and I've written a small quick-start below. IntelliJ offers very good support for Git, and once your repository is created you can do everything you need from the IDE. I'm going to assume you're working on Windows, although the steps shouldn't be too far removed on other platforms.
Install Git
You can download and install Git from https://git-scm.com/download/win, which will install a command shell called Git Bash.
One-off setup for your project
Open up git bash and go into the directory containing your source. Rather than seeing separate drives as Windows does, Git Bash assumes there is a logical 'root' directory under which all your files are accessible. Your C: drive will be /c. To move around you can use cd to change directory (using / instead of ) and ls to list files instead of using dir.
Assuming your source code is in C:\projects\myproject:
cd /c/projects/myproject
git init
The second line above creates a git repository in that directory. This doesn't affect your code, it just creates a folder called .git that contains all of the book-keeping information.
You don't want to have every file under version control - in particular you don't want your build outputs. You need to set up a file in your project directory called .gitignore which tells git which files and directories should be ignored. As a starting point you can copy https://github.com/github/gitignore/blob/master/Java.gitignore and rename the file to .gitignore
Basic Commands and committing your initial version
There are a small number of basic commands:
git status
Running git status will tell you which files have been modified, which are not under version control, and which files have been added to the staging area to be committed next time.
git add path/to/file
This adds a file to the staging area waiting to be committed. You can add multiple files to the staging area before committing them in one go.
git commit -m "description of your change"
This commits all of the staged files as a new version, which the specified commit message.
If you go into your project directory, do a git status and check through the list to make sure there's nothing you don't want to have under version control, then you can do git add . to add everything to the staging area and git commit -m "Check in initial version of the source code" to commit it to the repository.
After you've committed, you can run
git log
To see a history of all of the changes. IntelliJ has a view that will show you the same thing.
Creating an experimental branch
This is where git shines; if you want to try something experimental you can create a branch of your project while allowing git to preserve the original version.
git checkout -b experiment1
Will create and switch to a branch called experiment1. You can delete, rename, move, rewrite and develop whatever you like on this branch. The changes you commit will be independent of your original working version.
You can switch back to your original version (preserving all of the changes you've committed on that branch) using:
git checkout master
Where master is just the name of the default branch created when you ran git init. The experimental version will still be there and can be switched to again using git checkout experiment1 or from IntelliJ using the branch selection in the bottom right corner of the status bar.
If you decide that the changes you've made in experiment1 are to become your new "good" version, you can merge them back into the master branch and repeat the cycle from there.

How to stop jDeveloper from regenerating .jpr files

I use GIT and what I constantly see is that git shows that entire SomeModel.jpr contents were removed and replaced with the same contents. File stays the same. Well sometimes something changes and you miss it in whole soup.
Build JDEVADF_11.1.2.3.0_GENERIC_120914.0223.6276.1
This is probably a problem with your git configuration. I saw this to when I worked on a Windows system and git is configured to use only line feed as line terminator. Check your git settings and play with the line terminator settings (auto or leave as is).

How to control file permissions in CVS repository?

Currently some users have their umask set in ways which result in execute permission on regular files, which I'd like to avoid.
Is there a way to force all files checked in to only be read with some exceptions?
What is the recommended way to handle this in CVS?
Cvs command option watch is also preventing file permissions to be restored. If watched, when file is checked out it will be read-only. From cvs man pages:
$ cvs watch --help_options
Usage: cvs watch {on|off|add|remove} [-lR] [-a <action>]... [<path>]...
on/off: turn on/off read-only checkouts of files
So, use cvs watch off filename to remove checkout from repository making it read only every time.
I am not sure if this is the best solution, but I would probably do something with the cvswrappers file in CVSROOT directory of the repo, using commitinfo, commitcheck and commit_prep.pl. If you don't have commit_prep.pl, you can use something like this one:
http://opensource.apple.com/source/cvs/cvs-29/cvs/contrib/commit_prep.pl
There are quite a few examples on the web, so just search for those commit* files if you don't already have those in your repo.
Note that, as this post suggests, the permission is really set only during the first commit of a file, after that, you'd need to "manually" modify the permission on the repository itself.
How do I add execute permission to a file in CVS after it's already been checked in?
In commit_prep.pl, you can clear the exec permission using chmod ugo-x , before the file is committed for the first time.
This solution assumes you are using linux.