Git status Windows Explorer icon overlays #722
Comments
It's certainly not impossible, but it'll require some work from you, since there are quite a few other issues and this is not exactly nescessary to work with Git. I like this concept, though (VS2013 has similar icons on project files in a Git repository and they are really usefull). We have other shell extensions (namely "Git bash here" and "Git GUI here"), so I don't see a reason against adding some more. You'll want to open a pull request against build-extra. You can find an example on integration of shell extensions into the Git for Windows setup here and here. To get started on icon overlays you can have a look at this, this, this and this. Do you think you can do this? The "Git veterans" are usually there to help you if you get stuck, or to review some of your code, so you're not completely alone on this, but you'll have to put some effort into this. I know, some grown structures of this project are a little overwhelming in the beginning, but you can find into this. If you have questions, just ask. If you want to share some unfinished code, open a pull request and mark it as [WIP] or [Do not merge yet]. |
|
Awesome! Yes. I can handle the learning curve. There are a number of constraints on my time, but if that's okay I'd be happy to do the work. |
That's fine. This isn't some kind of critical issue that stops thousands of people from working. :) |
|
It looks like in the shell extension example the code for the shell extensions is actually in the git repo. Is build-extra the best repo to contain the code I write for the icon overlay extension? What directory should I put the code under? Also, I'm used to Visual Studio. How should I set up the code? |
@jnm2 that is not quite correct... The shell extension code you rereferenced installs (static) registry entries that then call Git's binaries. All of the shell extension-specific part is in those registry entries, nothing of that is done by Git's binaries. They are simply the targets. What you are looking for is a real shell extension, not just a bunch of registry entries. Registry entries cannot call out to Git and ask, say, whether a given file is tracked in Git, whether it is modified or up-to-date, etc. We did include a real shell extension with Git for Windows 1.x, called Git Cheetah, but we stopped maintaining it due to lack of contributors/maintainers. Feel free to start from there.
I am afraid that you will have to get used to the command line a bit in order to work on Git or Git Cheetah. Unless you are willing to do the heavy lifting of getting things into Visual Studio (and maintaining the project, as the main development will still happen within Git for Windows' SDK). |
They are real shell extensions, they just don't need any code, because they are just simple context menu entries. Icon overlays are indeed more complex and require code.
I linked you to an example on how to integrate the shell extensions into the setup. It's in the
Yes, I don't see a reason to put this into
I think one |
I would prefer it to live in its own repository. |
Ok. Just for clarification, which of the following situations are you aiming for?
You're probably right though, because it seems we'll need one class per icon overlay (folder contains repository, file is unmodified, file is modified, file is newly added). |
I vote for the fourth option: fork Git Cheetah. It already has all the code to implement a dynamic shell extension. The icon overlay idea is mentioned in the TODOs, but nobody was interested enough (yet) to provide an implementation. |
|
I like the idea of having a separate repo, owned by the Git for Windows team. Also makes sense to reuse Git Cheetah. However I am not interested in anything except icon overlays, so it seems that would mean Git Cheetah is completely redefined to be only shell overlays and nothing else. Is that something you want to have happen, or would you want to resurrect everything Git Cheetah used to be as well? Also I am only interested in supporting Windows Explorer, which would further limit Git Cheetah from what it used to be. I wouldn't want people to expect what I'm writing to be Git Cheetah. Now if you want to resurrect Git Cheetah I wouldn't mind collaborating on Git Cheetah and being the one to write the shell overlay code, but I don't have the resources to handle the entire project. |
|
The finder part of Git Cheetah is limited to OS X versions before 10.6 and it would need a major rework to work on a modern-ish OS X so I'd say we can drop it. Nautilus is still alive and well, but I don't think many people use(d) Git Cheetah in Nautilus. Those who want Git Cheetah for Nautilus or OS X can still download the old version from the msysgit repo. I don't think reviving the old extended context menu integration is nescessary. |
|
I am not really interested in a shell extension that only does icon overlays. Having said that, it would be easy enough to fork Git Cheetah, rip out all of the context menu stuff (and maybe also rip out all of the MacOSX stuff, but... why? Why touch something that is not compiled on Windows, anyway?), add the icon overlays and be done with it. It would also be relatively easy to hide this icon-only version behind a Makefile variable (so that the default would be to build a fully functional shell extension, including icon overlays), and I would gladly accept a Pull Request with that work. |
Adding a new Git Cheetah repository under the Git for Windows organization that contains code for
I understand your concerns, but I don't think we should mix and match the current lightweight context menu integration with the old context menu integration. I would prefer combining the current context menu integration with the new icon overlays. I had a look at the
I'm assuming "Property page" is intended to be something like HashCheck's checksums page, but with Git information like a file history or information about the last commit that changed this file. |
Exactly. Therefore I have no intention of forking Git Cheetah into the Git for Windows organization (or moving it there).
Well, everybody who forks Git Cheetah's repository can do with it what they wish... 😀 To reiterate, though: I do not think it would provide for a good user experience to include a shell extension with Git for Windows that only provides icon overlays. Users rightfully expect Git's actions to be available via context menus. Nothing stops @jnm2 from making his own, icon-overlay-only shell extension, and using it in his setup, of course. |
I am thoroughly confused at this point. It would be a waste for me to write this for my own setup. My question is whether Git for Windows see icon overlays as in scope, because I would like to see it in the Git for Windows installer. After being asked to help, I'm happy to but I don't care whether it's a separate component or part of another component with other shell features or which repo it is part of.
The goal is an installer checkbox that says, My only constraint is that I don't have the resources to implement a replacement that does any more than icon overlays. I get that long-term, you want Git actions in the context menu. Are you saying that I should not contribute icon overlay code until such a time as you achieve parity with Git Cheetah with your own Git for Windows shell extension?
Users don't expect that today, do they? Today's Git for Windows doesn't have any Git actions as context menu options, nor would I use them! This is just me but I prefer dropping to the command line to run a series of commands, every time. If there were installer options to add Git actions to the context menu I would uncheck them. (As you'd agree, that shouldn't prevent me from using icon overlays.) |
Understandable. I personally would be fine with a default off option to add shell overlays via Git status. So long as the contributor promises to maintain it, supporting all versions of Windows Git supports (or at least maintaining the installer such that unsupported versions of Windows are not offered the overlay support). I believe @dscho primary concern is a new feature, brought with enthusiasm and joy, results in the project maintainers being left to support a non-core feature after the contributor disappears (ala Git Cheetah). |
Sure, but not without a proper shell extension (including context menus a la TortoiseGit), as I believe that users would reject a shell extension that only touched the icon overlays.
Happily, Git Cheetah provides context menus already. It just needs a bit more love, and probably a maintainer.
If you wanted to write a shell extension from scratch, rather than extending Git Cheetah, I would totally agree that it is a waste of your time.
Me, too, also to determine which files are up-to-date an which are modified/added/whatever. But that's just me. That's not the majority of Git for Windows' users. |
Abandoning everything under the MSysGit organization, marking it obsolete and reviving Git-Cheetah there 8 months later doesn't seem much saner to me.
I'm not sure it's justified to rightfully expect things like this. I really do prefer the lightweight context menu integration we currently have and think registry only is the correct way to do context menu integration.
I prefer the command line for complex tasks and using a fully fledged GUI like Git GUI or Sourcetree for simple tasks like everything Git Cheetah can currently do + some more like fetching, pulling, pushing, stashing, viewing tags, creating tags and many more features Git Cheetah is lacking. I honestly don't see a reason to switch branches inside the windows explorer if I can't do more with those branches and commits.
I hope we can reach that goal, as long as the icon overlays don't depend on the context menu integration. I don't think we have to worry too much about unsupported versions of Windows, this seems to work back to Windows 2000. My preferedsolution for this would be one checkbox for 'simple context menu integration', one for 'extended context menu integration' and one for 'icon overlays'. I don't care if they are default on or default off, but they should remember their setting from the installation of the previous version. In the end it's of course up to @dscho to decide the course he wants this to take. |
|
Just want to throw out there that the current shell extensions (Git bash here and Git cmd here), my proposed extension (Git status overlays), and Git Cheetah/whatever @dscho would like to see, can each be cleanly and individually maintained. We are envisioning distinct checkbox options in the installer and distinct, self-contained functionality that goes with each checkbox. So why not go ahead and add the shell extension for the overlays and its installer checkbox since we have a guy that's willing to maintain that, and let the shell extensions we already have (Bash here and cmd here) stay separate from that as they currently are, and when Cheetah or its replacement shell extensions are ready they can light up in the future, separate from the others as they currently are. It sounds like the people in this thread would not use any of the Cheetah stuff but would use the other shell extensions. |
|
TBH right now, if anybody wants icon overlays that reflect the files' status as per Git, they can already install TortoiseGit, which exists, and is well-maintained. Sure, it does more than you want, but you can safely ignore those context menu entries. As to mentioning Git Cheetah: as the original author, I know how much time it took to start this shell extension. My mentioning Git Cheetah tried to help get started with the icon overlays. I still do not see any particular benefit in a shell extension that only provides icon overlays, but then does not let the user perform real simple Git actions via the context menu (such as Stage, Remove, Blame, etc). That sounds just really counter-intuitive to me. And I can already see the bug tickets (should we really ship such a icon-overlay-only shell extension) asking "Why can't I do these things with your shell extension? Why don't you bundle TortoiseGit instead, it doesn't suck?" because such reports are invariably written using decent and pleasant words. |
A lot of people already have a lot going on in their context menu and I've heard the sentiment that they want to keep it as clean as possible. I'm one of them. Also, besides workflow criticism, I don't even want TortoiseGit on my system. It's too heavy. The particular benefit that I mentioned with icon overlays is being able to see at a glance what is going on, even if I'm not planning to make a change with Git. It's about being able to take in a bulk amount of low-cognitive-load, strongly contextual information while browsing that I may or may not act on, and only dropping to the command line using In other words, if I'm browsing Explorer, I most definitely do not want to be dropping to the CLI. If I need to make a change, I most definitely do not want a UI.
If people's mental image of a shell extension is context menu and UI, then I'll stop using the phrase in either sense. My original question has nothing to do with that. In installers where you have the option to show thumbnails for the program, it's not, "Do you want to install a separate shell extension?" it's, "Do you want to see thumbnails?" I don't want a shell extension, I want to see icon overlays. I'll bet I'm not the only one. |
Same thing. If you want icon overlays that change dynamically, you want a shell extension. |
|
Yes. I was referring to "If people's mental image of a shell extension is context menu and UI." |
|
For the record, I agree with @dscho with respect to icon overlays and their availability with Tortoise Git. I used to use Tortoise Git myself when I was first starting out with git. But one thing that infuriated me were the very shell extensions themselves. Sure, they're nice and pretty-looking if you spend a lot of your time in the Explorer shell (which I used to when working with Git, hence my installing Tortoise Git), but when you have a moderately sized repository with more than just a handful of changes, these shell extensions slowed down the whole machine. At this point, I began asking what the point of Tortoise Git was if it made my machine slow--because I'd end up "dropping down" to the command line anyway. And once I learned the command line, it wasn't so bad; actually, I never want to go back to a GUI (other than for the very infrequent branch visualization; and Atlassian SourceTree does a much better job of that than even Tortoise Git). If you really want Explorer shell icon overlays, like @dscho suggests, use Tortoise Git, and in addition, you'll get a whole lot more Explorer Shell extensions than just icon overlays. For those who use the command line, knowing what's staged, changed, and/or new/untracked in your current branch is a simple command away: |
@jnm2 just to make things utterly clear: if you want icon overlays that are dynamic, i.e. some icon overlay if a file is tracked and up-to-date, another one if the file is tracked and modified, etc, I am only aware of one way to do that: implement a shell extension. And if you want to go that route, I suggested to use Git Cheetah as a basis. I only suggested this so you could save time because it took me quite a while to figure out how to build and test shell extensions, back when I started the Git Cheetah project. As it is, I managed to waste all of our time by being not clear enough. To stave off more lack of clarity: I am not interested in adding support for a shell extension of any kind to the Git for Windows installer (other than we have right now) unless it is a shell extension that is
Now, if you, @jnm2, decide that you want your own shell extension that does not sport any context menus but only icon overlays, then you are very welcome to make that happen. Starting from Git Cheetah's source code should give you a head start so that you can have something working within a weekend or so. I encourage you to do that for your own pleasure (and not so much expecting that it will end up in the Git for Windows installer eventually). As I feel that this ticket is addressed as far as Git for Windows is concerned, I hereby close it. (But feel free to continue the discussion should you want to add your opinion, or to ask questions about Git Cheetah's approach). |
I spend a lot of time in Windows Explorer around git repos. The only thing I miss with Git is being able to see at a glance which folders contain source-controlled files, which files are untracked and which are modifications. It allows me to rapidly take in what I can change and how it will affect the repo without reading the gitignore file or working by trial and error.
The only tool that currently does this is TortoiseGit which is definitely not something I want to install. I don't like the premise of TortoiseGit in particular and in general I don't want to perform any Git operations from Windows Explorer, ever. Just the command line. But it would be awesome to have the optional feature of a readonly shell extension that just gives the visual boost of status icon overlays.
Is this in the potential scope of Git for Windows?
The text was updated successfully, but these errors were encountered: