StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
3313897
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
6
CommunityOwnedDate
CreationDate
2010-07-22T22:08:34.900
FavoriteCount
0
LastActivityDate
2016-03-25T06:49:15.620
LastEditDate
2016-03-25T06:49:15.620
LastEditorUserId
170656
OwnerUserId
170656
ParentId
3313561
PostTypeId
2
Score
27
ViewCount
0
LastEditorDisplayName
text
Body
EDIT: So it's 2016, six years on from when I wrote the original answer below. I've used git and mercurial heavily for several years now, and I've been developing on a mac for several years too. I've become very familiar and comfortable with git usage on the command line, but for day-to-day work I use SourceTree from Atlassian. This is not an advertisement, just a note to update this answer. SourceTree is a double abstraction: the same ui for for git/hg, and the same ui for Windows/Mac. When you have to switch platforms and projects often, this becomes very attractive. Having written <a href="http://code.google.com/p/tortoisegit/wiki/HOWTO_CentralServerWindowsXP" rel="nofollow noreferrer">a guide to setting up both client and server for Git on Windows</a>, I have a pretty good idea of what one can expect. Also, my primary repository (<code>.git</code> folder) is ~260MB of source, so it is really not a trivial performance test for day-to-day Git work on Windows. My general impression is that Git on windows is very fast for the vast majority of situations one is likely to encounter, with one really huge exception: <code>git gui blame -C -C</code>. By default, git will not blame on files beyond file rename boundaries, and the extra <code>-C -C</code> arguments must be passed to enable that to happen, but then things can really slow down. It takes 17 minutes on modern hardware to produce a complete annotation of one of our larger ~20 kloc source files. That delay can really break your concentration. <h2>Regarding <a href="http://www.cygwin.com/" rel="nofollow noreferrer">cygwin</a>:</h2> I only tried this once, and not for anything significant. I really wanted a native solution. By all accounts, git on cygwin works well enough. <h2>Regarding <a href="http://code.google.com/p/tortoisegit/" rel="nofollow noreferrer">TortoiseGit</a></h2> Frank Li has done tremendous work bringing the now-familiar UI to the Git world. TortoiseGit started up very quicky because most of the UI was available from TortoiseSVN (and other tools like TortoiseMerge), and I have worked with this interface a great deal. In general, it allows one to get going with Git very quickly if you are familiar with TortoiseSVN. The developer has gone to great pains to use terms from the TortoiseSVN world and map them to git commands. For instance, a revert really performs a <code>git checkout <file></code> under the hood. In general, working with Git this way has been pretty seamless, and I must admit to having learned Git while using the TortoiseGit interface: and it must be conceded that this was a hindrance to my education. The TortoiseSVN-like log viewer doesn't really work for a distributed-vcs workflow (it works well enough it you use Git as if it were SVN), and you only find this out later because the problems only come in when there are many, many development branches (the <code>gitk</code> tool is much better at handling this display). And the other issue is that even after using TortoiseGit for many months, I still didn't know even the most basic git commands. There is nothing really wrong with TortoiseGit, and bugs get fixed impressively quickly when they do occur; the main problem seems to be a design issue (possibly more than one) in the UI, something that the <code>gitk</code> and <code>git gui</code> developers have worked out because of a longer development history, or a more intimate knowledge of idiomatic git usage, or something like that. <h2>Regarding command-line use:</h2> The <a href="http://code.google.com/p/msysgit/people/list" rel="nofollow noreferrer">MSYS git development team</a> are the ones who really should be thanked for even bothering to do all the work they did, and without their support it is likely the mingw git branch would never even have been merged with mainline. I have now begun using msysgit, as is, in the Git Bash shell, as my only git interface for a few weeks. My impression is that, although the initial learning seems more difficult, once that knowledge has been gained, everything else becomes easier. <a href="http://cheat.errtheblog.com/s/git" rel="nofollow noreferrer">This reference</a> is, in my opinion, one of the really better references learning git on the command line. Speaking as a Git user on Windows, and coming from an extended experience using the TortoiseGit interface to git, this is a summary of my workflow, which covers >95% of what is needed (all in Git Bash, not the Windows command shell (cmd)): <ul> <li>Check for Modifications <blockquote> git status </blockquote></li> <li>Switch branch <blockquote> git checkout some-feature-branch </blockquote></li> <li>Fetch <blockquote> git fetch </blockquote></li> <li>Show Log (the <code>&</code> detaches the <code>gitk</code> process from the shell, so that the shell doesn't wait for <code>gitk</code> to be closed before allowing more commands) <blockquote> gitk & </blockquote></li> <li>Commit: either <ul> <li>Simple commit: <blockquote> git commit -a -m "This is my commit message" </blockquote></li> <li>Complex, multiple successive commits: <blockquote> git gui </blockquote></li> </ul></li> <li>Push to branch: master <blockquote> git push origin master </blockquote></li> <li>Merge (e.g. after Fetch) <blockquote> git merge origin/master </blockquote></li> </ul> I haven't had to do any conflict-resolution yet, but I'll figure that out when the time comes (comments welcome :). EDIT: For conflict resolution, kdiff3 is the way to go. Setup is simple, and everything from simple diffs up to three-way merge works reliably and swiftly. <h2>Conclusions</h2> <ul> <li>Git on Windows is full-featured, and works as advertised, and is not limited on Windows.</li> <li>Performance is generally very good, but comprehensive large blames might be slow.</li> <li>The TortoiseGit interface is seductive, but ultimately unsatisfying: you should try to learn git on the command-line. I have done both, and this route is more efficient.</li> </ul>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWhat are the limitations of Git on Windows?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USCaleb Hattingh
UserOwnerUserId
1. USCaleb Hattingh
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POWhat are the limitations of Git on Windows?
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.