Showing posts with label git. Show all posts
Showing posts with label git. Show all posts

Wednesday, October 9, 2013

EGit Push tag broken

The Push Tag... wizard is much too complicated at the moment, yes. Try 
enteringrefs/tags/ as the target ref name.

http://stackoverflow.com/questions/18396182/egit-push-tag-broken

Monday, September 30, 2013

What's the difference between 'git pull' and 'git fetch'?

  • When you use pull, Git tries to automatically do your work for you. It is context sensitive, so Git will merge any pulled commits into the branch you are currently working in. pull automatically merges the commits without letting you review them first. If you don’t closely manage your branches you may run into frequent conflicts.
  • When you fetch, Git gathers any commits from the target branch that do not exist in your current branch and stores them in your local repository. However, it does not merge them with your current branch. This is particularly useful if you need to keep your repository up to date, but are working on something that might break if you update your files. To integrate the commits into your master branch, you use merge.

git rebase vs git merge

Short Version

  • Merge takes all the changes in one branch and merge them into another branch in one commit.
  • Rebase says I want the point at which I branched to move to a new starting point
So when do you use either one?

Merge

  • Let's say you have created a branch for the purpose of developing a single feature. When you want to bring those changes back to master, you probably want merge (you don't care about maintaining all of the interim commits).

Rebase

  • A second scenario would be if you started doing some development and then another developer made an unrelated change. You probably want to pull and then rebase to base your changes from the current version from the repo.

Sunday, September 29, 2013

using github + eclipse to pull code

eGit doesn't know, which remote branch you want to pull from. If you create your local branch based on a remote tracking branch, then the key is generated automatically. Otherwise you have to create it yourself:
branch.master.merge=refs/heads/master
branch.master.remote=origin
where master stands for the branchname, in the key it's your local branch, in the value it's the branch in the remote repository. Place that in the repository-specific configuration file%repositorypath%\.git\config
As for the terms:
  • merge: join two or more development histories together
  • fetch: download objects and refs from another repository
  • pull: fetch from and merge with another repository or local branch
  • sync: allows you to compare 2 branches
In general, I urge you to read eGit user guide, where you can get even better understanding of Git and eGit. It can be found at http://wiki.eclipse.org/EGit/User_Guide

Thursday, September 19, 2013

Difference between HEAD and master

master is a reference to the end of a branch (by convention this is usually the 'trunk' of the tree, to use a SVN term, but it doesn't have to be).
HEAD is actually a special type of reference that points to another reference. It may point to master or it may not (it will point to whichever branch is currently checked out). If you know you want to be committing to themaster branch then push to this.
Here is a visual example:
alt text
On your own repository you can check where the HEAD is pointing to by running this:
$ git symbolic-ref HEAD
refs/heads/master
However, finding out where the remotes/origin/HEAD is pointing to is more tricky because it is on the remote machine.
There is a great little tutorial on git references here:

.gitignore vs .gitkeep

".gitkeep" isn’t documented, because it’s not a feature of Git.
Git cannot add a completely empty directory. People who want to track empty directories in Git have created the convention of putting files called “.gitkeep” in these directories. The file could be called anything; Git assigns no special significance to this name.
There is a competing convention of adding a “.gitignore” file to the empty directories to get them tracked, but some people see this as confusing since the goal is to keep the empty directories, not ignore them; “.gitignore” is also used to list files that should be ignored by Git when looking for untracked files.

Wednesday, September 4, 2013

Undoing a git push

You need to make sure that no other users of this repository are fetching the incorrect changes or trying to build on top of the commits that you want removed because you are about to rewind history.
Then you need to 'force' push the old reference.
git push -f origin cc4b63bebb6:alpha-0.3.0
You may have receive.denyNonFastForwards set on the remote repository. If this is the case, then you will get an error which includes the phrase [remote rejected].
In this scenario, you will have to delete and recreate the branch.
git push origin :alpha-0.3.0
git push origin cc4b63bebb6:refs/heads/alpha-0.3.0
If this doesn't work - perhaps because you have receive.denyDeletes set, then you have to have direct access to the repository. In the remote repository, you then have to do something like the following plumbing command.
git update-ref refs/heads/alpha-0.3.0 cc4b63bebb6 83c9191dea8
http://stackoverflow.com/questions/1270514/undoing-a-git-push

Friday, August 30, 2013

How to migrate SVN with history to a new Git repository?

Magic:
$ git svn clone http://svn/repo/here/trunk
Git and SVN operate very differently. You need to learn Git, and if you want to track changes from SVN upstream, you need to learn git-svn. The git-svn man page has a good examples section:
$ git svn --help
http://stackoverflow.com/questions/79165/how-to-migrate-svn-with-history-to-a-new-git-repository

Git - Won't add files?

I found myself in a similar situation as the poster:
If I call "git add .", and then "git status" and it keeps saying "working directory clean" and has nothing to commit.
But I had a different solution than what's here. Since I came to this first, I hope to save others some time.
From the above answers and what I've seen elsewhere, the usual fixes to this problem are:
  • Ensure there are actually saved changes on the file in question
  • Ensure the file doesn't meet your exclude rules in .gitignore and .git/info/exclude
  • You're not trying to add an empty folder. Git won't track those. Standard solution is to place a blank file named .gitignore as a placeholder so git will track the folder.
In my case, I had originally tried to create a git repo around an existing repo (not knowing it was there). I had removed the .git folder from this sub repo a while ago, but I didn't realize that it was too late, and git was already tracking it as a submodule. You can read more about how these behave and how to remove them here, but
  • the solution for me was to simply run git rm --cached path_to_submodule.

Thursday, August 29, 2013

When pushing to remote Git repo using EGit in Eclipse, what should I choose?

You see this screen in Egit Push URI documentation:
Push Ref Specification
That is where you define the refspecs:
A "refspec" is used by fetch and push operations to describe the mapping between remote Ref and local Ref.
Semantically they define how local branches or tags are mapped to branches or tags in a remote repository.
In native git they are combined with a colon in the format :, preceded by an optional plus sign, + to denote forced update.
In EGit they can be displayed and also edited in tabular form in the Push Ref Specification and the Fetch Ref Specification and other dialogs.
The "left-hand" side of a RefSpec is called source and the "right-hand" side is called destination.
Depending on whether the RefSpec is used for fetch or for push, the semantics of source and destination differ:
For a Push RefSpec, the source denotes a Ref in the source Repository and the destination denotes a Ref in the target Repository.

Push Refspecs

A typical example for a Push RefSpec could be
HEAD:refs/heads/master
This means that the currently checked out branch (as signified by the HEAD Reference, see Git References) will be pushed into the master branch of the remote repository. 
http://stackoverflow.com/questions/10365958/when-pushing-to-remote-git-repo-using-egit-in-eclipse-what-should-i-choose

Friday, August 23, 2013

Multiple projects in one git repo?

In Git, it is better to have each project in its own repo, and the libraries in another repo if needed and used as submodules ( equivalent of svn externals) in each project.
This is because in Git, a repo is a much more lightweight concept than SVN and also, more importantly, there is no ability to clone individual folders ( not to be confused with sparse checkout) within a repo separately like you are able to checkout and work on individual folders in SVN. So if you had all projects in a single repo, you will have to clone them all.
Serving Git repos, using smart-http, git daemon and ssh is pretty straightforward. There is also Gitolitefor managing multiple repos ( including authorization and authentication). Read the linked chapter on ProGit on serving Git repos- http://progit.org/book/ch4-2.html
Coming to your grouping, you can put the repos in folders as per your grouping structure, and serve using, say smart http method, whereby the repo urls will look like the urls that you would have used with SVN, will all projects seeming to be under the grouping etc.

How can I delete a file from git repo?

Use git rm:
git rm file1.txt
git commit -m "remove file1.txt"
http://stackoverflow.com/questions/2047465/how-can-i-delete-a-file-from-git-repo