New approach for the case of finding unmerged files with merged entries
in the index.
After some discussion the solution tries to:
- Avoid the problems with infinite loops in this case.
- Provide better information to the user in the commands affected.
- Make sure there are ways to clean the index.
- Provide also a way to specifically recover each one of the files with
this problem.
With these patches the behaviour of these commands (for this case) change:
- git reset is able to finish, cleaning the index, but warning out the
information about the removed stages.
- git merge is able to finish, reporting that there is a merge in progress as
usual, it also warns about the unmerged files with merged entries.
- git add fails when this case happens, telling the user to check the state
with 'git ls-files -s', before, it did nothing. The same with git commit -a.
- git update-index --cacheinfo can be used to select an specific staged
version to resolve the conflict, without the need of reseting the working
copy. It did nothing before.
Tests added for these cases. Rest of the tests remain unchanged and pass too.
Jaime Soriano Pastor (4):
read_index_unmerged doesn't loop forever if merged stage exists for
unmerged file
Error out when adding a file with merged and unmerged entries
Added tests for the case of merged and unmerged entries for the same
file
git update-index --cacheinfo can be used to select a stage when there
are merged and unmerged entries
builtin/update-index.c | 1 +
cache.h | 1 +
read-cache.c | 36 ++++++++++--
t/t9904-unmerged-file-with-merged-entry.sh | 94 ++++++++++++++++++++++++++++++
4 files changed, 127 insertions(+), 5 deletions(-)
create mode 100755 t/t9904-unmerged-file-with-merged-entry.sh
--
2.0.4.4.gaf54b2b
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html