在crlf正常化后使用隐藏回收滞留回购？ [英] Stuck repo using stash after crlf normalization?

问题描述

我有我的本地回购协议，因为禁止我提交，存储，签出另一个分支，甚至放弃更改。所以我只是被卡住了。

我会尝试描述哪些步骤将我带入这种情况，据我所知。

请坐下。

不久之前， ... 其他开发者在项目中标准化crlf根据： https://help.github.com/articles/dealing-with-line-endings

在这段时间（你知道，光速。 ..）我做了一些本地更改，提交，并拉。

当我拉Git时说：

 错误：您对以下文件的本地更改将被合并覆盖：
 wp-config.php 
  

wp-config.php 早先使用从索引中移除git update-index --assume - 改变了wp-config.php ，因为它的模板配置文件适用于每个本地环境。

基础模板可以更改。毫无意外。在这里我计划：
$ b $ ol


隐藏我自己的配置更改

pull origin master

隐藏应用我的配置返回

在步骤3中出现了问题。 git pull origin master 仍然引发了上述错误，就像存储无效一样。

git status 表示 wp-config.php 的变化未进行提交。这让我感到惊讶。

自从我将更改储存起来后，我运行了 git checkout - wp-config.php ...但没有任何效果！文件仍然没有提交。

自从我生气了，我创建了一个新的分支my-config，添加并提交了 wp-config .php 放入它，然后切换回master，删除 wp-config.php （使用 git rm


所以现在这个主人是最新的和干净的，我计划恢复我自己的配置没有Git的帮助（手动编辑文件）。



因为我想知道发生了什么，我切换到了my-config分支，并在这里尝试了一个非常简单的操作：

  git stash 
 git stash apply 
  

猜猜是什么？
隐藏应用文件将被合并覆盖：
wordpress / license.txt
wordpress / readme.html
...
（所有由crlf转换修改的文件）


现在我被困在我的分支上（并计划看到它，法语者会理解;）） ：

• git stash apply ， commit 和 checkout master 给出了上面的错误


• git stash 产生一个存储入口，但不会改变未分离状态


• 和 git checkout - < file>

现在我唯一能做的就是删除所有这些文件（使用操作系统 rm


真实的故事。

我很想解释d在master分支上发生了什么，然后在my-config分支上发生了什么，以及在这种情况下我带来了什么（我怀疑在crlf转换后的文件中使用了隐藏）。

<重要注意事项：

• 我在linux上运行
  
• git core .autocrlf 位于输入


• 我的 .gitattributes 与处理行结束文章中的相同
  
• 我对Git相当陌生（第二天与之共处）

当我在my-config分支上输入 stash 时，它输出：

 警告：在wordpress / license.txt中，CRLF将被替换为LF。 
该文件将在工作目录中具有其原始行结尾。 
 ...（每个crlf转换文件一个）... 
保存的工作目录和索引状态WIP on my-config：dbf65ad my config  - 不应该推送
 HEAD现在在dbf65ad my config  - 不应该被推送
  

（ dbf65ad 是我在my-config分支上做的唯一提交）

解决方案

你的同事改变了引起第一次冲突的线条。

这就是为什么你把你的工作藏起来，把东西拿出来（现在没有问题），然后开始再次使用存储器。

通过调用 git stash apply git启动递归合并。

错误消息只是告诉你遇到了合并冲突。根据开发者的存储文档，这可能是在解决冲突后，由 git stash drop 解决：
$ b

应用[存储]可能会因冲突而失败;在这种情况下，它不是从存储列表中删除
。您需要手动解决冲突
并调用 git stash drop


结论：如果行尾的配置必须是在现有项目中完成，似乎最好的做法是在项目文件夹中使用 .gitattributes 。由于它是通过行结束符更改提交进行分发的，因此它将避免令您头痛的事情将您当前的工作切换到新的规范化标准。



更改项目中的行结尾&安培; .gitattributes

根据 .gitattributes 您可以使用以下步骤更改所有文件（活动分支中）的换行符：

< pre>< / index＃删除索引以强制Git为
$ git reset＃重新扫描工作目录
$ git status＃显示将被标准化的文件
$ git add -u
$ git add .gitattributes
$ git commit -m引入行尾标准化

使用与您的源文件匹配的模式替换<< filepattern>> - 在您的案例中 *。py 用于python文件（一个很好的模式 - 在这里给出解释 .gitignore -description ）。

如果你有多个filepattern添加，你可以在 .gitattributes 中添加几个行结束符。

注意：由于第二步需要删除 .git / index （这是特定于分支的），这必须在您希望保留的每个分支中完成。

如果你有很多分支要处理，你可以考虑写一个简短的脚本遍历你的git分支。

I have my local repo in a state that forbid me to either commit, stash, checkout to another branch or even discard changes. So I'm just stuck.

I will try to describe what steps brought me to this situation, as far as I remember.

Please, take a seat.

A not so long time ago, in another computer far, far away... an other dev normalized crlf in the project according to: https://help.github.com/articles/dealing-with-line-endings

In the while (you know, speed of light...) I made some changes locally, commited, and pulled.

When I pulled Git said:

error: Your local changes to the following files would be overwritten by merge:
    wp-config.php

wp-config.php was earlier removed from the index using git update-index --assume-unchanged wp-config.php since its a template config file adapted to each local environment.

The base "template" can change. Nothing surprising. Here what I planned:

1. reindex wp-config.php
2. stash my own config changes
3. pull origin master
4. stash apply my config back

Things went wrong at step 3. git pull origin master still raised the error above, as if the stash was ineffective.

git status said wp-config.php had changes not staged for commit. That surprised me a bit after a stash.

Since I stashed my changes I ran git checkout -- wp-config.php... but without any effect! File was still not staged for commit.

Since I was becoming mad, I created a new branch my-config, added and commited wp-config.php into it, then switched back to master, deleted wp-config.php (using git rm), and merged origin/master... with success!

So now that master was up to date and clean, I planned to restore my own config without the help of Git (editing the file manually).

Since I wanted to know what happened, I switched to my-config branch, and tried here a very simple manipulation:

git stash
git stash apply

And guess what? stash apply failed saying:

error: Your local changes to the following files would be overwritten by merge:
    wordpress/license.txt
    wordpress/readme.html
    ...
    (all the files that where modified by the crlf conversion)

And now I'm stuck on my branch (and plan to saw it, Francophones will understand ;)) since:

• git stash apply, commit and checkout master gives the error above
• git stash produces a stash entry but doesn't change the unstaged states
• and git checkout -- <file> neither removes the unstaged state

The only thing I can do now is to delete all these files (using the OS rm) to be able to go back to the master branch.

True story.

I would love to understand what happened on the master branch, then on my-config branch, and what brought me in such situations (I suspect using stash on crlf converted file).

Important notes:

• I run on linux
• git core.autocrlf is on input
• my .gitattributes is the same as the one in "dealing-with-line-endings" article
• I'm relatively new to Git (2nd day living with it)

When I did stash on my-config branch it outputed:

warning: CRLF will be replaced by LF in wordpress/license.txt.
The file will have its original line endings in your working directory.
... (one for each crlf converted file) ...
Saved working directory and index state WIP on my-config: dbf65ad my config -- should not be pushed
HEAD is now at dbf65ad my config -- should not be pushed

(dbf65ad is the only commit I did on my-config branch)

解决方案

After some research i guess the following happened. Your workmate changed the lineendings which caused the first pull-conflict.

That's why you stashed your work, pulled the stuff (now without problems) and started to apply the stash again.

With invoking git stash apply git starts a recursive merge in of your stashed changes.

The error-message just tells you ran into a merge-conflict. According to the developer's stash-documentation this may be resolved by a git stash drop after resolving the conflicts:

"Applying the [stash] can fail with conflicts; in this case, it is not removed from the stash list. You need to resolve the conflicts by hand and call git stash drop manually afterwards."

Conclusion: If the configuration of the line-endings must be done in a existing project it seems to be best practise to do so by using a .gitattributes in your project-folder. Since it gets distributed with your line-ending-change-commit, it will avoid the headaches switching your current work to the new normalization-standard.

Changing line endings within projects & .gitattributes

According to the developers documentation of .gitattributes you can change the line-endings for all files (in the active branch) with the following steps:

$ echo "<<filepattern>> eol=lf" >>.gitattributes
$ rm .git/index     # Remove the index to force Git to
$ git reset         # re-scan the working directory
$ git status        # Show files that will be normalized
$ git add -u
$ git add .gitattributes
$ git commit -m "Introduce end-of-line normalization"

Replace <<filepattern>> with a pattern that matches your source files - in your case *.py for python-files (a good pattern-explanation is given in this .gitignore-description).

If you have more than one filepattern to add, you may add several line-ending-definitions to the .gitattributes.

Attention: Since the second step requires to delete the .git/index (which is branch-specific) this must be done in every single branch you'd like to keep.

If you have many branches to process, you might consider writing a short script iterating through your git branches.

这篇关于在crlf正常化后使用隐藏回收滞留回购？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！