I have gone thru the egit tutorial doc here http://wiki.eclipse.org/EGit/User_Guide.
I now have a git repository with an eclipse project on my laptop and can push this to a remote git repository on git hub. However, this means I have two git repositories - one local and one remote. I'm thinking I'd prefer to just use the remote one only. This would mean any time I commit, it commits to the remote and there is no local repository.
Is it possible to this egit?
Thanks.
git is a distributed version control system. By definition this means that each developer has its own repository.
I have not experience with egit but you can configure a hook to automatically make a push after a commit.
Also, in a git cli you could set an alias to make the commit and push process in only one step, but anyway, the local repository will be need.
You should always have a local repository to work with. First pull the repository to local repository, perform changes and push back to the remote repository.
Related
I have a project in my local Git repository and there is a problem in the project that is not fixed after lots of pull from origin etc. So, I need to clone the project from origin without losing the branches in the project (in local repository). So, what is the best approach for this kind of situations? Because sometimes I have seen this problem and fix the problem by deleting project completely on local repo and cloning from remote repo.
You shouldn't have to delete a project completely on your local repo just to clone from the remote repo. If you really want to do that you could just try creating a new local repo and then clone from the remote repo and then you will still have all of your other branches in the original local repo.
I would recommend trying git reset --hard origin/master to see if that fixes your problem.
I am working in a company network which blocks connectivity to remote maven repo,What is the best way to use maven offline without sync with remote repo ?
Do we have option without setting up a mirror in local machine.
This is not ideal, but you could build the project outside your company network (at home), then take a copy of your .m2 directory back to your work computer. This works in a pinch and only until you need more dependencies.
I have forked original repository into my github account and cloned the same into my workspace. After working for a week on my local branch I want to push my local branch to my forked repository and then merge it with original repository. But I can see that files that I have modified in my local branch have also been modified in the original repository. I can think of two approaches for merging my local branch safely.
Should I first get the latest changes from the original repository into my local branch using git pull? In this case will the complete file be overridden or only parts of the file that has changed in the original repository preserving my local changes.
Second approach is to go ahead with pushing my changes to my forked repository and then merge it with original repository. Here I am assuming that Git considers a conflict only if there are two different versions of the same line in a file. In case the two versions of the file have changes in different parts of the file they can be merged safely.
I am also little unclear about when Git merges two versions of a file. How does it decide which version of the file will take precedence over the other.
Any other approach to do the same is welcome.
First of all, in such scenario it is hard to avoid conflicts at all, and generally working on the same repository with other people you should be prepared to resolve conflicts once in a while.
In your case I would use git rebase and utilize git branches, which are a really useful feature when used well.
Create separate branch with your changes locally
Revert your local master branch to the state before this changes
Update local master branch with changes from the original repository
Push your master branch to your remote repository (so that your forked version matches the original repository)
Rebase your local feature branch onto master. In this step you'll probably need to resolve some conflicts. But it would be easier, as you are based on current master (destination of your changes), and you are in control what should go in, and what should not. Also, you can easily test your solution after rebase, and make some changes before issueing a pull request.
Push local feature branch with your changes to your remote repository.
Create pull request to the original repository.
// I assume that your local master branch is set up to track origin/master branch, where origin is your forked version of the original repository.
// 1. Local branch named "my-new-feature"
$ git branch my-new-feature
// 2. Reset your master branch back to the state before changes
$ git fetch origin
$ git reset --hard origin/master
// 3. Update local master branch. First you need to add the original repository as a remote (let's name it "upstream")
$ git remote add upstream https://github.com/some-user/some-project.git
$ git fetch upstream
// you should still be on your local master branch. Now update this local branch with changes from the original repo
$ git rebase upstream/master
// 4. Push your local master to your forked repository
$ git push origin master
// 5. Rebase your changes onto master
$ git checkout my-new-feature
$ git rebase master
// This is the place where you are most likely to have conficts. Read git messages, as it helps you what to do.
// Once all conflicts have been resolved, stage your changes but do not commit. If committed they will not be detected by ongoing rebase.
$ git add .
$ git rebase --continue
// 6. Push your local branch with newest changes
$ git push origin my-new-feature
// 7. Issue a pull request on GitHub using your just pushed branch
Also, git merges two files based on the direction of the merge. If you are on a branch A-branch, and you run git merge B-branch, then files from B-branch have "higher priority" and their changes will be most likely applied automatically.
I will suggest the first approch as you listed: pull the changes from the original repo first. Reasons as below:
It will save energies for the users who view pull request and merge the branches.
If there has conflicts for mering the pull request, you should also resolve the conflicts again in your local repo, and then push to the fork repo again.
Pull changes from the original repo only overwrite parts of files not all files. Situations as below:
Files neither changed in original repo nor your local repo: these files won’t changed.
Files changed in the original repo but not changed in your local repo: these files will be overwrited as the version of the original repo in your local repo.
Files not changed in original repo but changed in your local repo: these files won’t be overwrite.
File both changed in original repo and in your local repo: these files will show as conflicts, you should resolve the conflicts manually.
To pull the changes from original repo, you’d better pull with --rebase option (pull the change from original repo first, then apply your local changes on the top of the latest original repo:
git pull <remote> <branch> --rebase
Assume the commit histroy as below after git fetch (origin is the remote for the fork repo, upstream is the remote for the original repo):
…---A---B---C---D---E master, origin/master
\
F---G---H upstream/master
Then you can execute below commands:
git pull upstream master --rebase
git push origin master -f
Then the commit history will be:
…---A---B---F---G---H---C'---D'---F' master, origin/master
|
upstream/master
Then you can create a PR to merge the fork repo master branch into the original repo. It will be convenient for PR viewers and approvers.
Env : Maven 3.3.9
Hi,
I have a maven jar module with version as 1.0-SNAPSHOT. When i do mvn install, the jar installed into local repository (~/.m2/repository) does not have timestamp. I agree that its not a common scenario where you would like to have timestamped jars in your ~/.m2/repository repo. But still couple of questions:
Does mvn install append timestamp automatically? Looking for some
configuration way rather than use ${timestamp} in final name.
Does automatic timestamp mechanism applies to mvn deploy?
Is there a way to tell maven to use ~/.m2/repository
itself for mvn deploy?
Thanks,
Rakesh
The mvn install will only put your project into your local cache which means it makes it available for other projects on your machine.
mvn deploy will deploy the artifacts into your remote repository which is usually a corporate repository manager.
In case of a SNAPSHOT this means this artifact has not been finalized and is under developer. This means you can create several states of the same version like 1.0.0-SNAPSHOT. The time stamp which is created during the deployment to a repository manager is intended to have different artifacts available for development. You can control via -U option if you like to use the most recent version of the SNAPSHOT's.
After you feel ready you make a so called release which will set the version to something like 1.0.0 (without SNAPSHOT) which is deployed as well but into a release repository which is immutable.
Furthermore having timestamps in your local cache $HOME/.m2/repository does not make really sense, cause you can control when you install an artifact there and no one else and you should prevent using finalName change cause this is only intended for your target folder and not for your local cache.
And finally using the local cache for mvn deploy does not make sense, cause what is the idea behind that? Best is to start using a repository manager like Nexus, Artifactory or Archiva in particular if your are working in a corporate environment.
In addition to #khmarbaise's answer see the following references:
Maven / Introduction to Repositories:
There are strictly only two types of repositories: local and remote. The local repository refers to a copy on your own installation that is a cache of the remote downloads, and also contains the temporary build artifacts that you have not yet released.
Remote repositories refer to any other type of repository, [...]
Maven: The Complete Reference, 15.2.8. Repositories:
Repositories are remote collections of projects from which Maven uses to populate the local repository of the build system.
Repository - SNAPSHOT Handling reads:
This documentation was targetted at Maven 2.0 alpha 1. It is here only for historical reference and to be updated and integrated into the Maven documentation.
But I didn't find any latest documentation where this has been integrated. (#khmarbaise?)
Timestamped files are not created on install in the local repository for reasons of disk space preservation. However, when a SNAPSHOT is resolved and downloaded, it is saved with its timestamp version number (eg: 0.15-20050401.150432-2).
Understanding Maven Version Numbers
Maven Dependency Resolution - A Repository Perspective
Long story short:
The same snapshot version can be deployed to a remote repository from different hosts, so they have to be distinguished there somehow. And they are distinguished by timestamps (and a build number).
There will be an artifact with a timestamp (and build number) in the local repository only if Maven resolved and, hence, downloaded it from remote.
So:
No.
Yes.
Would break Maven's repositories handling of local vs. remote.
This may sound crazy but we have our developers all working on the same Linux machine, this machine also has nexus installed as our maven repo. Effectively everyone ends up with artefacts in their ~/.m2/ folder which are also duplicated in the nexus server.
Is it possible to simply tell maven to only look at the artefacts in nexus?
I have for the moment set the property <localRepository>/path/to/global/repo</localRepository> in our global maven config, but unsure if this could cause a problem if two users are grabbing the same file at the same time.
We do this because the company won't buy us powerful workstations so we all ssh to our development server.
I'm not sure if this directly answers your concern, but it looks like what you're doing is correct.
From http://maven.apache.org/settings.html
localRepository: This value is the path of this build system's local
repository. The default value is
${user.home}/.m2/repository. This
element is especially useful for a
main build server allowing all
logged-in users to build from a common
local repository.
I wouldn't want to point my local repo to the nexus datastore, because then installs would update the repository datastore behind nexus' back.
However you could set up a single "machine" local repo separate to the nexus datastore,
and then for each user change the ~/.m2/repository directory to be a symlink pointing to the "machine" local repo.
At least then you'll only have 2 copies of the repo.
Concurrent installs and downloads, are still likely to clobber one another, but this can be fixed with an annoying redo.
Update:
There is a new solution available.
Installation of the TEAM (Takari Extensions for Apache Maven) extensions, provides a thread-safe local repository and an improved algorithm for multi module builds.
See http://takari.io/book/30-team-maven.html#concurrent-safe-local-repository
Use the
--offline
option at command line.