Can you interact with the index/staging area with

Question

I've been tasked with giving a presentation on Git to my colleagues, who are almost entirely Windows users who are used to using TortoiseCVS. I've been using Git for about a year, but I almost exclusively used the Unix command line interface.

So I've been trying to get familiar with the Windows GUI Git tools including TortoiseGit. But it seems to me that this is more than just GUI skin over the Git command line interface, and actually abstract some things completely away, specifically the index.

For instance, when I right click a new, unversioned file in the Windows Explorer, I can select "Add" from the TortoiseGit menu, and later commit this file, but this same menu item is missing from files which are already in Git, in which case I only see the option "submodule add".

Is there no way to interact with the index with TortoiseGit?

I'm looking for analogues to git add, git diff --cached, and git reset HEAD, specifically.

Here's a message to the Google group about this, but it was from last summer.

I'm using TortoiseGit version 1.6.5.0 and msysgit version 1.7.4.msysgit.0, if it matters. I installed these just a few days ago so they are probably reasonably up to date.

Answer 1

The answer is: no, you can't.

For me, TortoiseGit is a tool that you can use to make the transition from – in your case – CVS to Git easier (like I wrote in my answer to Does TortoiseGit actually make Git a lot easier to use like TortoiseSVN?). But once the transition is made and your colleagues get more familiar to Git, it's time to come up with the real tools.

And the most powerful tool to interact with Git is the command line. Period. The Git Gui and gitk are also usable, bring some convenience but lack explorer integration (at least in terms of overlays). But in times with multi headed development boxes: why don't keep the Git Gui open on one monitor (the one used for general management stuff) and work on the other?

I recently also did an introduction to Git in my team at work. We were used to TortoiseSVN, so I also showed them how to add files using Tortoise, how to commit and so on. But on every slide, I also noted what they have to type in the Git Bash to achieve the same result. That way, once they're a little more experienced, they can take out the introduction slides and peek at the commands they have to use.

Answer 2

Recently hit the need of using git add to apply stash when there were changes to the same files and found that I can use it with a trick: have (create) a new file in the repo (.txt for example), open commit window that will show changed files along with the new one. Select all changed files and the new file. Right click on the new file and you will have Add command there. It will apply git add to all selected files. After that you can just Revert the new file. All of that allowed me to apply stash over modified files.

Answer 3

To a limited extent, you can perform those actions within TortoiseGit. For instance, there is a reset dialog. They aren't prominently featured (I think) because using TortoiseGit means you have less need for the git index -- there are convenient and highly functional GUI methods for choosing and reviewing the things you intend to commit, so the index becomes less necessary.

That being said, TortoiseGit brings many useful things to the table for both the beginner and the advanced git user, though it is only a complement, not a replacement, to commandline.

As an additional transition, you might be interested in a batch file I use that blurs the line a little by allowing convenient invocation of those TortoiseGit GUI windows from the commandline: https://github.com/ses4j/tgit

Answer 4

The truth is even worse than the answers so far have let on. I tried an experiment: git add some changes to the index, restore the working tree to match the current HEAD, and run a TortoiseGit commit.

It listed the changed file as one of the files eligible to be included in the commit, so it was aware something was changed, which gives the impression that at least it knows how to finish a commit that's already been staged by another tool. But when I chose it the commit actually used the working tree copy and destroyed the uncommitted data in the index and the commit ended up being a no-op on that file.

A dangerous tool, I think I'll be avoiding it.