I've been using the git plugin for Eclipse for months without problems.
But lately (after a bad forgotten manipulation, probably) when I switch branch using the contextual menu "Team -> Switch To", the modifications are pushed to the last branch.
Now, each time I'm doing a push or pull after a switch, I need to remember to modify the ref mappings.
A temporary fix has been to set the mappings in "Configure push for remote origin" to :
refs/heads/*:refs/remotes/origin/*
but I prefer to avoid pushing all branches each time.
Is there a way to go back to the usual behavior where the current local branch is pushed to the correct remote location after a switch, without having to modify the ref mappings each time?
The solution was actually simple:
I just needed to remove all ref mappings declared in the push configuration. The system pushes the current branch to the corresponding one in the remote.
Related
I am using the git plugin for eclipse and I have noticed a problem with it and hoping this is a simple configuration change. Can anyone help?
When switching branches, the uncommitted changes are being merged across onto the newly checked out branch (only in certain circumstances). It seems as if this happens every time when it is "safe" to do so. The way to recreate is:
Create feature branch "branch1" from remote repository
Create feature branch "branch2" from same remote repository
Make changes on "branch2" and don't commit changes.
Switch to "branch1"
a. No confirmation message is shown.
b. The uncommitted changes from "branch2" are merged onto "branch1"
I want to be able to force the commit message to appear (just like it does using git-bash). Is this possible?
To my understanding, this behavior is intended by EGit: a checkout is performed as long as the files to be checked out do not collide with the working directory. And uncommitted changes are left as they are.
If you think EGit should offer a different strategy of handling uncommitted changes I suggest to open an enhancement request: https://eclipse.org/egit/support/
In the meanwhile, you may want to (manually) stash uncommitted changes prior to switching branches. That's what I see most people do in this situation.
I started using SourceTree few days ago and after I committed and pushed my changes to the remote GitHub repository, the numbers on the buttons remain the same, for example if the number on the push button becomes 3 when I committed a change, after I pushed it; it needs to be 0 or empty. But that's not the case here, it remains the same even though it has successfully been pushed. I also checked that my changes had been pushed using a web browser by going to the GitHub site. Is it because of the branch that I have pulled from and am pushing to are different or something else? Can any one please help cause I don't understand it... Thanks!
The numbers shown on the right hand side of the Branches panel reflect how many commits ahead or behind the Tracking Branch you currently are. If the numbers aren't what you expect, you should verify that the branch is tracking what you actually want.
You can verify the tracking branch by right clicking your local branch (as depicted below) and expanding the Track remote branch menu item. Finally, if you want to change the tracking branch simply click the new target from the list and Sourcetree will update accordingly. Hopefully that helps make sense of the disconnect that can happen when you rename branches and provides some details around why it happens and a simple way to resolve.
The same thing also happened to me too, I was working on branch I had push everting but was keeping appearing one unsend Push and miraculously also appear unsend Push on Master.
So what did was the same as Hristo Staykov and Sammie remove the Master branch from my local computer, since I had one miraculously unsend Push on Master did need to run this line terminal to remove the branch:
git branch -D master
And then Repository > Refresh Remote Status
I simply use the keyboard shortcut from the Repository menu:
CTRL+ALT+R (or control+option+R if you prefer)
My guess is that the shortcut would be the same or at least similar on Windows. Just look for the option called Refresh Remote Status under the Repository menu.
So I make my file changes, but when I try to push them source tree complains that some one else pushed before me.The files are different,yet I am forced to merge the changes. Some times I have to backup and reset my workspace before it can allow me to push again
Is there no way to force the push?
Open SourceTree Preferences
Tab: Advanced
Third checkbox: Allow force push
Enable the checkbox and close Preferences.
Next time you push, there will be an extra checkbox: Force push.
Checking it will also display an additional Confirm Force Push dialog box before the force push is actually performed.
Even though the files are different, you have to perform a merge or a rebase before you can push. The commits from your current working branch have to be merged into the current branch that exists on the server before you can update it. You're merging the branches, not the files.
Using the "force push" command does not force your commits to be applied in addition to what is on the remote branch - it forces your commits to replace the commits on the remote branch. Using this option would throw away all of the commits that had been made by the other user.
Because this is a destructive operation, SourceTree does not include GUI access to the "force push" command. Here's what Steve Streeting from Atlassian says about it:
SourceTree doesn't expose force push because it's almost always not what you want to do.
It means that someone else has pushed before you. What you should be doing is pulling their changes, merging them (or rebasing your changes on top of them), and then pushing.
I have been doing all my work on the master branch. Since I created my project and pushed it into my Github repository, I have been the only one working on it so I have had no need to fetch.
I want to work on an experimental feature, so I want to create a new branch. When I go to "Team -> Switch To -> New Branch" I see this:
It mentions creating a branch based on a local branch. I have read EGit Local vs. Remote repositories but to be honest I am quite confused by it. I'm not sure if I should be fetching or cloning because both are mentioned there, and even then I'm not sure how I would do it (like I said, as I am the only contributor to this project all I've had to do so far is commit and push).
And even then, I'm not sure if Rebase, Merge, None should be my pull strategy as shown in the screenshot?
I was hoping I could just create a new branch, commit and push like I normally do and then switch back to my master branch when I didn't want to work on my experimental feature. It seems like it's much more complicated than that.
I'd like to be able to do this through Eclipse so I learn how for the future, but will it be easier if I just do this on the Git command line? Thanks in advance.
It sounds like what you want is to create your (local) branch based the remote/origin master (use the drop-down list at the top) and then select Merge as your pull strategy. That way when you are working on the branch and pull, it will pull from master and merge any changes directly into the branch. It also allows you to push the branch to remote, which give you another level of safety in case your local repo gets lost or messes up somehow.
Another piece of advice I've learned the hard way: whenever I'm about to do something with git that I'm not totally confident about, I make a quick ZIP or copy of my local repo. That way it's easy to throw away whatever I did and go back to a good state. Sad that git drives us to such measures, isn't it?
I'm trying to rationalize two perspectives which seem to be related (or at least provide very similar functionality): The 'Git Repository' perspective (which I got after adding EGit), and the 'Team Synchronizing' perspective (which I think was part of the EE distribution).
As far as I can tell, I was able to get the Git Repository working (with GitHub), or at least most of the features: The 'Git Staging' Window is working fine, I'm able to commit by dragging files from 'Unstaged changes' to 'Staged changes' and then clicking the Commit icon. Then I'm able to push my changes from the 'Git Repositories' window, by right clicking on the workspace->Remotes->origin->url, and select Push from menu (is that the 'correct' procedure?).
With the 'Team Synchronizing' perspective, I'm no luck to even set it up. Once selecting the 'Synchronize...' frmo the menu, the Git, then I see a table (what is it?). I'm trying various values for the Destination (otherwise, unable to hit the Finish button), but no matter what I do, it tells me 'no changes' for all my projects.
There are also many context-menu item when right clicking on a project, and selecting 'Team'. What are these?
In CVS the Team Synchronize is about the only sane way of managing your incoming and outgoing changes. You can update / merge incoming changes and commit outgoing changes from this one view. Since every commit is discrete and it is non-atomic, the view is fine for this workflow.
In EGit however you already have explicit actions for adding, committing, pushing, pulling and merging. So the team synchronize is largely outside the normal workflow. It behaves much like a glorified synching from a patch - you pick which branch(s) you wish to compare your working directory and it shows you the differences. You can then apply those changes en masse or individually but it's not going to pick up the context, i.e. it's not going to create merge points or whatnot.
So you should train yourself not to use except for exceptional reasons. For example, maybe you have two branches A & B. Somebody committed a change to B and you need only a small part of it, so you could use Team Sync to show the diffs and only apply the ones you need. Or maybe you just want to squash up all the changes on branch B and call them a single commit in A. Then you might use Team Sync rather than screwing around with a rebase when you're going to toss B anyway or its a remote branch.
From my understanding, the "Git repository" perspective is intended for committing files from the working directory to the local Git repository, while the "Team synchronizing" perspective is for syncing your local repository with a remote one.
I found this confusing at first as well, because when using SVN, the "Team sync" perspective was for committing/updating files. Until I noticed that in EGit's Team sync perspective, instead of showing the commit/update buttons, it has the pull/push buttons, which are for syncing two Git repositories.
For the various options that appear under the "Team" context menu, they correspond to a bunch of Git operations. I'd suggest some reading about Git's principle of operation before using EGit. http://git-scm.com/doc would be a good start.