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 reply 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
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 "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 reply 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
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 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
parent reply 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=


ml

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
next sibling parent reply =?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
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 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-






October/004900.html

 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-






 October/004900.html

 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 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