git cherry-pick nie działa

111

Próbuję wybrać najlepszy commit od mastera i przenieść go do obecnej gałęzi produkcji. Jednak kiedy wykonuję git cherry-pick <SHA-hash>, po prostu otrzymuję ten komunikat:

# On branch prod_20110801
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#   site/test-result/
 nothing added to commit but untracked files present (use "git add" to track)
 The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Otherwise, please use 'git reset'

Uwaga: próbowałem wykonać reset i reset - twardy HEAD ^ i żaden z nich nie wydawał się niczego zmieniać.

Nie wiem, dlaczego to nie działa dla mnie.

Wszelkie spostrzeżenia, porady lub pomysły, jak rozwiązać ten problem, byłyby pomocne ~!

git branching-and-merging cherry-pick

— Jay Taylor
źródło

Stało się to ze mną, kiedy przypadkowo próbowałem wybrać niewłaściwe zatwierdzenie. Zdarza się czasami podczas używania gitk.

— cst1992

142

Git traktuje wybór wiśniowy jako nie-op - wszystkie zmiany wprowadzone przez to zatwierdzenie zostały wprowadzone przez zatwierdzenie w Twojej bieżącej gałęzi. (A przynajmniej tak myśli Git). Sprawdź, czy zatwierdzenie, które wybierasz, nie zostało już w jakiś sposób scalone, jako poprawne scalanie, rebase / cherry-pick lub fragmentaryczna łatka. (Użyj, git show <commit-id>aby zobaczyć różnicę.)

— cdhowie
źródło

16

Dziękuję za twoją radę, okazuje się, że selekcja już się odbyła i wszystko, co muszę zrobić, to wrzucić ją na github.

— Jay Taylor,

Tak, nie zdawałem sobie sprawy, że to sprawdzanie zawartości plików z podanym identyfikatorem zatwierdzenia. Poszedłem szukać identyfikatora zatwierdzenia w dzienniku i nie mogłem go znaleźć. okazało się, że zostało już włączone.

— mparaz

Niestety nie jest to jedyny powód, o którym mowa. Mam dokładnie taką samą sytuację, kiedy miałem zatwierdzenie, które przywraca niektóre wcześniejsze zatwierdzenie i kiedy wybrałem go w innej gałęzi, której historia nie miała tego cofniętych zmian (tj. Nie miałem wyboru tego cofniętego zatwierdzenia ). Oczywiście to moja wina. Ale w tym przypadku oczekuje się, że git powinien zawieść ze statusem konfliktu, zamiast próbować być zbyt sprytnym, co skutkuje zdezorientowanym użytkownikiem.

— Artem Pisarenko

Może się tak zdarzyć, jeśli cofniesz zatwierdzenie scalające, a zatwierdzenie, które ma być wybrane, znajduje się w przywróconej gałęzi.

— mat.

11

W moim przypadku doprowadzało mnie to do szału, ponieważ było dość oczywiste, że konkretny commit, który chciałem wybrać, nie został włączony do mojej obecnej gałęzi.

Okazuje się, że ktoś już tydzień wcześniej wybrał zobowiązanie. Te zmiany , ale nie konkretne SHA, były już w moim obecnym oddziale, a ja ich nie zauważył.

Sprawdź plik (i), które próbujesz wybrać. Jeśli mają już zmiany, wersja zatwierdzenia została już wybrana lub dodana w inny sposób. Nie ma więc potrzeby ponownego wybierania go.

— pkamb
źródło

Jestem prawie pewien, że ten konkretny commit nigdy nie występuje w twojej gałęzi, kiedy został wprowadzony przez cherry pick, ponieważ cherry pick będzie nowym hashem, prawda? A może nie rozumiem?

— msouth

@msouth To, co pierwotnie zabrałem z innych odpowiedzi, to „zatwierdzenie zostało już scalone”, ale zauważyłem, że nie ma go w mojej gałęzi. Masz jednak rację, twierdząc, że zawsze jesteś nowym SHA.

— pkamb

Tak, myślałem o „konkretnym zatwierdzeniu identyfikowanym przez hash”, kiedy to wpisałem. Mój język był nieprecyzyjny. Często przeglądam dane wyjściowe programu, git log --graph --pretty --decorate --onelineaby zobaczyć, czy dany SHA znajduje się w mojej gałęzi, czy nie. Zobacz moją odpowiedź poniżej o tym, jak możesz się pomieszać, myśląc, że komunikat o zmianach wskazuje na zmianę - jest sytuacja, w której tak nie jest i to pierwotnie doprowadziło mnie do tego pytania. Mózg ma tendencję do wybierania tych skrótów i czasami może wrócić, by cię ugryźć.

— msouth

6

Zauważ również, że dodanie pustego pliku (np. .gitkeep) Do drzewa jest traktowane przez cherry-pick jako puste zatwierdzenie.

— Neamar
źródło

W moim przypadku miałem zatwierdzenie odwrotne (czyli samo przywrócenie pustego zatwierdzenia) przed moją próbą wyboru, więc myślę, że coś pustego prawdopodobnie spowoduje pojawienie się tego komunikatu.

— lidkxx

3

Tak więc, oto kolejna myląca sytuacja, w której może się to zdarzyć: miałem następujące rzeczy:

Próbowałem wybrać 9a7b12e, co najwyraźniej jest niczym - nawet próbował mi powiedzieć w tej linii w danych wyjściowych dziennika git, że 4497428 jest tym, czego naprawdę chciałem. (To, co zrobiłem, to po prostu wyszukałem komunikat o zatwierdzeniu i złapałem pierwszy hash, jaki widziałem, który go zawiera). W każdym razie, po prostu chcę, aby ludzie wiedzieli, że jest inny sposób, w jaki możesz dać się oszukać, próbując wybrać opcję „no op”.

— msouth
źródło

10

Głosowanie przeciwne bez wyjaśnienia nie jest zbyt pomocne - jest to dokładne odwzorowanie problemu, który miałem, który doprowadził mnie do znalezienia tego pytania podczas moich poszukiwań. Jeśli masz zalecenie, jak to ulepszyć, napisz o tym w komentarzach, zamiast po prostu głosować w dół.

— msouth