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
  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/ | 94 ++++++++++++++++++++++++++++++
 4 files changed, 127 insertions(+), 5 deletions(-)
 create mode 100755 t/


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to