View mode: basic / threaded / horizontal-split · Log in · Help
November 14, 2012
[RFC] A huge problem with Github diff
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
November 14, 2012
Re: [RFC] A huge problem with Github diff
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.)
November 14, 2012
Re: [RFC] A huge problem with Github diff
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.
November 14, 2012
Re: [RFC] A huge problem with Github diff
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
November 14, 2012
Re: [RFC] A huge problem with Github diff
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.
November 14, 2012
Re: [RFC] A huge problem with Github diff
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.
November 14, 2012
Re: [RFC] A huge problem with Github diff
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.
November 14, 2012
Re: [RFC] A huge problem with Github diff
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
November 14, 2012
Re: [RFC] A huge problem with Github diff
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
November 14, 2012
Re: [RFC] A huge problem with Github diff
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.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home