How to avoid GitHub client's “The diff is too large to show here” issue

Okay okay, I was a bit too enthusiastic about the new GitHub GUI app last week. It does have issues, which will hopefully be solved soon. I hit one specific issue, yet also found a workaround which helped me and may help you — thankfully, for all the graphical glory there's still a powerful set of command-line Git tools available, which can help us out on a bad day.

The problem is that when committing a large(ish) file from the Windows GitHub client, after the commit is done, sometimes it is not possible to see a proper difference summary between this and the previous version of the file — the diff display says that “The diff is too large to show here”, as shown below. In my tests it happened on files larger than 300-400 rows.

Too large? I just added one row!

It is important to note that the root of the problem (too many changes) is also visible on the GitHub site, so the issue is in the actual commit process, not in the display. It is on the server that you can see what the system thinks was actually changed — even if you changed just one line of code, it shows the whole previous file as deleted, and the whole new file as being added.

Not very helpful.

Yet it is also very very odd that this doesn't happen reliably — sometimes the client detects and submits text changes just fine!

So, if and when this happens, you can use the “Open a shell here” command from the repository tools:


It will open a command-line (non-standard one, depending on your config), in which you can perform the following actions:
> git add [file-name]

This action marks the file(s) to be committed. You can repeat it for as many files as you need. Then:
> git commit -m '[commit description]'


This action performs the commit of the previously marked files to the local repository.

If you were using Git from scratch, you would need to configure a so called “remote”, a remote (yes) location (or several) that you deal with. It is customary to name the master location as “origin”:
> git remote add origin https://github.com/[user-name]/[repository-name]

Yet with GitHub GUI client, this remote is already configured for you, so, if you try to configure it again (as I did, or the pedant in me), you'll get the following capital error:

fatal: remote origin already exists.


Then all you need to do is push it to the origin remote (from your master branch):
> git push origin master

Done, and done. The diff on the file now looks as it should, highlighting the changes lines correctly:

That's what it should look like.

Funny that in my tests I would sometimes get incorrect work on GUI client — and correct work of command-line, versus some cases where the client works find — but the command line one doesn't. So only use this solution if you need it — i.e. when the file you try to commit doesn't show its diff properly, as described above.

So this is definitely not the bottom of the issue, but still a way to work around it. And a lesson on how to commit files manually — not that difficult, after all!

I wonder if there is a way to silently roll commits back on the client — so your advice would be much appreciated. What I mean is that when the above problem happens, I've already committed a file, and when I revert the commit it is still visible in history — which looks messy, especially if you plan to put this version into a pull request of someone else's repository — they will see your back-and-forthing as individual changes. If you can recommend me a way to permanently delete such failed commits, so they're not visible to anyone — I'd be grateful!

Oh, hey, and I've made my first pull request to the LiveStreet CMS code (a pull request is when I changed something and ask the project owner whether they would like to accept these changes into their code — I'd call it “push” request, but oh well) — even if it doesn't get accepted (though I'd like to know the reasons) it is still a valuable experience. I'll try not to boast too much about it :)

Take care, and till next time.


Comments

  1. When the Git win app was first released, I installed it and in 15 minutes I uninstalled it. It is total junk as a Git client. And it is total junk as a Github site replacement. I do not understand how one can work even on a simplest project with that app.

    I found no logical explanation on why this app exists at all. For obvious reasons it cannot and should not replace the site itself. So you need site to fully work with Github features. Having some of them in a client does not have any sense at all for me.

    Even more - the GUI of the app is total junk too.

    If you want free Git client - there are loads of them. I searched for one on Mac and I found pretty good one - SourceTree. I'm sure there is one for Windows too. Why do you need that github's junk - I cannot even imagine.

    ReplyDelete
    Replies
    1. Thanks for your feedback, it is very important for us ;))

      Though, I mean, there are probably many things missing from it, but so far I managed to sync / commit fine, working on a single small project. It doesn't have pull request functionality, so to put your code into someone else's project you do need to go to the site, yes. But not for working with your own projects, as far as I can tell, and that probably covers 90% (caution: imaginary number! :)) of users' needs out there.

      I may want to check other clients, though, that's a good advice.

      Delete
    2. Well, you are right - my feedback does not have any facts supporting my harsh opinion. I apologize, but in my defense I can say that I think my opinion is obvious just by looking at screenshots of normal Git clients - for example SourceTree.

      Delete
    3. Mac only :( But I'll look for other ones, and share my opinion here :)

      Delete
  2. How did you move history-column to the right? (GitHub client)

    ReplyDelete
    Replies
    1. Hi! This is how it used to be in early versions of their UI client. This is changed now, so the history is shown on the left for me too.

      One can argue that this is, perhaps, more logical, as you'd select a history entry first — and then view the corresponding changed second, so for left-to-right reading cultures History should be on the left.

      Delete
    2. Thanks for answer.
      It's a pity. Logical - may be. But usability is better when it at right, because now when work with history list we need move mouse pointer on long distances between scroll list of changes and choosing another history item. Not for dispute, just my opinion :)

      Delete
    3. Yes, that is a good point as well. I think it looked nicer with history on the right, too :)

      Delete

Post a Comment

Popular Posts