{"action":"created","issue":{"url":"https://api.github.com/repos/atom/tree-view/issues/913","repository_url":"https://api.github.com/repos/atom/tree-view","labels_url":"https://api.github.com/repos/atom/tree-view/issues/913/labels{/name}","comments_url":"https://api.github.com/repos/atom/tree-view/issues/913/comments","events_url":"https://api.github.com/repos/atom/tree-view/issues/913/events","html_url":"https://github.com/atom/tree-view/pull/913","id":169813270,"number":913,"title":"Use colors to indicate git status","user":{"login":"pbiggar","id":181762,"avatar_url":"https://avatars.githubusercontent.com/u/181762?v=3","gravatar_id":"","url":"https://api.github.com/users/pbiggar","html_url":"https://github.com/pbiggar","followers_url":"https://api.github.com/users/pbiggar/followers","following_url":"https://api.github.com/users/pbiggar/following{/other_user}","gists_url":"https://api.github.com/users/pbiggar/gists{/gist_id}","starred_url":"https://api.github.com/users/pbiggar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pbiggar/subscriptions","organizations_url":"https://api.github.com/users/pbiggar/orgs","repos_url":"https://api.github.com/users/pbiggar/repos","events_url":"https://api.github.com/users/pbiggar/events{/privacy}","received_events_url":"https://api.github.com/users/pbiggar/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/atom/tree-view/labels/needs-review","name":"needs-review","color":"bfe5bf"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2016-08-07T19:59:23Z","updated_at":"2016-08-11T20:13:31Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/atom/tree-view/pulls/913","html_url":"https://github.com/atom/tree-view/pull/913","diff_url":"https://github.com/atom/tree-view/pull/913.diff","patch_url":"https://github.com/atom/tree-view/pull/913.patch"},"body":"Currently, the coloring of status in tree-view makes it very difficult to understand the git status of files. For example, changed files (to use the git meaning of the term) are shown the same as updated files, while added files are shown differently.\r\n\r\nFor example, for a repo in this state:\r\n<img width=\"254\" alt=\"screenshot 2016-08-07 12 39 27\" src=\"https://cloud.githubusercontent.com/assets/181762/17464819/99b95652-5c9c-11e6-8a3e-efed1b068d95.png\">\r\n\r\nThis is what tree-view tells me:\r\n<img width=\"202\" alt=\"screenshot 2016-08-07 12 41 14\" src=\"https://cloud.githubusercontent.com/assets/181762/17464822/a381c5fc-5c9c-11e6-80b8-fb8bb8f19f93.png\">\r\n\r\n\r\nThis is because tree-view doesn't differentiate between whether a file is in the git index or not. It's best shown in the current code:\r\n\r\n```coffee\r\n     if repo.isPathIgnored(@path)\r\n      newStatus = 'ignored'\r\n     else\r\n      status = repo.getCachedPathStatus(@path)\r\n      if repo.isStatusModified(status)\r\n        newStatus = 'modified'\r\n      else if repo.isStatusNew(status)\r\n        newStatus = 'added'\r\n```\r\n\r\nBasically, the status can be status-ignored, status-modified, or status-added.\r\n\r\nThis isn't particularly useful if you use git, as I'm sure you all do. I find myself going to the command line frequently to figure out the actual status of my files. In particular, I find it very hard to make partial commits (dissecting my changes into multiple logical commits) as I constantly have to switch into the command line and back.\r\n\r\nThis is particularly annoying given that tree-view is one of the areas pointed out as \"git integration\": http://blog.atom.io/2014/03/13/git-integration.html. I thought perhaps that status-modified and status-added had different meanings, but it's clear (in the blog post and the code) that they are supposed to represent git.\r\n\r\nI initially tried to make this a package, but none of the APIs were exposed and it involved a lot of fighting (races and CSS specificity mostly), and this felt like this was a bug in tree-view as opposed to a nice extra, hence making this change here.\r\n\r\nOK, done with the justification, onto the changes.\r\n\r\nFor the same repo as above, here's what this looks like:\r\n<img width=\"204\" alt=\"screenshot 2016-08-07 12 51 30\" src=\"https://cloud.githubusercontent.com/assets/181762/17464944/e41d463e-5c9e-11e6-9c2f-33034be8abea.png\">\r\n\r\n\r\nAs you can see, while you can't tell anything in the current version of tree-view, with these changes you can really see the git status quite well.\r\n\r\n\r\nInstead of taking a distillation of the the git status as it currently stands, these changes expose the actual git statuses, taking into account that some changes are in the index and some are not. It takes the git status code, analyses it to break the changes into 5 major statuses, which mirror git config's names for them (see color.status.<slot> in https://git-scm.com/docs/git-config for discussion):\r\n\r\n- status-added\r\n- status-updated\r\n- status-changed\r\n- status-unmerged\r\n- status-untracked\r\n\r\nAnd then some extras (which also come from the git status code):\r\n- status-conflicted\r\n- status-unmodified\r\n- status-ignored\r\n\r\nI also added styling (well, colors) for the statuses. I use the colors from `@ui-variables` - is that portable across themes? Styling currently seem to be handled by themes, but I added defaults so that we can ship this and let the themes catch up (we can remove the colors later if needs be). \r\n\r\nNote that files can be in two statuses at the same time. For example if you `git add` a file, then edit it afterwards, then the file will be both status-updated and status-changed. In the git CLI, this is displayed as a green M followed by a red M. To try and represent this here, I used a gradient. It looks quite pretty 😄. \r\n\r\nFor directories, I cut it down to status-ignored, status-changed, status-conflicted, status-updated, status-unmodified. I'd appreciate feedback on this (well on anything, but esp on this :)).\r\n\r\nI've fixed existing tests (except one, I'll be working on that soon). I also have more tests to write. Would love suggestions on what things people worry about here.\r\n\r\nI'm not sure about status-conflicted. AFAICT, when a file is conflicted, it will have other statuses to indicate how the conflict happened. I choose to use status-conflicted instead of trying to represent those statuses, which I think makes the most sense. This bubbles up to directories: a directory is conflicted if any files in it are. However, I use the same color for conflicted (red) as for untracked, so maybe I should add italics or something. Suggestions welcome.\r\n\r\nIdeally, some of this code should be moved to git-utils. git-utils doesn't expose much right now. That might be a nice followup, but it feels like a bad idea to try and make the change in git-utils first, without a downstream consumer, and it seems easier and more productive to get this into tree-view first. That's why I didn't refactor the git status code too much. Happy to revisit this if you folks don't like. (I will say that after many years of contributing code to multi-repo projects, I feel there's a real risk of being asked to make the change upstream first, and then being told that there's no consumers yet, so make it downstream. I would really like to avoid this 😄) \r\n\r\nThere is some eventing code that will now receive an array instead of a status. It's undocumented so I presume that not much uses it (I tried to use it in my package and it seemed flaky, but hard to tell). It doesn't break any of the other git tools I use, but if there's a better way to address this, I'm all ears.\r\n\r\nFor some reason, status-unmodified is never reported. I'm looking into that now, but since I don't style it, it makes no functional difference for now.\r\n\r\n~~Currently, the selected file (in one-dark-ui at least) doesn't show the status color. I think we should change that, but I'm not sure how. Punting for now.~~ NVM, this seems to work fine :)\r\n\r\nOK, I think that's everything. Would love as much feedback as possible before I invest a lot of time in testing it :)\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/atom/tree-view/issues/comments/239277771","html_url":"https://github.com/atom/tree-view/pull/913#issuecomment-239277771","issue_url":"https://api.github.com/repos/atom/tree-view/issues/913","id":239277771,"user":{"login":"50Wliu","id":2766036,"avatar_url":"https://avatars.githubusercontent.com/u/2766036?v=3","gravatar_id":"","url":"https://api.github.com/users/50Wliu","html_url":"https://github.com/50Wliu","followers_url":"https://api.github.com/users/50Wliu/followers","following_url":"https://api.github.com/users/50Wliu/following{/other_user}","gists_url":"https://api.github.com/users/50Wliu/gists{/gist_id}","starred_url":"https://api.github.com/users/50Wliu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/50Wliu/subscriptions","organizations_url":"https://api.github.com/users/50Wliu/orgs","repos_url":"https://api.github.com/users/50Wliu/repos","events_url":"https://api.github.com/users/50Wliu/events{/privacy}","received_events_url":"https://api.github.com/users/50Wliu/received_events","type":"User","site_admin":false},"created_at":"2016-08-11T20:13:31Z","updated_at":"2016-08-11T20:13:31Z","body":"Yes it does.  We have a large backlog of PRs so there's large fluctuations when it comes to how fast each PR is reviewed."}}
{"actor":{"display_login":"50Wliu"}}