Tag: remotes

How to handle a failed push when the remote contains work you don’t have locally – 127

In Visual Studio, if the remote contains work that you don’t have locally, and you try to do a push to that branch, you’ll see the following in Visual Studio Team Explorer:

Failed to push to the remote repository. See output window for more details.

The output window contains more information:

output window - the remote contains work that you don't have locally

You’ll resolve this by clicking Pull

Pull from Team Explorer

Visual Studio will automatically do any merges. Since there are were no conflicts, the auto-merge was successful and created a merge commit.

Push outgoing commits

Now you can simply Push these changes up to the remote.

Successfully pushed to origin/master

From the command line

Here’s what the corresponding scary message looks like from command line.

Updates were rejected because the remote contains work from CLI

You’ll first want to Git Pull – which will result with Notepad prompting me to update my merge commit message if needed.

And now in Mortal Kombat fashion (I spelled Kombat right this time), you need to Finish It!

and do a Git Push.

How to view newly added branches on a remote – 126

A few weeks ago I tried to figure out how to do this, but to no avail. I couldn’t find an answer because the solution is a more of a generic “catch-all” command to get lots of info about a remote, including figuring out which branches were newly added to a remote. 

$ git remote show origin

git remote show origin showing saraford-patch-1 as a new remote branch

Note how next to the circled `saraford-patch-1` you see the text `new (next featch will store in remotes/origin). Now I know what new branches (if any) I’ll “fetch down” the next time I do a fetch. 

Obviously this command shows other goodness, like seeing which local branch talks to which remote branch, and more importantly, what “origin” (or some other specified remote) points to.

Thanks to Jeff (blog comments) for the pointer to `git remote show origin` which answered my question!

How to merge from a remote tracking branch into your local branch in command line – 124

Today’s tip is the continuation from Tip 118 – how to download and merge from a remote branch into Visual Studio, but using the command line.

Let’s suppose you have a local branch that’s tracking the remote branch (see yesterday’s tip). And let’s say someone has made an update to that remote branch (e.g. they made a commit `newfile.md` via the GitHub UI to the branch). Now you want to get those changes into your local branch.

First, we’ll put this week’s earlier tip to good use by doing a `git fetch` just to get those changes onto your computer.

Now you want to merge those changes into your local branch.

First, make sure you’ve checked out the desired branch to receive the merge.

Second, do the merge from the remote tracking branch (since it has the data)

$ git merge origin/<branch-name>

git merge origin/I-am-a-new-branch

And now if you do a `dir` or `ls` you’ll see the changes. In my example, the newfile.md is now shown in the local branch.

newfile.md shown in local branch

How to checkout a remote branch for the first time via the command line – 123

In Tip 116 you saw you to create a local copy of a remote branch in VS. In today’s tip, you’ll learn how to do this from the command line.

First, let’s verify our current list of branches.

git branch -a showing only 1 local branch 

Next, you can use the following git command (provided you only have one remote)

$ git checkout I-am-a-new-branch

It seems that you don’t have to specify the `origin/` part. Git knows to look for corresponding tracking branches.

And you’ll have your local branch.

creating a new local branch from a remote tracking branch

As I’ve mentioned time and time again, I hate shortcuts when learning things for first time. This SO answer tells me there’s a more complete way.

$ git checkout -b <branch-name> origin/<branch-name>

I gave this a try with my gh-pages branch and sure enough it worked!

git checkout -b gh-pages origin/gh-pages

How to use a double verbose to print the name of the upstream branch on command line – 121

Ah Git. It is the gift that keeps on giving if you’re into studying developer tool usability.

Suppose you wanted to get the last commit ID and message while listing all your branches. The `–verbose` or `-v` for short will provide you with that information, e.g.

$ git branch –verbose -a

git branch --verbose -a

Yay! But while I was scanning the documentation, I came across this usability gem*

If given twice, print the name of the upstream branch, as well. (see also git remote show <remote> ).

Yep, if you do a

$ git branch -vv -a

you’ll get even more information! Note the blue text depicting the upstream branch.

git branch --v -a

*Specifying the –verbose option twice reminds me of old school text-adventure games where you’d have to look twice in the same location to find a second item. If you thought to do that, you’ll get a bonus or something. Now I might have to search the Git documentation for the common commands to see what other options exist where you have to specify a parameter twice!

 P.S. I can’t find in Visual Studio where to see the upstream branch. You can see all remote branches in the history view, but that’s not quite the same. Perhaps since  in Team Explorer (as far as I can tell) 1. you can’t rename a branch checked out from a remote tracking branch and 2. can’t checkout more than one remote tracking branch, it’s assumed that the upstream branch has the same name as your local branch. That’s my guess.

How to view your branches from the command line – 120

Now that you’ve seen how to do fetches, merges, and pulls from a remote tracking branch within Visual Studio, let’s rinse and repeat from the command line. Personally, it’s been easier to first grasp these concepts using Visual Studio, then rinse and repeat at the command line level.

I have to know the truth behind what the UI is doing 🙂

If you want to view the full list of remotes, similar to the full list shown in Team Explorer – Branches

list of branches in Team Explorer

From the command line, you can do

$ git branch -a

You’ll see the same list (well almost the same list. I’m not sure yet what the remotes/origin/HEAD is doing yet… stay tuned unless someone wants to beat me to the answer in the comments!)

Note how the local branch `for-review` is listed first (which kinda gets blended in color-wise with the command), then master, then the remote tracking branches.

git branch -a from command line

Something that has confused me for a long time until I wrote yesterday’s post was whether “remotes/origin/why-not” was the same as “origin/why-not” or even the made-up “remotes/why-not” (which I don’t think a branch is ever referred to as such). Now that I can visualize what both the command line and Visual Studio are doing, it’s easier to get my head wrapped around these remote tracking branches.

How to deal with a merge conflict when doing a Pull from a remote branch into a local branch in Visual Studio – 119

Suppose this time you have conflicts when you do a Pull, meaning your local branch had a conflicting change that was committed locally (but not yet pushed – see Outgoing Commits 1 in screenshot below) and someone else (let’s say you via GitHub.com UI) made a corresponding  conflicting change on the remote.

Here’s the UI setup in Team Explorer. Click on Pull.

Pull incoming commits

Git halts the pull operation (at the merge portion) when it detects the conflicting changes, as expected.

Resovle the conflicts scary TE screen

From here it should be familiar territory by now. Clicking conflicts brings you to a merge conflict screen.

Resolve Conflicts

Clicking Merge brings up the 3 way merge tool (or choose a take remote  or a keep local). If you go the Merge tool route, make sure you click “Accept Merge” at the top. Gets me every time.

merge tool accept merge button

Once you’ve accepted the merge (or choose to use the remote or local version), click Commit Merge.

Commit Merge in Resolve Conflicts in TE 

Now we have to commit those our resulting merge. Click Commit Staged in Changes pane in Team Explorer.

Commit Staged in Changes in TE

and you’re done! Reviewing the local master history shows the merge commit now as the tip.

master local history

Still thinking re yesterday how a Pull is different than a Fetch + Merge. I guess if you know you want to download changes, but not ready to deal with any potential conflicts at this time (e.g. going offline for a while or got other things to do right now), Fetch is the way to go. If you know you’re ready to start playing with the code on your local branch, then Pull is the way to go, I think.