How to stage line by line in git gui although "No newline at end of file" warning

Question

I use git gui to select lines for being staged for a commit. This normally works like a charm. I am aware of the option to do the same on the command line.

Whenever a file does not initially have a new line at the end of the file git gui recognizes this and appends a warning message in the editor as I illustrated in the screenshot.

Problem

The problem which results from the missing line break is that one can no longer stage and commit individual lines. When I right-click to select the specific line and choose Stage line for commit from the context menu an error message pops up.

error: fatal: corrupt parch at line 11.

The problem is not specific to the operating system and can be repoduced on Windows, MacOSX and Linux. I know that I can avoid the problem if I add a new line to the file and commit this version before I continue selecting individual lines.

Steps to reproduce the problem

1. Initialize a new repository.
2. Create a file with three lines of content each with the word "Hallo". Do not put a new line at the end of the file.
3. Add and commit the file.
4. Edit the same file putting words inbetween the three lines.
5. Open git gui and try to stage the changes line by line.

Request

I wonder if there is some configuration for Git which allows me to circumvent the problem. Some automatism such as a hook which adds the desired new line would also be fine.

Bug report

I sent a bug report to the Git mailing list. You can follow and participate in the discussion here.

Pluralize

This is really a bug report for git-gui. This problem should only occur for the last hunk in a file. What is happening is when you stage lines, git-gui constructs a patch and then applies it via 'git apply'. In this case we need to remove the last line and re-add it with a newline and leave the "\ No newline at end of file" marker as context. This all happens in lib/diff.tcl apply_range_or_line. It's not trivial but should be fixable. – Gros

I agree: it would be nice if this could be fixed in git gui. Though, I do not know if other UI tools fight the same problems. – Pluralize

Answer 1

Thanks to Heiko Voigt there is a bugfix for the behavior. We fixed this at the Git-Merge conference - thanks to GitHub for organizing this. The patch is pending on the mailing list at the moment. As soon as it is merged and released I am going the update this post here.

• http://www.mail-archive.com/[email protected]/msg25556.html
• http://github.com/hvoigt/git/tree/hv/git-gui-fix-no-newline

---

Finally, gitgui-0.18.0 has been merged into git v1.8.4 and is part of the official release (Aug 23, 2013). Now everybody can enjoy staging linewise commits regardless of a new line at the end of the file. Thanks again to Heiko!

Pluralize

@Ikraav I think you are the first person I noticed who is actually concerned about this bug. Nevertheless, I am looking forward to the bugfix release. – Pluralize

We are currently doing a bit (admittedly over-)centralized git stuff, running git gui remotely for various users to commit their work. This bug has bitten us annoyingly in the butt for a while. Today's been a good day, that's all I got to say about this :) – Rexer

@Ikraav I am glad I made your day a nice one :) – Pluralize

Answer 2

I found an pre-commit hook which takes care of the problem. Though, it is not the perfect solution since the fix applies not until you actually commit the file. I created a gist for the script so you can modify it if you like to improve on it.

• pre-commit hook

The original script was posted by Matt Baker. I reduced it to the fact of adding a new line but also included the routines for removing trailing whitespace. There is however one change regards the linebreak character: I added \n contrary to Matt's recommendation.

Problem case:

I used the script in a git rebase workflow. This caused git to change all files which have trailing spaces. It resulted in a massive diff. Therefore, I recommend to think over using the script.

---

Furthermore, I found this discussion on how to integrate hooks into multiple repositories quite interesting. You might wanna look into this when setting up your own hooks.

Pluralize