Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Commit Dialog - Stage selected Lines not working #684

Closed
antis81 opened this issue Oct 28, 2011 · 26 comments
Closed

Commit Dialog - Stage selected Lines not working #684

antis81 opened this issue Oct 28, 2011 · 26 comments

Comments

@antis81
Copy link
Contributor

antis81 commented Oct 28, 2011

When I select a bunch of lines in the diff view of an unstaged file and try to stage them, GitExtension says most of the time something like "error ..... patch does not apply".

Concerning this, it would be more clear, if the whole line whas selected and not just part of it.

@Turbo87
Copy link
Contributor

Turbo87 commented Oct 28, 2011

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...

@antis81
Copy link
Contributor Author

antis81 commented Oct 29, 2011

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.

@irium
Copy link

irium commented Nov 30, 2011

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

@Turbo87
Copy link
Contributor

Turbo87 commented Nov 30, 2011

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...

@antis81
Copy link
Contributor Author

antis81 commented Nov 30, 2011

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?

@irium
Copy link

irium commented Dec 1, 2011

"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).

@Turbo87
Copy link
Contributor

Turbo87 commented Dec 12, 2011

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!

@darktygur
Copy link

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.

@antis81
Copy link
Contributor Author

antis81 commented Mar 27, 2012

references #636

@phillijw
Copy link
Contributor

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.

@KindDragon
Copy link
Contributor

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

@gfoot
Copy link

gfoot commented Sep 6, 2012

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.

@antis81
Copy link
Contributor Author

antis81 commented Sep 11, 2012

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.

@jonorossi
Copy link

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 ..."

@feinstaub
Copy link
Contributor

+1

@jbialobr
Copy link
Member

a670f15 fixed bug introduced in 2.40

@jbialobr
Copy link
Member

fd96875 fixes BOM issue

@jonorossi
Copy link

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.

@jbialobr
Copy link
Member

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.

@KindDragon
Copy link
Contributor

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

@grantbowering
Copy link

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.)

@jbialobr
Copy link
Member

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

@philippdolder
Copy link

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.

@per1234
Copy link

per1234 commented Jun 30, 2018

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.

@vbjay
Copy link
Contributor

vbjay commented Jun 30, 2018 via email

@sylvain-bougnoux
Copy link

I've this same error for years but on some lines not always (for unknown reason). As said, playing with encoding or whitespace options, generally manage to bypass the error. When not, I stage the whole file and unstage the lines I don't want to commit. This time I got the error and none of these succeeded. I had to toggle "see whole file" on for success. FYI.

Windows 10
GE 4.0.2.16100
Git 2.38.1
kdiff3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests