I have a repository and I need work done by some subcontractors, let's say.
Instead of splitting the repo up into dependencies, to hide proprietary code, I can easily put all of the non-sensitive code in a folder, and somehow just give the subcontractors access to this one folder. Is this a good use case for git submodules? If so, what might the workflow look like exactly?
Nohow just give the subcontractors access to this one folder. Git doesn't operate on the level of subtree
Submodules is bad choice, consider subtree
Both submodules|subtree mount as subfolder external independent repo, thus you have to split original repo anyway
Related
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.
I try to write a file store based on libgit2.
Software snapshots should be saved as branches mysoftware and specific versions committed and tagged. Then later I want to checkout the tags to different directories.
When looking at git_checkout_tree, it seems like there is only one working tree for a repository and thus it does not even seem possible to checkout multiple working trees concurrently.
Is this correct!?
EDIT:
Additionally, I would like for this thing to work on Windows without the need for cygwin!
The git_checkout_opts structure in libgit2 contains a target_directory option that will allow git_checkout_tree() to write to a different directory instead of using the default working tree for the repository. This would allow you to custom build a solution with libgit2 that maintained multiple checked out copies.
Without using that option, a libgit2 git_repository object expects there will be just one working directory and looks to the core.worktree config option if it isn't the "natural" working directory for the repository.
The git-new-workdir tricks with symlinks in the .git directory don't work great with libgit2 right now, I'm afraid, and particularly doesn't work well on Windows. I'd love to see this addressed, but it isn't too high on my priority list.
Git doesn't support this natively, but you can use git-new-workdir to do it.
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 want to create a bazaar repository and have the .bzr directory not alongside the versioned files.
I'm searching for an option like "--git-dir" in git, or a way to achieve the same thing. Evenctually I'd accept an hack too.
A solution using bzrlib is feasible
Example current structure
project/.bzr
project/foo_versioned_file
project/bar_versioned_file
Wannabe structure
project/foo_versioned_file
project/bar_versioned_file
/unrelated_path/.bzr
There is nothing like --git-dir in bzr, but if you only need avoid having the full history along your working tree, then it's worth to consider using lightweight checkouts. Lightweight checkouts allow you to use only small number of files in .bzr/ directory (but you have to have it anyway) and the real branch with its repository and its history can be kept outside the working tree. So:
bzr branch bzr+ssh://HOST/REPO/BRANCH /unrelated_path
bzr checkout --lightweight /unrelated_path project
I have a Bazaar repository on Host A with multiple branches. This is my main repository.
Until now, I have been doing checkouts on my other machines and committing directly to the main repository. However, now I am consolidating all my work to my laptop and multiple VMs. I need to be working offline regularly. In particular, I need to create/delete/merge branches all while offline.
I was thinking of continuing to have the master on Host A with a clone of the repository on the laptop with each vms doing checkouts of the clone.
Then, when I go offline, I could do bzr unbind on the clone and bzr bind when I am back online.
This failed as soon as I tried to bzr clone since bzr clone only clones a branch(!!!!)
I need some serious help. If Hg would handle this better please let me know (I need Windows support.) However, at this moment I cannot switch from Bazaar as it is too close to some important deadlines.
Thanks in advance!
bzr fundamentally works with one branch / directory (the branch are visible at the file system level), so if you need to clone each branch from your repository (not unlike svn, in a way). Hg, at basic level, works this way too (although you can put several branches in one repository using say named branches).
For DVCS, it is important to distinguish between the following:
Working tree: a versioned set of files (at a given revision)
Branch: a linear set of revisions
Repository: a set of revisions
When you clone locally a directory versioned by bzr, you are copying the repository subset which contains all the revisions in the branch you are cloning, and get the working tree. This assumes you are not asking for a branch wo a working tree nor using a shared repository.
What you want, IIUC, is to clone the full repository with all the branches. There is no 'native' way to do so in bzr I believe, but plugins to help you toward this, like multi-pull and push-repo, to sync multiple branches in one shot.
But I don't understand why that's such a big problem, or the link with working offline: you just clone the branches you want to work on your laptop.