I have a remote Git repository with approx. the following repository structure:
service1/
service1/image1/
service1/image1/docker/
service1/image1/docker/Dockerfile
service2/
service2/image2/
service2/iamge2/docker/
service2/image2/docker/Dockerfile
I can clone it from https://<my-git-server>/my-project.git to obtain a directory my-project/ and a corresponding file structure underneath it.
My service2 is a Tomcat server that hosts a webapp whose source code I would like to push into the same remote repository next.
Eclipse's file structure inside the project folder is approx. as follows (as is normal for Dynamic Web Projects in Eclipse):
my-project/WebContent/
my-project/build/
my-project/src/
If possible, I would like to arrive at a new repository structure for the remote Git repository as follows:
service1/
service1/image1/docker/
service1/image1/docker/Dockerfile
service2/
service2/image2/
service2/image2/docker/
service2/image2/docker/Dockerfile
service2/image2/eclipse/
service2/image2/eclipse/my-project/
service2/image2/eclipse/my-project/WebContent/
service2/image2/eclipse/my-project/build/
service2/image2/eclipse/my-project/src/
My question is: how I can specify the additional path component eclipse/myproject? I understand that pushing from Eclipse to https://<my-git-server>/my-project.git would result in WebContent, build and src becoming siblings of service1 and service2, and that pushing from Eclipse to https://<my-git-server>/my-project.git/service2/image2/eclipse/my-project would not work either.
So how does one accomplish such a thing?
Upon further study and reflection I have decided on managing source code for my project in two Git repositories. I have no outside dependencies that would prevent me from doing so and have come to understand that monorepos and Git don't fit so well.
For reference, here are the new repository structures:
service1/
service1/image1/docker/
service1/image1/docker/Dockerfile
service2/
service2/image2/
service2/image2/docker/
service2/image2/docker/Dockerfile
WebContent/
build/
src/
If I am not mistaken, Git subtrees or submodules could now serve for cloning from these repositories into a single "mono" (as in monorepo) local view, if ever required.
Related
I've worked with SVN all my life and, right now, I'm trying to learn a little about GIT. In order to do so, I have created a local private GIT server in a RaspBerry and connected it to my Eclipse.
Until now, I have created a folder in the raspberry (/home/pi/raspberry-repo.git/ ) and formatted it as a GIT repository ( git init --bare ) creating the following directory structure:
I have also successfully connected Eclipse via SSH to such repository but I have some question that may be conceptual in nature:
I already have 2 local projects in Eclipse and I have executed the Team>Share Project in them, in order to add them to the LOCAL repository in my PC. After that, I have made some commits in both projects to such local repository and pushed the changes to the remote repository in the raspberry. My doubt appears when I look the GIT perspective in Eclipse.
In SVN the usual structure is:
but in GIT the structure seems to be this:
So, AFAIK in order to download a project from a remote repository I must File>Import>Projects from GIT, select the branch and the project in such branch.
Is all this correct?
Should I use just one project per repository? (Create a folder in the raspberry for each project )
Another question is why I'm unable to see any proper file from my projects when I browse throught the Raspberry filesystem (I just see a new folder inside of the Objects folder for each commit). The repository is not stored in plain text... Is that normal or I'm making some mistake when configuring the repository folder in the raspberry?
Hope you have patience with this doubts! By the way, any GOOD tutorial is welcome (the ones I have found aren't very good)
I've seen similar questions but some are very old and some are not quite what I'm looking for or have no answers.
I have projects in Eclipse under /workspace/project1 and /workspace/project2. They are Gradle projects and are dependent on each other. I also have /workspace/project3 which is a Gradle project but independent.
I need to "upload" them to a git repo on Bitbucket. I installed EGit to help me with this. It asks me where my local repo is located and I don't know what to tell it. Should I create a repo per workspace or per group of dependent projects or what?
For example when I right click a project and press Team > Share > Git I get to this dialog and I don't know what I should fill in there.
Each (non-bare) git repository has a work directory in which the files of the currently checked out commit (referred to as HEAD) are stored.
By default, the work directory is the parent of the git metadata directory (named .git), but it can be detached through a config setting. For example: git config core.worktree /path/to/workdir
EGit cannot deal with repositories that have a detached work directory as answered here: EGit working directory not under the local repository
But irrespective of this limitation, you cannot split the work directory of a git repository among several workspaces.
Therefore, you should move the projects to the work directory to resemble this structure:
~/git/my-repo/.git
~/git/my-repo/project1
~/git/my-repo/project2
~/git/my-repo/project3
If project3 is independent of the others, it may remain where it is or be located somewhere else entirely.
A word of caution when planning to have interdependent projects spread across several git repositories. This makes the git repositories effectively interdependent as well, but without git having a dependency management tool.
To have EGit move the projects, you would enter project1 in the Path within repository input field.
Commonly used build files like the master pom.xml or corresponding Gradle files would be located in the root of the work directory. This also eases configuration of popular build services like Travis, Codeship and friends.
A few things to understand/keep in mind:
An Eclipse workspace is a logical container of projects, not necessarily a physical container. The folder in which a worksapce is located can also be a physical container of projects, meaning the project's files can be located in a folder under the workspace folder (this is the default location if you create a new project in Eclipse). But that is not a requirement; a project that is contained within a workspace can have its contents (its files) located in any location on your file system.
In most dev setups, the local git repos are located in a "standard" location in the user's home directory, namely %USER_HOME%/git/name-of-repo. Again, that's not a hard requirement, users have the option to clone or create repos in any location they choose.
So Eclipse eGit is showing you those 2 axes of flexibility. It's asking where you want to create your local git repo, which usually is different than your workspace folder. Use the Create... button to create it. I think at that point it will auto-populate the Path within repository field. If it does not, you can name that path anything you want (usually its the same as the project name, though not necessarily)
At the end of it all you'll have your workspace (logical container) as well as a local git repo which will be the physical location of the project contents.
I am using CVS and I have this hierarchy:
/ROOT
/JAVA
/JavaProject1
/JavaProject2
.project
/PHP
/PHPProject1
/PHPProject2
.project
In Eclipse > CVS Repository Exploring, I can see this hierarchy and I can Check Out only the project that I want.
Also I can check out (import) JAVA and PHP folders (I created them as Eclipse General project for import) to Eclipse Package Explorer and can synchronize and commit all together.
When I want to use Git, it only supports one project.
I don't want a flat hierarchy (near all JAVA and PHP project together), I want to use tree hierarchy and I want to check out only the project that I want as with CVS.
Is my CVS hierarchy possible in Git or what technique should I use?
I think you're mixing what you want to do locally with how you want
to arrange things remotely. All git commands access only the local
repository. The 'push' and 'fetch' commands appear to access a remote
repository, but in fact they effectively start each other on the remote
machine running against the local repository on that machine. So the
tasks you can do remotely are very limited. Specifically, copying "branch"
and "tag" references and the commit histories those references point at.
This means for the simple case there is ONLY the local repository,
it exists in the .git directory in the working directory.
You can arrange working directories, with their .git directories however
you wish on your local machine. Likewise, you can arrange the the remote
repositories in any way allowed by the remote hosting service. The
layouts do not have to match. If the remote is your own Linux server you
can make the layout just like your local. If the remote is (for example)
Github you're more limited.
You'll need to backup the .git directory to backup
the repository; the rest of the working directory is probably not significant. You can use git push to do this backup, as long as you never use '--force'.
Git isn't really very keen on you having multiple working directories
for one repository. It is possible, however, in the simple case they
will each have their own copy of the repository and you will need to
push/pull the updates individually either to a "central" repository
or more "randomly". None of these repositories have to be physically
"remote".
Git much prefers you to switch between branches in one working directory
and use make install style processes to send builds out.
It is also possible to have unrelated branches in one repository, but most people find this too confusing as you still only have one working directory.
I'd like to create Git repositories for some of my existing STM32 embedded C projects that I'm developing with Eclipse.
Currently I have two separate projects in their own folders, and a common folder containing ST's official STM32 Cube peripheral drivers (.c and .h) files that both projects use.
The driver folder shouldn't change (except when new versions are released) but the project files will be edited as I develop them.
How should I place them on Git? Should I:
Have three repos (one for each project and another for the drivers)?
Have two repos and change my project structure to place the drivers with both projects?
Something else?
The first option seems OK, but if I don't clone both the project and driver repos, and do them to specific locations, I can't see how I would configure Eclipse properly.
The second seems more hassle free but redundant (it won't be as easy to update all projects to use new drivers as they are released, and it will use more server space).
EDIT: Just to clarify, I'm not using the STM32CubeMX software. I'm simply using the STM32CubeF4 peripheral drivers, which are basically just embedded C .c/.h source/header files for the chip's internal peripherals (and possibly a few .lib library files for DSP calculations). See the "download" button at the bottom of this page for the .zip archive (current version is 1.4.0): http://www.st.com/web/en/catalog/tools/PF259243
If you use a common driver in several other repos, it looks like a job for git submodules.
You have three separate repos, for example on your server, and both projects include the driver code as a submodule. What is stored in each project repo is:
an URL to the driver repo (on your server)
which commit of the driver repo is to be used
the path where to put the driver clone, relative to the project repo
After cloning a project repo, you run git submodule update --init, and the repo at URL is cloned into the relative path, and its commit is checked out.
git submodule add --name <driver> /server/src/driver.git driver
(/server/src/driver.git is URL, driver is path. <driver> is just an optional reference to ease future work with submodules. Don't use it if it is the same as path)
git submodules feel a bit cumbersome at first. For example, cloning or checking out commits in the parent (project) repo does not make the submodules working files up to date. You have to manually git submodule update for that.
You will end up with two clones of your driver, one in each project's working files structure. But this is not really redundant, as they are clones of a common driver repo on your server.
For every update of your driver, you push the driver changes to your server. To update to the latest driver version in another project, you go to that project's submodule, do the usual git push (you might be in detached state, in which case you need to checkout master first). The update will show up in the project's (not the submodule's) git status, which will tell you "New commits" in the driver submodule. What has changed is which SHA1 is checked out in your submodule; commit the changes in the project will only update which submodule commit is to be checked out.
I've got a project in a git repository that uses some custom (and so far unversioned) setup scripts for the build environment etc. I'd like to put these under version control (hopefully git) but keep them versioned separate from the project itself, while still living in the base directory of the project - I've considered options like local branches but these seem to have the problem that switch back to master (or any other "real" branch) will throw away the working copies of the setup scripts.
I'm on Windows using msysgit so I've got a few tools to play with; does anyone have a recommendation or solution?
If you really need them separate from your main git repo while still living directly within it, you could try:
creating a new repo with those script within it
and:
adding that new repo as a submodule to your repo. Except:
a/ those scripts won't live directly in the base directory, but in a subfolder representing the submodule
b/ you need of course to not publish (push) that new repo, in order for other cloning your main repo to not get those setup files
or:
merging that new repo into your main repo (with the subtree project), but:
you need to split back your project to get rid of those files
for a project with a large history, and with frequent push, that step (the split) can be long and cumbersome.
I would consider a simpler solution, involving some evolution to your current setup files:
a private repo (as in "not pushed") with those setup files
environment variables with the path of your main git repo in order for your setup files (which would not be directly within the base directory of said main repo) to do their job in the right directory (like beginning for instance with a 'cd right_main_git_repo_dir').
I want to share an additional solution and some samples from which to start.
I've has a similar problem in attempting to build Mozilla Firefox with Buildbot -- I need to have some files in the root folder (namely the .mozconfig file and some helper scripts) and I wanted to version them separately.
My solution is as follow:
checkout the Firefox code from the Mercurial repository;
checkout an additional repository with the additional file I need;
before starting the build, I copy these file to the folder with the Firefox code.
This approach is implemented in the following repositories:
buildconfig-mozilla-central: it contains the Buildbot configuration, which
pulls both repositories
copies the files from the scripts repository
and start the build;
buildscripts-mozilla-central: the repository with the build configuration and helper scripts.
Please note that the code might not be well factored (for example the paths) but it should be a good starting point.
This procedure is tailored for Firefox, but it can be applied to any repository.