Gitextensions: Commit Dialog - Stage selected Lines not working

well for the usual copy/paste operation selecting the whole line doesn't work...

But I agree that the algorithm should support newly created files. Not sure how to do it though...

Well, think easy. In the situation of committing, it is very unusual to copy text from a the diff. I've seen other solutions, where the whole line is copied, which is fine. I would think of the copy function as a nice to have feature in this case. I know, that you are using the same view, when diffing a file. So maybe a separate class (delegate?), that handles just the commit document functionality would do here.

I don't understand what about you are talking. The issue exists with a long time and is very annoying. I'm experiencing it not when staging lines from newly created, but and from already tracked, but just modified files too. Sad, but I still did not get the steps to reproduce ((( it appears unexpectedly

I haven't had any problems with this feature in quite a while now. Once you are able to reproduce it please let us know, otherwise a fix is nearly impossible...

Well, it did definitely not work in 2.25, in 2.26 somehow it seems to work, but there was no official fix for this. I had a commit that I couldn't split because of that behaviour, so had to commit it "as is". What I'm talking about is the behaviour in gitx, which is one of the best ui's by now. it is intuitive and clear. When you select a line within the diff during commit, the whole line is selected and on the right side appears exactly one button "stage line(s)" depending on if you selected one or more lines. if you click it, the lines are staged or - vice versa unstaged. would enjoy to see something similar in gitextensions.

For now: It seems to work if you select exactly the whole lines you want to (un)stage and not any character more or less. So maybe we can close the issue and reopen, when more details of what happens are clear?

"For now: It seems to work if you select exactly the whole lines you want to (un)stage and not any character more or less. So maybe we can close the issue and reopen, when more details of what happens are clear?"

I cann't approve this. Just yesterday I've got the error and selecting whole lines didn't help. I remember that in some old versions this some times helped, but not now. (Probably after version that removed ability to reset line(s) before staging them).

As I said earlier: If you have a case that you can reproduce please save that state so that others (or you) can try to fix the problem!! Without a reproducable test case this can not ever be fixed!

I don't know whether I'm better off opening a new issue or not, but I'll start off by commenting here. I'll happily open a new issue if that's better.

I noticed that I get the above error when I try to stage lines while "Show entire file" is toggled on. If I toggle it back off, it works fine. This is happening consistently for me right now. I was using version 2.26, but I just upgraded to 2.28 and it's still happening.

references #636

I had this same issue yesterday (on the GitExtensions project no less). Some lines in a file could be staged but others couldn't. I'll try to reproduce it tonight.

I reproduce this error for .sln file in UTF8 encoding with BOM. Problem only appear when diff encoding in combo box is UTF8. When I switch to Default encoding everything work right.

I think main problem because BOM change line numbers

I've just observed a similar problem in Git Extensions v2.28. With a file created using Unix line endings, added using Git Extensions, I received warnings that the line endings would not be modified in my workspace, but would be replaced with Windows line endings if I checked the files out again. Following on from this, I made two changes to the file. Then, attempting to stage only the second hunk fails, claiming the patch is corrupted. Staging the first chunk seems to work fine. The command line git tool has no problem staging just the second hunk, despite the line endings, so this appears to be a bug in Git Extensions.

Deleting the file, and doing a "git checkout" to get a version with the correct line endings, fixes the problem - now I can use Git Extensions to stage the second hunk of the patch in isolation without causing errors.

However, there was a similar patch corrupted error when I attempted to unstage both hunks, one by one - it didn't like it when there were no more hunks left in the staging area.

The problem seems to origin from either a file's encoding or maybe the line-endings as mentioned above. It happened to me just today in a c# project containing a comment with German characters (Latin1, windows-1251?) strings and in one line it changed (whatever reason) the file encoding. The file was reformatted by VS2010. From exactly this line on, every following line cannot be staged through GE (2.40, but also in earlier versions). Staging in core-git works fine.

I just upgraded to 2.40 from 2.31 and this feature now seems completely broken. I can't seem to stage any lines in any files. I've tried with both ANSI encoded C++ files and UTF-8 encoded C# files, which most the time used to work in 2.31 (used to get problems with the last line of the file).

"... patch failed ... patch does not apply ..."

+1

a670f1501103fbe0d214ab76811a33353cab87af fixed bug introduced in 2.40

fd96875589f22851a691fa1f0f989816a77458aa fixes BOM issue

Many thanks Janusz. I rebuilt GitExtensions, replaced the files in Program Files and it works great.

I did notice that if a file has a empty line at the end and you remove it, GitExtensions is unable to stage this change, however this was the existing defect I mentioned in my previous comment.

This was a quick fix. When I tested it, found another case that stage doesn't work. I will try to rewrite algorithm in simpler manner.

If someone reproduce this bug with 2.41 or later please reopen it.

I'm currently having this problem with 2.43. I can't "Stage Selected Lines" anywhere in any file if "Ignore whitespace changes" is checked. (Unfortunately when it's unchecked, many of the files I have to commit have every line in the file removed and then every line added again. I'm not sure why; it could conceivably be a tabs-versus-spaces thing, but that would be peculiar since one of these files is a .csproj which one does not normally edit by hand and therefore shouldn't be subject to that settings change.)

This feature doesn't work with ignored whitespaces. It looks more like EOL problem.

This happened to me with 2.48 in the following scenario:
Tools->Settings->Git config->Line Endings: Not set
Setting the Line Endings to any of the options resolved the problem. Looks like not set in the effective view is a configuration issue, and in my opinion should be shown as such.

The specific variant of this but as reported previously by grantbowering occurs for me when "Ignore leading and trailing whitespace changes" or "Ignore all whitespace changes" is enabled with GitExtensions 2.51.03, Windows 10 64 bit:

1. Modify a file.
2. Commands > Commit
3. Hover mouse over diff window of the commit dialog.
4. From the top toolbar that appears, enable "Ignore leading and trailing whitespace changes" and/or "Ignore all whitespace changes".
5. Click on a modified line in the diff.
6. Press the "S" key to stage the selected line: error: patch failed:...error:...patch does not apply.

See #3493.

On Fri, Jun 29, 2018, 8:03 PM per1234 notifications@github.com wrote:

The specific variant of this but as reported previously
https://github.com/gitextensions/gitextensions/issues/684#issuecomment-12332133by
grantbowering occurs for me when "Ignore leading and trailing whitespace
changes" or "Ignore all whitespace changes" is enabled with GitExtensions
2.51.03, Windows 10 64 bit:

1. Modify a file.
2. Commands > Commit
3. Hover mouse over diff window of the commit dialog.
4. From the top toolbar that appears, enable "Ignore leading and
   trailing whitespace changes" and/or "Ignore all whitespace changes".
5. Click on a modified line in the diff.
6. Press the "S" key to stage the selected line: error: patch failed:
   ...error:...patch does not apply.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/gitextensions/gitextensions/issues/684#issuecomment-401501721,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADdhsSZcDBHHn25q6HhRfvdkTdM5pjbsks5uBsA3gaJpZM4AFHeS
.