Gitextensions: 提交对话框-暂存选定的行不起作用

对于通常的复制/粘贴操作而言，选择整个行不起作用...

但我同意该算法应支持新创建的文件。 虽然不确定如何做...

好吧，想想就容易。 在提交的情况下，从diff复制文本是非常不寻常的。 我看过其他解决方案，可以复制整行，这很好。 在这种情况下，我认为复制功能很不错。 我知道，差异文件时使用的是同一视图。 因此，也许一个单独的类（委托？）可以处理提交文档的功能。

我不明白你在说什么。 这个问题存在了很长时间，非常烦人。 我暂存新创建的行而不是已跟踪的行，而是修改的文件时，不会遇到这种情况。 伤心，但我仍然没有获得复制的步骤（（（

我已经有一段时间没有使用此功能的任何问题了。 一旦您能够复制它，请告诉我们，否则几乎无法修复...

好吧，它在2.25中绝对不起作用，在2.26中似乎以某种方式起作用，但是对此没有官方的解决方法。 由于这种行为，我无法分开提交，因此必须“按原样”提交。 我要说的是gitx中的行为，这是目前最好的ui之一。 这是直观而清晰的。 在提交过程中在差异内选择一条线时，将选中整条线，并且在右侧会根据选择的一条或多条线恰好显示一个按钮“ stage line（s）”。 如果单击它，则这些行是暂存的，反之亦然。 会喜欢在gitextensions中看到类似的东西。

现在：如果您完全选择要（取消）登台的整行，而不是或多或少地不选择任何字符，这似乎可行。 因此，当清楚了解发生的更多细节时，也许我们可以关闭问题并重新打开？

“目前：如果您完全选择要取消显示的整行，而不是或多或少不输入任何字符，这似乎是可行的。因此，当清楚知道会发生什么的更多细节时，也许我们可以关闭问题并重新打开？”

我不同意这个。 就在昨天，我遇到了错误，选择整行没有帮助。 我记得在某些旧版本中，这有时会有所帮助，但现在不是。 （可能是在取消升级行的能力的版本之后）。

正如我之前所说：如果您有可以复制的情况，请保存该状态，以便其他人（或您）可以尝试解决此问题！ 没有可重现的测试用例，就永远无法解决！

我不知道我是否最好开一个新期刊，但我将从这里评论开始。 如果那更好，我会很高兴地打开一个新期刊。

我注意到打开“显示整个文件”时尝试暂存行时出现上述错误。 如果我重新将其关闭，则效果很好。 对于我来说，这一直在发生。 我使用的是2.26版，但我刚刚升级到2.28版，而且这种情况仍在发生。

参考＃636

我昨天也遇到了同样的问题（在GitExtensions项目上也是如此）。 文件中的某些行可以暂存，而其他行则不能。 今晚我将尝试重制它。

我以带有BOM的UTF8编码重现了.sln文件的错误。 仅在组合框中的差异编码为UTF8时才会出现问题。 当我切换到默认编码时，一切正常。

我认为主要问题是因为BOM更改了行号

我刚刚在Git Extensions v2.28中观察到类似的问题。 使用Unix行尾创建的文件，以及使用Git扩展添加的文件，我收到警告，行尾不会在我的工作空间中被修改，但是如果我再次签出文件，它们将被Windows行尾替换。 在此之后，我对该文件进行了两项更改。 然后，仅尝试暂存第二个大块的尝试失败，声称补丁已损坏。 暂存第一个块似乎很好。 尽管命令行结尾，命令行git工具也可以毫无问题地进行第二次调试，因此这似乎是Git Extensions中的错误。

删除文件，然后执行“ git checkout”以获取具有正确行尾的版本，可以解决此问题-现在，我可以使用Git Extensions孤立地进行补丁的第二次扩展，而不会引起错误。

但是，当我尝试逐个撤消两个块时，也出现了类似的补丁损坏错误-当暂存区中不再有块时，它不喜欢它。

该问题似乎源自文件的编码或如上所述的行尾。 就在今天，我在ac＃项目中遇到了这样的情况，该项目包含带德语字符（Latin1，Windows-1251？）字符串的注释，并且在一行中（无论出于何种原因）它更改了文件编码。 该文件已由VS2010重新格式化。 从这一行开始，每行都不能通过GE暂存（2.40，但在较早的版本中也是如此）。 在core-git中暂存效果很好。

我刚刚从2.31升级到2.40，此功能现在似乎已完全损坏。 我似乎无法在任何文件中暂存任何行。 我已经尝试过同时使用ANSI编码的C ++文件和UTF-8编码的C＃文件，这些文件大多数时候都在2.31中工作（用于解决文件最后一行的问题）。

“ ...补丁失败...补丁不适用...”

+1

a670f1501103fbe0d214ab76811a33353cab87af修复了2.40中引入的错误

fd96875589f22851a691fa1f0f989816a77458aa修复了BOM问题

非常感谢Janusz。 我重建了GitExtensions，替换了Program Files中的文件，效果很好。

我确实注意到，如果文件末尾有一个空行并将其删除，则GitExtensions无法进行此更改，但这是我先前的评论中提到的现有缺陷。

这是一个快速修复。 当我测试它时，发现该阶段不起作用的另一种情况。 我将尝试以更简单的方式重写算法。

如果有人使用2.41或更高版本重现此错误，请重新打开它。

我目前在2.43中遇到此问题。 如果选中了“忽略空白更改”，则无法在任何文件的任何位置“分段选定的行”。 （不幸的是，当取消选中该选项时，我必须提交的许多文件都删除了文件中的每一行，然后又添加了每一行。我不确定为什么；可以想象这是制表符对空格的事情，但是那会特有的，因为这些文件之一是.csproj，通常不会手动编辑该文件，因此该设置不会受到更改。

此功能不适用于忽略的空格。 它看起来更像是停产问题。

在以下情况下，发生这种情况的原因是2.48：
Tools->Settings->Git config->Line Endings: Not set
将“行尾”设置为任何选项均可解决此问题。 在effective视图中看起来像not set是一个配置问题，在我看来应该这样显示。

当使用GitExtensions 2.51.03（Windows 10 64位）启用了“忽略开头和结尾的空白更改”或“忽略所有空白更改”时，此更改的特定变体（如先前由Grantbowering报告的

1. 修改文件。
2. 命令>提交
3. 将鼠标悬停在提交对话框的差异窗口上。
4. 在出现的顶部工具栏中，启用“忽略开头和结尾的空白更改”和/或“忽略所有空白更改”。
5. 单击差异中的修改行。
6. 按“ S”键进入所选行： error: patch failed: ... error: ... patch does not apply 。

请参阅＃3493。

在周五，2018年6月29日，下午8时03 per1234 [email protected]写道：

特定的变体，但如先前报道
https://github.com/gitextensions/gitextensions/issues/684#issuecomment-12332133通过
当我“忽略开头和结尾的空格时，就会发生Grantbowering
更改”或“忽略所有空白更改”已通过GitExtensions启用
2.51.03，Windows 10 64位：

1. 修改文件。
2. 命令>提交
3. 将鼠标悬停在提交对话框的差异窗口上。
4. 在出现的顶部工具栏中，启用“忽略开头和
   尾随空白更改”和/或“忽略所有空白更改”。
5. 单击差异中的修改行。
6. 按“ S”键登台所选行：错误：修补失败：
   ...错误：...补丁不适用。

-
您收到此消息是因为您已订阅此线程。
直接回复此电子邮件，在GitHub上查看
https://github.com/gitextensions/gitextensions/issues/684#issuecomment-401501721 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ADdhsSZcDBHHn25q6HhRfvdkTdM5pjbsks5uBsA3gaJpZM4AFHeS
。