git: przechowuje różne etapy pliku w indeksie/drzewie roboczym po konflikcie

Question

Załóżmy, że jeden plik jest w stanie konfliktu z git.

Oznacza to, że indeks zawiera 3 wersje pliku, poprzednią, jedną z jednego oddziału, drugą z drugiego.

Chciałbym sprawdzić wersję 3 ("ich") w katalogu roboczym, a wersję stage 2 ("nasze") w indeksie.

Czy jest to bezbolesny sposób?

Answer 1

Prawdopodobnie najbardziej bezbolesny sposób jest taki.

# Checkout 'their' version from the index into the working tree 
git checkout --theirs file 

# reset the index to the HEAD version, i.e 'our' branch 
git reset HEAD file 

fiddling z indeksem z update-index hydraulicznego nie powinno być konieczne, chyba że zgubiłeś HEAD (że tak powiem).

Answer 2

Sztuczka polega na "dodaniu jednej wersji do indeksu": oznaczałoby to plik jako rozwiązany (co oznacza, że ​​nie jest już "nasz" lub "ich").
To musi być ostatni krok.

Może coś takiego:

git show :3:<filename> > <filename>.theirs # save the "theirs" version in a tmp file 
git show :2:<filename> > <filename>  # display the "ours" version in the working dir 
git add <filename>       # add it to the index 
              # (marking the conflicting file as resolved) 
move <filename>.theirs <filename>  # erasing the file with the "theirs" version 
              # in the working directory 

Niezupełnie "bezbolesny" ...

---

Aby uniknąć plik tymczasowy, Jakub Narębski sugeruje użycie git update index (polecenie hydrauliką) manipulować bezpośrednio indeks.

--replace --cacheinfo <mode> <object> <path> 

--cacheinfo służy do zarejestrowania pliku, który nie jest w bieżącym katalogu roboczym. Jest to użyteczne w przypadku minimalnego scalania transakcji.

Domyślnie, gdy ścieżka pliku istnieje w indeksie, git update-index odmawia próby dodania path/file. Podobnie, jeśli istnieje plik path/file, ścieżka pliku nie może zostać dodana. Za pomocą flagi --replace istniejące wpisy, które kolidują z dodawanym hasłem, są automatycznie usuwane z komunikatami ostrzegawczymi.