Posts Tagged ‘scm’

TortoiseGit – round 2, fight!

April 22, 2010 2 comments

For some odd reason, I’ve gotten my head wrapped around TortoiseGit and hence this follow-up post.

Cloning a public repository successfully is neat… but not exactly useful.

So, for this post I’m going to try a couple of tricky things in rapid succession:

  1. creating conflicting changes in a clone that I have to resolve when I push
  2. create two radically different changesets consistent with two sparring developers

And if I get really creative, maybe I’ll try to clone an SVN repository just for the heck of it.

First things first.

Cloning my local repo was trivial, and not worth detailing. I created two conflicting changes, one in the master and one in the cloned repo. Committed in the clone with no issues, then hit the “push” dialog.

I was expecting some kind of error, or perhaps a merge dialog to pop up – but instead I got the following very confusing error message.

git.exe push “origin” master:master

To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the ‘Note about
fast-forwards’ section of ‘git push –help’ for details.
To C:\Users\foo\Downloads\hg-git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to ‘C:\Users\foo\Downloads\hg-git’

As a complete and total git newbie, I found this error message very confusing. What is a fast-forward update? I actually missed the “merge the remote changes” message the first time through. This dialog is not very useful – why not list the log message of the remote changes that need to be pulled? This would be much more user friendly. At the very least, it should pop up with a button to pull & merge.

Hmmm… what to do next.

The dialog says I need to merge, but I seem to remember reading something about pulling before a merge.

How about TortoiseGit->Pull?

The result is shown below in the following image.

Wow, that is not only confusing, but downright useless.

Unless I completely missed something, there’s no easy “edit conflicts” button that pops up the 3-way merge tool. I actually had to search around for a bit to figure it out. You can either right click on a file and then select TortoiseGit->Edit conflicts, or you can use the “Check for modifications” link to show a list of all changed (and conflicting) files.

OK, so I edited the conflicts, then committed them to my local clone. Now what happens if I push?

git.exe push “origin” master:master

remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require ‘git reset –hard’ to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set ‘receive.denyCurrentBranch’ configuration variable to
remote: error: ‘ignore’ or ‘warn’ in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: ‘receive.denyCurrentBranch’ configuration variable to ‘refuse’.
To C:\Users\foo\Downloads\hg-git
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to ‘C:\Users\foo\Downloads\hg-git’

Wow, this is so lame I’m almost ready to give up on git.

At this point, git is zero for two on the user friendliness scale. So far my googling for the many error messages in this git-barf just turn up more of the same – I can’t push from master -> master on a local repository. Which is completely and totally not helpful, and doesn’t make any logical sense.

It’s getting late, so I’ll post back when I git this figured out (ha ha very punny).


Categories: Uncategorized Tags: , , ,

First Impressions of TortoiseGit

April 21, 2010 Leave a comment

This will be a really short post, I recently installed TortoiseGit and wanted to post my first impressions.

I’ve been a long time SVN user, with a fair amount experience using TortoiseSVN. TortoiseSVN is about as good as it gets when it comes to getting out of the way and letting you get your actual work done. I have a lot of good things to say about TortoiseSVN, but let’s face it – it’s just a GUI front-end for SVN.

I’m going to skip the debate about centralized vs distributed revision control — the ‘net is full and overflowing with opinions, debates, misinformation, and evangelism on both sides. At the end of the day, SVN (darcs, Mercurial, git, bazaar, perforce, etc) are just tools to manage changes to source code. Each has it’s own strengths and weaknesses, so I won’t bore you by repeating these pros/cons here.

What I really wanted to write about was my first impressions with using TortoiseGit, which is a Tortoise clone for git. I’m coming at this from a complete newbie’s perspective – I’ve only cloned one git repository before, and it’s been a while.

First things first: install TortoiseGit. No issues here, the installer runs and within a minute or so I’ve got explorer integration working. An annoying artifact of running Windows is the constant reboots – sure enough, TortoiseGit wants me to reboot before it’s fully working. Argh. I didn’t want to reboot, so I put this on hold or a day or two until my next natural reboot.

Now, let’s clone a repo.

Right click in windows explorer, click on “Git Clone” — oops! Got a dialog box of death, looks like I forgot to install msysgit. A download/install later, and now TortoiseGit pops up the clone dialog.

The SVN checkout and git clone dialog look pretty much the same, nothing really interesting to see but I’ve included a screenshot here.
svn checkout vs git clone

I cloned, and the clone worked perfectly without any issues. It’ll be interesting to see how well this works from a corporate network, behind a proxy and all that.

Of course, showing the log files works perfectly and gives me all the changesets from initial import.

One thing I really like about the git log is the graph running along the left side – it looks like a depiction of the branching & merging, but I’d have to check into it more to be sure:

I have yet to try anything actually useful, committing / branching / etc — but at first glance, it looks fully capable and functional and I’m excited to get more into it as time permits.

Categories: Uncategorized Tags: , ,