Hacker News Reader

Comment by tracker1 | Hacker News Reader

I really appreciated that this response was not overbearing, or just raw opinion, and rather compared many of the similarities and differences from mercurial to git, and how they approach similar issues differently.

Honestly, I've struggled in moving from SVN/TFS to GIT, but it's been worthwhile.. having local branching, and being able to work locally is great. I can't really compare this to hg, as I haven't worked with mercurial at all.

The company I work for has moved a lot of its' development to a github enterprise deployment, and it's been interesting. I like git extensions for windows, though it's a bit rough around the edges. It's also a bit limited in terms of VS integration, but I can manage. I think that Tortoise + Ankh was a better combination overall in terms of the polish of the tooling, over what git currently offers.

I tend to now work with a few console windows open, and have been using the command line much more.

View on HN

You should try SourceTree, it's a great Windows and Mac Git GUI client! It's free (as in beer) and also supports Mercurial.

I second SourceTree - if there's something missing that you need, Atlassian are surprisingly responsive to feature and bug reports.

I like SourceTree but it the UI gets clunky and slow within a short period of time. Not sure why, but it usually happens when you have anything more than a trivial number of commits.

Have you tried it in the last few days? After SourceTree got relatively slow for me with the past few updates, the last update actually completely fixed that!

I use SourceTree for git, but I find TortoiseHg is better for mercurial; it's just far more feature complete, with support for almost all mercurial commands and (bundled) extensions.

I'm still somewhat surprised by how poor git gui's are, considering it's the more popular VCS - though SourceTree is certainly one of the better ones.

I was really happy when I heard about SourceTree(back then it was not even released yet) but when it finally came out it was bulky to begin with.

TortoiseHg on the other hand always looked nice and clean.

Or for many of the world's desktop Linux developers who use Eclpipse, EGit is quite good and also free. Oh, and it works on Windows, Mac, for that matter just about any Linux platform that supports Eclipse.

Are you kidding!? I found EGit to be extremely buggy, not at all matching git's conceptual model, and difficult to use/navigate. Compared to the hg plugin for Eclipse or gti's command line it is light years behind. The only thing I use it for is viewing the history of a single file.

SourceTree is good if you can handle the .NET 4.5 requirement. At work, we can't risk the breakage 4.5 can possibly do to 4.0 apps and can't force customers to upgrade for 2/x applications so I don't bother.

My first foray into DVCS was Mercurial through Kiln and subsequently TortoiseHg. It's always been great but the introduction of the workbench made everything gel. Having all of the UI in one spot made the experience that much easier. It makes discovery pretty simple compared to TortoiseGit/SVN where you have to know what each menu item maps to.

I've since moved to GIT for work and personal use. GIT flow sold me as hg flow really didn't feel equivalent. I also like submodules as they make proper segregation that much easier. Hg has patch queues which made working on items that weren't commit ready easy. At the time, I didn't understand feature branches so I should likely revisit Hg earnestly. Hg has always had a better user experience where error messages aren't cryptic but there's a wealth of knowledge online to solve any problem in either DVCS at this point. There's some spots in git where you still need the command line where TortoiseHg seemed to cover every need I had.

TFS finally supporting git as a repository, despite its caveats (convert once, only vs2012+) will likely push git pretty far. Having used Ankh, I was never impressed. I'd rather use tortoise + git source control plugin or git extensions as the experience is definitely sufficient. I actually prefer the tortoise workflow over doing it all in vs though but there's a bulk of what we do outside of vs anyway so being proficient there helps tremendously.

Have you tested 4.5? What breaks?

A significant problem is that once .NET 4.5 is installed, a developer can no longer test how an app behaves under .NET 4, even if the app still has its target framework set to .NET 4.

There are several major WPF bugs fixed in .NET 4.5; developers will no longer encounter those bugs locally, but can only find them on a dedicated .NET 4 testing machine, or (more likely) reported from a .NET 4 customer in the field.

There's a detailed writeup of the problem here: http://social.msdn.microsoft.com/Forums/vstudio/en-US/c05a8c...

My normal workflow with git is through the cli. Cli really is the best way to use it since git is good at prodding you along to do the right thing. Make sure to go find a good set of aliases and turn on git prompt.

When I need to look at histories or large change sets I'll open up SourceTree or go to the BitBucket repos. If I need to see the file history of a single file gitk -p -- file is the quickest way that I have found.

I'm currently dealing with 2 projects that are similar and share code but are in different repos. Git has made it easy to add remotes to each project and cherry pick commits that need to be shared. As someone who started with VSS years ago, Git continues to amaze me with how easy it makes source wrangling.

What is "git prompt" and how do I turn it on? A quick search didn't reveal anything.

I think the parent is meaning something like the git-status integration of e.g. oh-my-zsh [0], or something like the 'official' git-status integration script for bash [1]

(I've used the former, but not the latter.)

[0] https://github.com/robbyrussell/oh-my-zsh [1] https://raw.github.com/git/git/master/contrib/completion/git...

Add this to wherever you setup your bash prompt:

source /usr/local/git/contrib/completion/git-prompt.sh

source /usr/local/git/contrib/completion/git-completion.bash

GIT_PS1_SHOWDIRTYSTATE=true

export PS1='\u@\h \[\033[01;34m\]\w\[\033[00m\]$(__git_ps1 "\[\033[01;33m\](%s)\[\033[00m\]")$ '

source ~/.profile

What this does is add a git style prompt anytime you are in a directory managed by git. On the prompt it will show your current branch, what state it is in (+'s/*'s show if you have changes), if your are merging/rebasing/cherry-picking/etc...

The source files may live in slightly different places on your machine depending on where you installed git.

This above also adds tab completion for git commands, branches, tags, etc...

Also, see my .gitconfig for aliases I have put together from various places on the net:

https://github.com/matwood/cfg/blob/master/.gitconfig

I use TFS at work and Git at home - I do miss Visual Studio's merge features which have been greatly improved in 2012 and 2013. How did you get your head around resolving merge conflicts in Git?

it's not too bad in git. you just look at the merge conflict markers in each of the files specified, delete or merge what you want in each of the files, then add the changes to the staging area, and commit again to complete the merge.

this might help: http://stackoverflow.com/a/7589612

and this: http://git-scm.com/book/en/Git-Branching-Basic-Branching-and...

Even better, one can specify a mergetool in their config, and use a standard diff tool to resolve conflicts.

At work, my Git repos are exclusively C# and I've been using SemanticMerge [1] for resolving conflicts to good effect.

[1] https://www.semanticmerge.com/

It's a pity they're a subscription and also they want me to log in to view the pricing.

Edit: There is a once-off price and also somewhere to apply if you're working on open source.

It's as easy as searching for ">>>>" in your text editor; the conflicts will be clearly marked and you take the markers out and make the merged code look the way you want it.

Or use my favourite conflict program p4merge

Reply on news.ycombinator.com