I have a situation, where my project consists of many submodules. So, there is a main project and this project has a .gitmodules file and the .gitmodules file has entry to further submodules:
project
-> files-main.txt
-> .gitmodules
-> sub
developer1
-> file-submodule.txt
developer2
-> file-submodule.txt
Now, lets say I am a developer1 and make some changes in the sub/developer1 folder. Ofcourse, after commiting the changes, the changes would be reflected in the main git ( project ) which is including the submodules.
My problem is that even if I set git config submodule.developer1 ignore=all, the project git still registers a change in the submodule. This is evident by the + sign against the submodule. The only benefit by setting ignore=all is that I dont get to see any kind of changes in the submodule when I run git status. But, this is misleading, because, I was expecting the command to ignore all kind of activities in the submodule, not just the reporting part.
+8b17424f3e30807df0dc782be05d041d0fb26f77 sub/developer1 (heads/MySubmoduleBranch)
This is what I did not want. I wanted to just ignore the submodules completely for sometime, so that they dont interfere in the project git. Ofcourse parallely, I wanted to continue commiting in developer1, but just not want to reflect the changes in the main project yet.
Does anyone has the solution the problem?
I would not like any kind of ACL changes for the team, neither a gitlab solution with pre-hooks etc. It would be great to come to a solution locally.
Related
I'm using a .gitignore file that was recommended for use with CodenameOne projects (See the blog post) and have committed my project to GitHub. Now I want to retrieve that project to a new PC and continue working on it but I'm having endless troubles doing it.
Shai shared a "quick trick" workaround which involves creating a new project then copying the relevant files from a clone of the Git into it, but then it's not a proper clone of the github repo that can be worked on and then synced back up to the remote.
So what I'm asking is: what steps (and troubleshooting resouces) would I use to ensure that:
I am storing the right files to the GitHub Repo to enable success
The IntelliJ Project will work with the retrieved files
I can commit changes back to the Repo going forwards.
Sorry, I'm a bit new to juggling GitHub repos and CN1's plugin structure for Idea has me mystified (I tried merging a new project with a directory which has a clone of the GitHub repo and the CN1 plugin is disabled - can't click on it)
I resorted to using the following .gitignore (using Codepoint One with IntelliJ IDEA):
# macOS
.DS_Store
# build artifacts
/build/
/dist/
/lib/impl/
/native/internal_tmp/
/out/
# idea
/.idea/**/workspace.xml
/.idea/**/tasks.xml
*.iws
With this setting, most of the IntelliJ configs are committed, as well as some binaries: CodeNameOneBuildClient.jar, JavaSE.jar, lib/CLDC11.jar, lib/CodenameOne.jar, lib/CodenameOne_SRC.zip.
This is not optimal (the binaries don't really belong in Git and take about 40 MB combined). But this way I can clone the project on a different machine and start working right away. It also doesn't produce Git diffs on every build — but only if the libs are updated.
IntelliJ/IDEA Codename One projects are nearly identical to NetBeans Codename One project with the one major difference being the additional idea directory. Just copy that directory from a working intelliJ project and add it to the gitignore. The project should work.
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.
I'm looking for a way to control versions of my project through IntelliJ. However, I know Git can manage it the best way and I already did started experiencing Git with the help of Madara Uchiha's Git tutorial. I must say it is incredibly useful, but I rather have version control arranged on my harddrive which is constantly backed up.
I decided doing my version control manually and it's pretty slow and annoying. Is there an easier and more efficient way to clone the current project files in another folder?
For example, clone the current project files on another folder named v1.4.2 outside my project structure without relocating my project files, also having them refactored as project on its own so they be runnable whenever.
Set up a local Git repository for the project. It will start with a master branch. Then create a working branch that you make your changes in. You can merge this branch back in to master as you are ready. You can create as many branches as you need and switch between them very quickly. All using the one directory.
If you are new to git you can use something like Sourcetree - (a GUI for Git) it will allow you to manage the repository. It makes it really fast to switch between branches of your repository. It also helps with pushing changes to another location. GitHub, Bitbucket, etc.
For backup, you could always set up the project on Bitbucket. You can create public and private repositories for free. I really recommend setting this part up.
Depending on the environment that you are building on, you could build a shell script / batch script that would copy files to the duplicate location. Without knowing what type of project you are developing in/for it is hard to say what would be the best strategy.
Ideally if your project has a build output you could have the compiler/IntelliJ IDEA place the results into your result folder. You could then copy the results to your Builds/v1.4.2 folder or wherever. Whether you check in the files that are built will depend on your project. You can always exclude files/folders like your ../Builds that you don't want to track via your .gitignore file.
so yeah just wondering if darcs has anything equivalent to git's submodules.
i.e. lets say I have a repo (myapp) and I have a folder in it called mylibrary. mylibrary doesn't really have anything to do with myapp's development, it just has to be included. mylibrary's development happens in it's own repo, but when someone pulls myapp, it'll also pull an up-to-date version of mylibrary. any ideas?
My first thought: Since darcs is simpler than git (i.e., no branches and remotes--instead you just use directories and URLs, and it's your task to manage them), a darcs submodule would not give much more than what you can achieve with standard things like subdirectories or files inside you darcs repo.
If you needed a submodule in order to fix a certain state of the source of the used library, you could perhaps simply put a copy of the library's repo as a subdir and add it to your project's darcs. Compared to git, this would have the disadvantage of bloating the data transfer when someone gets your repo.
If you needed a submodule to tell those who get your repo where to get the updated source of the library (without bloating the size of your repo), you could simply put an URL and an instruction into a README file, or a script, or whatever. Compared to git, the disadvantage is that the state of the library's source as it was when you used it wouldn't be recorded in your commit, so people might get another version of the library, and the compilation wouldn't succeed, and it wouldn't be clear why.
So, the really interesting goal of a submodule could be not just to tell people where to get the library source from (as you write in the question), but to record the state of the subproject that you have actually used for compiling your project, and not to bloat your repo for those who don't want to get the source of the subproject.
Probably, this goal could also be achieved by storing more complex metadata about the state of the subproject, and a more complex hook to get exactly that state (or--by choice--another state) of the subproject. AFAIK from the docs, there is no built-in mechanism for such submodules.
Update (found on the darcs site):
http://darcs.net/Ideas/Subrepositories;
http://darcs.net/Ideas/NestedRepositories.
So, darcs will notice another darcs repo inside your working and it won't touch it. So the first way I've suggested above is shut (if you leave the darcs metadata there).
The second way is like something suggested in one of the section of the latter link. (They suggest an "uglu" script for something like this.)
Another (3rd) idea
Import the patches from the repo you intend to have as a submodule, but first move all files into a subdir. If it were possible just to apply such a moving special patch once and if it was effective for all the patches you import from the repo intended as submodule, but not to the patches you import from a "branch" of the main repo...
...well, it could be a special variant of the pull command (say, import) and of the push command (say, export) that would additionaly translate the paths accordingly.
I don't know of any submodule concept for darcs, which means the usual way to refer to another (shared) repo from a darcs repo would be through symlinks.
Since symlinks aren't supported with darcs, that means you needs to put in place a "posthook sh update-symlinks.sh" hook script to restore those links.
But you could also use add to this hook a check to see first what version of the lined repo is currently loaded, and update that version if needed (provided you have store in one way or another the exact version you need for that shared repo).
That last suggestion is actually close to the implementation of Git submodules or Mercurial subrepos.
I'm coding a framework along with a project which uses this framework. The project is a Bazaar repository, with the framework in a subfolder below the project.
I want to give the framework a Bazaar repository of its own. How do I do it?
You use the split command:
bzr split sub_folder
This creates an independant tree in the subfolder, which you can now export and work on separately.
Use fast-import plugin (http://bazaar-vcs.org/BzrFastImport):
1) Export all your history to the stream:
bzr fast-export BRANCH > full-history.fi
2) Filter the history to produce new stream:
bzr fast-import-filter -i subfolder full-history.fi > subfolder.fi
3) Recreate new branch with subfolder only:
bzr init-repo .
bzr fast-import subfolder.fi
As far as I know, there is not a way to do this easily with bazaar. One possibility is to take the original project, branch it, and then remove everything unrelated to the framework. You can then move the files in the subdir to the main dir. It's quite a chore, but it is possible to preserve the history.
you will end up with something like:
branch project:
.. other files..
framework/a.file
framework/b.file
framework/c.file
branch framework:
a.file
b.file
c.file
As far as I know, "nested" branches are not support by Bazaar yet. Git supports "submodules", which behave similar to Subversion externals.
I have tried doing this with bzr split, however, this does not work how I expect.
The resulting branch still contains the history of all files from all original directories, and a full checkout retrieves all the files. It appears the only thing that split does is convert the repository to a rich root repository so that this particular tree can be of a certain subdirectory only, but the repository still contains all other directories and other checkouts can still retrieve the whole tree.
I used the method in jamuraa's answer above, and this was much better for me as I didn't have to mess with converting to a new repository type. It also meant that full checkouts/branching from that repository only recreated the files I wanted to.
However, it still had the downside that the repository stored the history of all those 'deleted' files, which meant that it took up more space than necessary (and could be a privacy issue if you don't want people to be able to see older revisions of those 'other' directories).
So, more advice on chopping a Bazaar branch down to only one of its subdirectories while permanently removing history of everything else would be appreciated.
Do a
bzr init .
bzr add .
bzr commit
in the framework directory.
Then you can branch and merge to just that directory.
The bazaar higher up will ignore that directory until you do a join.
Bazaar understands when you do things like
bzr branch . mycopy
bzr branch . myothercopy
The current directories .bzr won't track those subdirectories changes.
It saves you from trying to find a place to put a branch.