www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [RFC] A huge problem with Github diff

reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
Current Github diff is very primitive and is almost like unified diff 
format which isn't for humans at all. This complicates and slows down 
code revision simultaneously reducing its quality.

Something must be done about it to stop wasting people time without any 
real reason.


Possible solutions:

* Instruct reviewers to install SmartGit, KDiff3 or something with human 
readable diff and fetch from repos of pull request senders.
     - Will spend reviewers time.
     - Will not auto-update on pull update.

* Instruct pull senders to also create a pull on bitbucket.org which has 
diff for human beings and push both simultaneously.
     - Will spend pull senders time but not significantly.
     + Will allow code line-comments on bitbucket.org's better diff.

* Move to bitbucket.org
     + Good diff
     - Need to instruct everybody about move
     - Possible lack of some futures (only possible, I don't know any)

* Write browser plug-in to fix Github diff
     - Somebody has to do it.
     - Some browser will not support such plug-in anyway.

* Write stand-alone application to work with Github
     - Somebody has to spend a lot of time for it.

* Write an angry letter to Github support (signed "frustrated D community" )
     + The easiest way.
     - The letter can be ignored.


P.S.
Looks like Github's owners doesn't care at all about current users, only 
abut needless features and GUI glance to involve new ones because 
otherwise I have no explanation of this sad situation.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Nov 14 2012
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 14 Nov 2012 19:27:46 +0400
Denis Shelomovskij <verylonglogin.reg gmail.com> wrote:

 Current Github diff is very primitive and is almost like unified diff 
 format which isn't for humans at all.

I'm pretty sure it basically *is* unified diff format, just with the line-starting +/- chars replaced by highlighting.
 This complicates and slows down 
 code revision simultaneously reducing its quality.
 
 Something must be done about it to stop wasting people time without
 any real reason.
 
 
 Possible solutions:
 
 * Instruct reviewers to install SmartGit, KDiff3 or something with
 human readable diff and fetch from repos of pull request senders.
      - Will spend reviewers time.
      - Will not auto-update on pull update.
 

Personally, I always have my Tortoise* tools set up to use Beyond Compare. Same sort of thing. And yes, vastly superior than the typical Git diff stuff.
 * Instruct pull senders to also create a pull on bitbucket.org which
 has diff for human beings and push both simultaneously.
      - Will spend pull senders time but not significantly.
      + Will allow code line-comments on bitbucket.org's better diff.
 

I think this is way too much of a "duplicated effort" deal to be realistic.
 * Move to bitbucket.org
      + Good diff
      - Need to instruct everybody about move
      - Possible lack of some futures (only possible, I don't know any)

+ Don't have to deal with the piece of shit GitHub anymore. I'd personally be thrilled with this one, as I hate GitHub with a passion, but I don't see it realistically happening.
 
 * Write browser plug-in to fix Github diff
      - Somebody has to do it.
      - Some browser will not support such plug-in anyway.

Yea, it's just a problematic hack.
 
 * Write stand-alone application to work with Github
      - Somebody has to spend a lot of time for it.
 

I've been *REALLY* wanting to see this happen. I was very disappointed when "GitHub for Windows" turned out to not be this at all, but rather nothing more than a really, really crappy substitute for TortoiseGit or any other Git GUI frontend.
 * Write an angry letter to Github support (signed "frustrated D
 community" )
      + The easiest way.
      - The letter can be ignored.
 

That'd be nice if it'd actually work!
 
 P.S.
 Looks like Github's owners doesn't care at all about current users,
 only abut needless features and GUI glance to involve new ones
 because otherwise I have no explanation of this sad situation.
 

Agree. I've been getting the feeling they care more about milking the "Web 2.0" cow than providing a good product with a reasonable (and fast) user experience. (Which is kinda strange considering it's a site that's specifically designed to revolve around a tool, Git, which takes speed as one of it's biggest selling points.)
Nov 14 2012
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/14/12, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:
 Personally, I always have my Tortoise* tools set up to use Beyond
 Compare.

Beyond Compare for the win. I agree GitHub's diff isn't that good. But even BitBucket has fallen into the frenzy of adding special effects. The side-by-side option on BitBucket animates a new window into view, fades out the rest of the screen to black, and gives you the diff without any syntax highlighting (only the diffed characters are in color). And then you press escape and wait 2 seconds for the glorious fade-out effect. It's like I'm in Minority Report.
Nov 14 2012
prev sibling next sibling parent "angel" <andrey.gelman gmail.com> writes:
There are people who actually like it the way it is.
And you still can clone the GitHub repository to a local machine, 
and use your favorite toolset.
Nov 14 2012
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 14 November 2012 at 15:27:36 UTC, Denis 
Shelomovskij wrote:
 * Instruct reviewers to install SmartGit, KDiff3 or something 
 with human readable diff and fetch from repos of pull request 
 senders.
     - Will spend reviewers time.
     - Will not auto-update on pull update.

I doubt that this is a serious problem. GitHub pull requests are available as refs on the main repository, so a single command is all it takes: git fetch upstream pull/322/head You can also create a named branch from the fetched commits: git fetch upstream pull/322/head:localbranch Or set your clone up so that all pull requests are fetched automatically: https://gist.github.com/3342247 David
Nov 14 2012
parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
14.11.2012 22:16, Andrej Mitrovic пишет:
 On 11/14/12, David Nadlinger <see klickverbot.at> wrote:
 On Wednesday, 14 November 2012 at 15:27:36 UTC, Denis
 Shelomovskij wrote:
 * Instruct reviewers to install SmartGit, KDiff3 or something
 with human readable diff and fetch from repos of pull request
 senders.
      - Will spend reviewers time.
      - Will not auto-update on pull update.

I doubt that this is a serious problem. GitHub pull requests are available as refs on the main repository, so a single command is all it takes: git fetch upstream pull/322/head You can also create a named branch from the fetched commits: git fetch upstream pull/322/head:localbranch Or set your clone up so that all pull requests are fetched automatically: https://gist.github.com/3342247 David

And here all along I was doing manual labour with "git remote add username git://path-to-username/dmd" and then fetching the user's branch and checking it out. Thanks for these tips.

+1 Same thing. -- Денис В. Шеломовский Denis V. Shelomovskij
Nov 14 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/14/12, David Nadlinger <see klickverbot.at> wrote:
 On Wednesday, 14 November 2012 at 15:27:36 UTC, Denis
 Shelomovskij wrote:
 * Instruct reviewers to install SmartGit, KDiff3 or something
 with human readable diff and fetch from repos of pull request
 senders.
     - Will spend reviewers time.
     - Will not auto-update on pull update.

I doubt that this is a serious problem. GitHub pull requests are available as refs on the main repository, so a single command is all it takes: git fetch upstream pull/322/head You can also create a named branch from the fetched commits: git fetch upstream pull/322/head:localbranch Or set your clone up so that all pull requests are fetched automatically: https://gist.github.com/3342247 David

And here all along I was doing manual labour with "git remote add username git://path-to-username/dmd" and then fetching the user's branch and checking it out. Thanks for these tips.
Nov 14 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 14 Nov 2012 19:20:26 +0100
Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 On 11/14/12, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>
 wrote:
 Personally, I always have my Tortoise* tools set up to use Beyond
 Compare.

Beyond Compare for the win. I agree GitHub's diff isn't that good. But even BitBucket has fallen into the frenzy of adding special effects. The side-by-side option on BitBucket animates a new window into view, fades out the rest of the screen to black, and gives you the diff without any syntax highlighting (only the diffed characters are in color). And then you press escape and wait 2 seconds for the glorious fade-out effect. It's like I'm in Minority Report.

Ugh, oh that's right...I forgot, bitbucket forced an updated recently that screwed up pretty much the whole site. (I've been wrapped up in my non-OSS work projects lately so haven't been using much of github or bitbucket.) This is why we need proper *real* software for these things instead of all this "web app" bullshit. That way nobody can force breakages and other dumb anti-features on everyone.
Nov 14 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 14-11-2012 16:27, Denis Shelomovskij wrote:
 Current Github diff is very primitive and is almost like unified diff
 format which isn't for humans at all. This complicates and slows down
 code revision simultaneously reducing its quality.

 Something must be done about it to stop wasting people time without any
 real reason.


 Possible solutions:

 * Instruct reviewers to install SmartGit, KDiff3 or something with human
 readable diff and fetch from repos of pull request senders.
      - Will spend reviewers time.
      - Will not auto-update on pull update.

 * Instruct pull senders to also create a pull on bitbucket.org which has
 diff for human beings and push both simultaneously.
      - Will spend pull senders time but not significantly.
      + Will allow code line-comments on bitbucket.org's better diff.

 * Move to bitbucket.org
      + Good diff
      - Need to instruct everybody about move
      - Possible lack of some futures (only possible, I don't know any)

 * Write browser plug-in to fix Github diff
      - Somebody has to do it.
      - Some browser will not support such plug-in anyway.

 * Write stand-alone application to work with Github
      - Somebody has to spend a lot of time for it.

 * Write an angry letter to Github support (signed "frustrated D
 community" )
      + The easiest way.
      - The letter can be ignored.


 P.S.
 Looks like Github's owners doesn't care at all about current users, only
 abut needless features and GUI glance to involve new ones because
 otherwise I have no explanation of this sad situation.

Or we could switch to Phabricator for our entire review process which has an absolutely awesome side-by-side diff and is generally a fantastic tool for distributed-style software projects. See my email to dmd-internals: http://lists.puremagic.com/pipermail/dmd-internals/2012-October/004900.html -- Alex Rønne Petersen alex lycus.org http://lycus.org
Nov 14 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 14-11-2012 21:36, Andrej Mitrovic wrote:
 On 11/14/12, Alex Rnne Petersen <alex lycus.org> wrote:
 Or we could switch to Phabricator for our entire review process which
 has an absolutely awesome side-by-side diff and is generally a fantastic
 tool for distributed-style software projects.

 See my email to dmd-internals:
 http://lists.puremagic.com/pipermail/dmd-internals/2012-October/004900.html

I don't see what's awesome about it, for one thing the code display pages don't seem to be static HTML (or whatever you call it), because every time I enter into codeview I have to wait a few seconds for all the code to render. For big changes it's annoying to having to wait so long. And if I hit the back button and forward again, it starts to re-render again and I have to wait again. Clicking the show context can take over 5 seconds to display, and then Firefox almost freezes because the CPU usage keeps spiking to 90%. Pretty lame if you ask me.

Cannot reproduce in both Firefox and Chrome; code view also loads instantaneously for me.
 It's also inconsistent, my font settings I've set in the control panel
 aren't applied everywhere.

You need to manually configure your monospaced font in Phabricator in your display preferences. Any other font that isn't being applied correctly is a bug. I don't know why they do it this way for monospaced font, but I don't find it to be a show stopper.
 And what is Arcanist, it seems it's betaware like msys, except much
 less tested on Windows? Quote: "NOTE: Windows support is relatively
 new and incomplete, file bugs when you run into issues." And you even
 need to install PHP to make it work.

From what I've heard, other Phabricator/Arcanist users have no trouble on Windows these days. The support was very alpha quality a while back, but it should be fine now. (I don't actually know. I don't use Windows.)
 And then there are things like making the code block button
 automatically insert some sort of PHP/Ruby code. Does it even support
 D syntax in comments?

It's just some code to demonstrate how the syntax works. Hit delete once and it's gone (or just don't use that button at all; why would you?). Yes, it does support D (it uses Pygments).
 The last thing we need now is to make the the barrier to entry for
 contributions skyrocket.

That seems like a bit of an exaggeration. Yes, it requires you to install a little extra software, but the end result is a much more manageable, human-friendly, and scalable review/audit system than GitHub. -- Alex Rnne Petersen alex lycus.org http://lycus.org
Nov 14 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/14/12 12:36 PM, Andrej Mitrovic wrote:
 On 11/14/12, Alex Rnne Petersen<alex lycus.org>  wrote:
 Or we could switch to Phabricator for our entire review process which
 has an absolutely awesome side-by-side diff and is generally a fantastic
 tool for distributed-style software projects.

 See my email to dmd-internals:
 http://lists.puremagic.com/pipermail/dmd-internals/2012-October/004900.html

I don't see what's awesome about it

Everything? :o) Andrei
Nov 14 2012
parent reply Thomas Koch <thomas koch.ro> writes:
Andrei Alexandrescu wrote:
 On 11/14/12 12:36 PM, Andrej Mitrovic wrote:
 On 11/14/12, Alex Rønne Petersen<alex lycus.org>  wrote:
 Or we could switch to Phabricator for our entire review process which
 has an absolutely awesome side-by-side diff and is generally a fantastic
 tool for distributed-style software projects.

 See my email to dmd-internals:
 http://lists.puremagic.com/pipermail/dmd-internals/2012-



 I don't see what's awesome about it

Everything? :o)

Yes, from the featurelist Phabricator looks pretty awesome. And I'm suffering again about an interesting piece of software written in the language of my nightmares: PHP Of course that's only my personal windmill I'm fighting. I just wanted to mention Gerrit Code Review: http://en.wikipedia.org/wiki/Gerrit_%28software%29 I'm in the process of packaging Gerrit for Debian, but this won't be ready before 2013. You can of course install Gerrit with upstreams .war file. Regards, Thomas Koch
Nov 14 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 15-11-2012 08:35, Thomas Koch wrote:
 Andrei Alexandrescu wrote:
 On 11/14/12 12:36 PM, Andrej Mitrovic wrote:
 On 11/14/12, Alex Rønne Petersen<alex lycus.org>  wrote:
 Or we could switch to Phabricator for our entire review process which
 has an absolutely awesome side-by-side diff and is generally a fantastic
 tool for distributed-style software projects.

 See my email to dmd-internals:
 http://lists.puremagic.com/pipermail/dmd-internals/2012-



 I don't see what's awesome about it

Everything? :o)

Yes, from the featurelist Phabricator looks pretty awesome. And I'm suffering again about an interesting piece of software written in the language of my nightmares: PHP Of course that's only my personal windmill I'm fighting. I just wanted to mention Gerrit Code Review: http://en.wikipedia.org/wiki/Gerrit_%28software%29 I'm in the process of packaging Gerrit for Debian, but this won't be ready before 2013. You can of course install Gerrit with upstreams .war file. Regards, Thomas Koch

Pick your poison: PHP or Java. ;) *flees* -- Alex Rønne Petersen alex lycus.org http://lycus.org
Nov 15 2012
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/14/12, Alex R=F8nne Petersen <alex lycus.org> wrote:
 You need to manually configure your monospaced font in Phabricator in
 your display preferences.

I did again and using latest Chrome. I can set font settings from the the code diff via View Options -> Configure Editor, but no matter what font I type in and click save it doesn't change the diff font. Here's what the diff looks like: http://i.imgur.com/TGArz.png That font is Arial, and it stays that way no matter what I put in the font settings. And in another view I a different font is rendered: http://i.imgur.com/RClAS.png Might just be a bug. Btw, what does "Clowncopterize" and "Cook the books" mean? I hate software that tries to act cute. It also doesn't have a good folder tree view, files and folders are intermixed. But maybe there's a setting for this somewhere.. Anyway all of that is nitpicking, I don't want to be negative towards this software if it would actually make us review and merge pulls faster. SVN->Github was a win, maybe this would be one too.. I have no experience using Phabricator so I don't know. From a first look it seemed complicated compared to Github, maybe with time it would grow on me.
Nov 20 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/14/12, Alex R=F8nne Petersen <alex lycus.org> wrote:
 Or we could switch to Phabricator for our entire review process which
 has an absolutely awesome side-by-side diff and is generally a fantastic
 tool for distributed-style software projects.

 See my email to dmd-internals:
 http://lists.puremagic.com/pipermail/dmd-internals/2012-October/004900.ht=

I don't see what's awesome about it, for one thing the code display pages don't seem to be static HTML (or whatever you call it), because every time I enter into codeview I have to wait a few seconds for all the code to render. For big changes it's annoying to having to wait so long. And if I hit the back button and forward again, it starts to re-render again and I have to wait again. Clicking the show context can take over 5 seconds to display, and then Firefox almost freezes because the CPU usage keeps spiking to 90%. Pretty lame if you ask me. It's also inconsistent, my font settings I've set in the control panel aren't applied everywhere. And what is Arcanist, it seems it's betaware like msys, except much less tested on Windows? Quote: "NOTE: Windows support is relatively new and incomplete, file bugs when you run into issues." And you even need to install PHP to make it work. And then there are things like making the code block button automatically insert some sort of PHP/Ruby code. Does it even support D syntax in comments? The last thing we need now is to make the the barrier to entry for contributions skyrocket.
Nov 14 2012
prev sibling parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
14.11.2012 19:27, Denis Shelomovskij пишет:
 P.S.
 Looks like Github's owners doesn't care at all about current users, only
 abut needless features and GUI glance to involve new ones because
 otherwise I have no explanation of this sad situation.

OK, probably Github isn't that bad as it helps some single Japanese: https://github.com/norinori2222/boyfriend_require/blob/master/README-en.md But it's still not for programmers... -- Денис В. Шеломовский Denis V. Shelomovskij
Nov 20 2012