Stage selected lines broken on master

[lucaotta]

It looks like that stage selected lines is broken on master branch, as well as on version 2.11 as released on homebrew.

I'm trying to stage a single hunk, and I get an error while applying the patch, in cmds.py:235

status, out, err = self.model.apply_diff_to_worktree(tmp_file)

The error returned is:

u'error: patch failed: C++/Support/FactoryTest/factory_test.cpp:9\nerror: C++/Support/FactoryTest/factory_test.cpp: patch does not apply\n'

Backtrace:

  /Users/luca/src/electrolux/parrot/git-cola(56)<module>()
  /Users/luca/Applications/git-cola.app/Contents/Resources/share/git-cola/lib/cola/main.py(31)main()
-> return args.func(args)
  /Users/luca/Applications/git-cola.app/Contents/Resources/share/git-cola/lib/cola/main.py(291)cmd_cola()
-> return application_start(context, view)
  /Users/luca/Applications/git-cola.app/Contents/Resources/share/git-cola/lib/cola/app.py(357)application_start()
-> result = context.app.exec_()
  /Users/luca/Applications/git-cola.app/Contents/Resources/share/git-cola/lib/cola/app.py(242)exec_()
-> return self._app.exec_()
  /Users/luca/Applications/git-cola.app/Contents/Resources/share/git-cola/lib/cola/qtutils.py(39)<lambda>()
-> action.triggered[bool].connect(lambda x: fn())
  /Users/luca/Applications/git-cola.app/Contents/Resources/share/git-cola/lib/cola/widgets/diff.py(582)apply_selection()
-> self.process_diff_selection()
  /Users/luca/Applications/git-cola.app/Contents/Resources/share/git-cola/lib/cola/widgets/diff.py(610)process_diff_selection()
-> self.has_selection(), reverse, apply_to_worktree)
  /Users/luca/Applications/git-cola.app/Contents/Resources/share/git-cola/lib/cola/cmds.py(1905)do()
-> return do_cmd(cls(*args, **opts))
  /Users/luca/Applications/git-cola.app/Contents/Resources/share/git-cola/lib/cola/cmds.py(1912)do_cmd()
-> return cmd.do()
> /Users/luca/Applications/git-cola.app/Contents/Resources/share/git-cola/lib/cola/cmds.py(239)do()
-> core.unlink(tmp_file)

I've verified that I can stage the same hunk using git gui.

[davvid]

Would it be possible to reproduce this using a recipe or public repo? There's probably something particular about the specific diff that needs to be handled (for example, the diff's location within the file affects the diff header line).

There's a temp file that cola writes that could be useful to inspect as well. The line where it does core.unlink(tmp_file) could be replaced with print(tmp_file). We can inspect the printed path to see the diff it's producing.

The diff writer probably has an edge case it needs to handle. I use stage selected all the time and it's been working reliably (for me) so there could be a usage pattern I'm not hitting.

[lucaotta]

Unfortunately the repo is not public. I've verified that this happens only on one particular file, for other files the functionality is working well.
The patch file produced is the following:

--- a/C++/Support/FactoryTest/factory_test.cpp
+++ b/C++/Support/FactoryTest/factory_test.cpp
@@ -9,6 +9,7 @@ PowerupStateMachine::PowerupStateMachine(AlarmMng *alarms, bool fctTestDone, boo
     if ( !fctTestDone )
         m_state = FactoryStep1;
     m_alarms = alarms;
+    m_state = Normal;
 }
 
 PowerupStateMachine::States PowerupStateMachine::state() const

I'm on Mac, I launch git-cola from the shell and I've launched it from the repo root and from another directory: in both cases the issue is the same.

[davvid]

I'm led to believe that git itself might be expecting a slightly different diff header for this hunk. The output above, I presume, is from cola's generated patch file.

If you run git diff on the same file, what does the diff look like from git? Is the header different?

[lucaotta]

I managed to trim down the issue and reproduce it into a public repo:
https://github.com/lucaotta/git-cola-issue-730

[davvid]

Awesome.. how do I reproduce it, should I just edit the file to add that same line as above? I noticed that the file has CRLF \r\n line endings.. perhaps it's related, we'll see.

when you edit, is your editor adding CRLF, or is it possibly adding LF \n only into a CRLF file? thanks for the reproducer.

Update: adding the line using CRLF just like the rest of the file reproduces the issue. We probably need to better handle files with CRLF line endings.