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

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

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.

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

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.

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.

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.

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

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

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