{"action":"created","issue":{"url":"https://api.github.com/repos/magit/magit/issues/2717","repository_url":"https://api.github.com/repos/magit/magit","labels_url":"https://api.github.com/repos/magit/magit/issues/2717/labels{/name}","comments_url":"https://api.github.com/repos/magit/magit/issues/2717/comments","events_url":"https://api.github.com/repos/magit/magit/issues/2717/events","html_url":"https://github.com/magit/magit/issues/2717","id":164405384,"number":2717,"title":"Side by side blame","user":{"login":"quicknir","id":10457096,"avatar_url":"https://avatars.githubusercontent.com/u/10457096?v=3","gravatar_id":"","url":"https://api.github.com/users/quicknir","html_url":"https://github.com/quicknir","followers_url":"https://api.github.com/users/quicknir/followers","following_url":"https://api.github.com/users/quicknir/following{/other_user}","gists_url":"https://api.github.com/users/quicknir/gists{/gist_id}","starred_url":"https://api.github.com/users/quicknir/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/quicknir/subscriptions","organizations_url":"https://api.github.com/users/quicknir/orgs","repos_url":"https://api.github.com/users/quicknir/repos","events_url":"https://api.github.com/users/quicknir/events{/privacy}","received_events_url":"https://api.github.com/users/quicknir/received_events","type":"User","site_admin":false},"labels":[{"id":33046,"url":"https://api.github.com/repos/magit/magit/labels/feature%20request","name":"feature request","color":"079400","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/magit/magit/milestones/22","html_url":"https://github.com/magit/magit/milestones/3.1.0","labels_url":"https://api.github.com/repos/magit/magit/milestones/22/labels","id":1282778,"number":22,"title":"3.1.0","description":"- Implement new collaboration tools\r\n  - Tight integration with gnus and/or mu4e for patch handling #1800\r\n  - Tight integration with gnus and/or mu4e for pull request handling #1800\r\n  - Tight integration with github, gitlab, bitbucket etc.\r\n    - Mirror issues as a ref\r\n\t  - Use api to \"fetch\" and \"push\" changes (using git hooks)\r\n\t  - Store each post in separate file, to require fewer manual merges\r\n\t  - Maybe implement the core as a shell-script\r\n      - Implement a variant that does not depend on any of the apis as backend\r\n- Re-implement care abstractions and features\r\n  - Implement minimal viable versions, don't use them in Magit for a while\r\n  - In an initial phase concentrate on \"one thing (log/diff) per buffer\", no window management\r\n  - Create logs asynchronously #2105\r\n    - Create graphs in a second, independent step #1425\r\n\t  - Using vector graphics or unicode box drawing characters\r\n  - Create diffs asynchronously and intelligently #2105\r\n    - Use raw diff output to avoid unnecessary work for collapsed sections\r\n\t- Implement better \"go to same position\" feature #1566\r\n  - Implement section using an object system #2055\r\n  - Implement `transient.el`, the `magit-popup.el` successor\r\n- Implement features I missed while working on v2\r\n  - Implement `git-handler.el`, a file handler for blobs and trees\r\n  - Implement `git-diff-handler.el`, a file handler for changes\r\n- New killer features\r\n  - Blob editing (with automatic rebases)\r\n  - Amend to appropriate commit directly from file-visiting buffer\r\n- Various\r\n  - Improve process buffer\r\n    - Group related output sections\r\n    - Allow sections that don't contain process output","creator":{"login":"tarsius","id":25046,"avatar_url":"https://avatars.githubusercontent.com/u/25046?v=3","gravatar_id":"","url":"https://api.github.com/users/tarsius","html_url":"https://github.com/tarsius","followers_url":"https://api.github.com/users/tarsius/followers","following_url":"https://api.github.com/users/tarsius/following{/other_user}","gists_url":"https://api.github.com/users/tarsius/gists{/gist_id}","starred_url":"https://api.github.com/users/tarsius/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tarsius/subscriptions","organizations_url":"https://api.github.com/users/tarsius/orgs","repos_url":"https://api.github.com/users/tarsius/repos","events_url":"https://api.github.com/users/tarsius/events{/privacy}","received_events_url":"https://api.github.com/users/tarsius/received_events","type":"User","site_admin":false},"open_issues":21,"closed_issues":0,"state":"open","created_at":"2015-08-31T20:25:45Z","updated_at":"2016-11-04T18:07:52Z","due_on":null,"closed_at":null},"comments":12,"created_at":"2016-07-07T20:56:16Z","updated_at":"2016-11-08T04:13:27Z","closed_at":null,"body":"Hello,\n\nI don't know if this idea has already been discussed or not, I tried to search the github issues and didn't see it. Currently, magit's blame puts commit information \"inline\" as I tend to think of it. You get lines that exclusively contain commit information, interspersed with the actual code.\n\nFor source that is the result of relatively few commits, this is absolutely fine. The problem is that as codebases tend to scale up in both size and age, you often see that core files will accumulate many, many smaller commits. To take a concrete datapoint: opening a random core file at a random spot in the codebase I work on, there are 13 commits accounting for 20 lines of code. To provide more interesting metrics: the file is about 1900 lines of code with 74 unique commits. This doesn't seem so bad with over 20 lines per commit on average. But obviously, magit blame needs to show a line of commit info anytime a line is from a different commit than the previous line. According to a quick python script I whipped up, there will be about 800 lines of magit blame info. That means that on average, you will see 2-3 lines of source between magit lines, and some regions will be much worse.\n\nWhat would be really nice (IMHO) is to have the option of pulling up a git blame that is visually similar to fugitive, where the commit info is on the left, side-by-side with the actual code.  This especially makes sense (IMHO) in the modern age of very wide screens. Example: http://minkod.se/wp-content/uploads/2015/05/Screenshot-2015-05-09-20.02.00.png. The original code is untouched, and even still has syntax highlighting. Obviously there are many variants on this; you can apply some kind of effect to either the background or foreground to color lines from the same commit together.\n\nSince the current blame mode obviously already works and is fine for many people/circumstances, this new git blame style could be optional/switchable.\n\nAny thoughts? Fwiw I'm willing to chip in a donation ($20 ?) if it helps get the ball rolling on this commit (I appreciate that one donation isn't a ton, but maybe if other people feel the same then a not-completely-trivial amount can be raised).\n\nEdit: I should mention that vc-annotate can do something like this, but it's not great for other reasons, cannot AFAIK do the neat \"reblame\" thing that's so easy in magit, etc. I'd much rather strictly stick with magit.\n"},"comment":{"url":"https://api.github.com/repos/magit/magit/issues/comments/259041175","html_url":"https://github.com/magit/magit/issues/2717#issuecomment-259041175","issue_url":"https://api.github.com/repos/magit/magit/issues/2717","id":259041175,"user":{"login":"jflombera","id":657025,"avatar_url":"https://avatars.githubusercontent.com/u/657025?v=3","gravatar_id":"","url":"https://api.github.com/users/jflombera","html_url":"https://github.com/jflombera","followers_url":"https://api.github.com/users/jflombera/followers","following_url":"https://api.github.com/users/jflombera/following{/other_user}","gists_url":"https://api.github.com/users/jflombera/gists{/gist_id}","starred_url":"https://api.github.com/users/jflombera/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jflombera/subscriptions","organizations_url":"https://api.github.com/users/jflombera/orgs","repos_url":"https://api.github.com/users/jflombera/repos","events_url":"https://api.github.com/users/jflombera/events{/privacy}","received_events_url":"https://api.github.com/users/jflombera/received_events","type":"User","site_admin":false},"created_at":"2016-11-08T04:13:27Z","updated_at":"2016-11-08T04:13:27Z","body":"@quicknir I still believe the \"single-line-of-info-per-chunk\" approach is better for the sake of readability, of course addressing the requirement of at least one visible line of commit info per chunk that @fice-t pointed out.  Even if the commit hashes are lined up, it still requires mental processing to analyze them.  It is much easier to parse \"visual\" chunks.\r\n\r\nHowever, if it is difficult to achieve (as I pointed out, I am new to Emacs and completely ignore what it takes and how difficult it would be; I completely trust you here), the coloring approach could address my concern as well (although less visually appealing, again still more info/noise to process).  This approach has its own challenges too, for example, which colors to use?  will they be fixed or adjusted to the color theme?"}}
{"actor":{"display_login":"jflombera"}}