git cherry-pick non funziona

110

Sto cercando di selezionare un commit dal master e inserirlo nel ramo di produzione corrente. Tuttavia, quando eseguo git cherry-pick <SHA-hash>, ricevo solo questo messaggio:

# 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'

Nota: ho provato a fare un reset e un reset --hard HEAD ^, e nessuno dei due sembrava cambiare nulla.

Sono confuso sul motivo per cui questo non funziona per me.

Qualsiasi intuizione, consiglio o idea su come risolvere questo problema sarebbe utile ~!

git branching-and-merging cherry-pick

— Jay Taylor
fonte

Questo è successo con me quando ho cercato accidentalmente di selezionare il commit sbagliato. A volte succede quando si usa gitk.

— cst1992

141

Git sta risolvendo il cherry-pick come un no-op - tutte le modifiche introdotte da quel commit sono state introdotte da alcuni commit sul tuo ramo attuale. (O è quello che pensa Git, comunque.) Verifica che il commit che stai selezionando non sia già stato unito in qualche modo, come una corretta unione, rebase / cherry-pick o patch frammentaria. (Usa git show <commit-id>per vedere il diff.)

— cdhowie
fonte

16

Grazie per il tuo consiglio, si scopre che la scelta era già avvenuta e tutto quello che dovevo fare era spingerla su GitHub.

— Jay Taylor,

Bene, non mi ero reso conto che stava controllando il contenuto dei file dato il commit-id. Ho cercato l'ID commit nel registro e non sono riuscito a trovarlo. si è scoperto che era già fusa.

— mparaz

Sfortunatamente, questo non è l'unico motivo del problema in questione. Ho esattamente la stessa situazione in cui ho avuto il commit, che ripristina un commit precedente, e quando l'ho selezionato su un altro ramo, la cui cronologia non aveva ripristinato le modifiche (cioè non avevo scelto la ciliegia di quel commit ripristinato ). Ovviamente è colpa mia. Ma in questo caso ci si aspetta che git fallisca con lo stato di conflitto, invece di cercare di essere troppo intelligente, il che si traduce in un utente confuso.

— Artem Pisarenko

Ciò potrebbe accadere se si annulla un commit di unione e il commit da selezionare risiede nel ramo ripristinato.

— matt

11

Nel mio caso questo mi stava facendo impazzire, poiché era abbastanza ovvio che il commit specifico che volevo scegliere non fosse stato unito al mio ramo attuale.

Si scopre che qualcuno aveva già scelto il commit una settimana prima. Le modifiche , ma non lo SHA specifico, erano già nel mio ramo attuale e non le avevo notate.

Controlla i file che stai tentando di selezionare. Se hanno già le modifiche, una versione del commit è già stata selezionata o aggiunta in un altro modo. Non c'è quindi bisogno di sceglierlo di nuovo.

— pkamb
fonte

Sono abbastanza sicuro che il commit specifico non è mai nel tuo ramo quando è stato introdotto da un cherry pick, perché il cherry pick sarà un nuovo hash, giusto? O sto fraintendendo?

— sud

@msouth Quello che originariamente preso da altre risposte è stato "il commit era già fusa", ma ho potuto vedere che era , non nel mio ramo. Hai ragione sul fatto che Cherry Pick sia sempre un nuovo SHA.

— pkamb

Sì, stavo pensando "il commit specifico, come identificato dall'hash", quando l'ho digitato. La mia lingua era imprecisa. Spesso guardo indietro attraverso l'output di git log --graph --pretty --decorate --onelineper vedere se un dato SHA è nel mio ramo o meno. Vedi la mia risposta di seguito su come puoi anche confonderti pensando che il messaggio di commit sia indicativo del cambiamento: c'è una situazione in cui non lo è, ed è questo che mi ha portato a questa domanda originariamente. Il cervello di una persona tende a fare quelle scorciatoie e di tanto in tanto possono tornare a morderti.

— sud

6

Notare inoltre che l'aggiunta di un file vuoto (ad esempio .gitkeep) all'albero è considerata da cherry-pick come un commit vuoto.

— Neamar
fonte

Nel mio caso ho avuto un commit di ripristino (che stava ripristinando un commit vuoto stesso) prima del mio tentativo di scelta rapida, quindi immagino che qualcosa di vuoto probabilmente farà apparire questo messaggio.

— lidkxx

3

Quindi, ecco ancora un'altra situazione confusa in cui questo può verificarsi: ho avuto quanto segue:

Stavo cercando di scegliere 9a7b12e che apparentemente non è niente - ha persino provato a dirmi su quella riga nell'output del log git che 4497428 era quello che volevo veramente. (Quello che ho fatto è stato solo cercare il messaggio di commit e ho preso il primo hash che ho visto che lo aveva). Ad ogni modo, volevo solo far sapere alle persone che c'è un altro modo in cui puoi essere indotto a cercare di scegliere un no op.

— msouth
fonte

10

Non è molto utile per te downvote senza spiegazioni: questa è la riproduzione esatta di un problema che ho avuto che mi ha portato a trovare questa domanda nella mia ricerca. Se hai un consiglio per migliorare questo, per favore dimmelo nei commenti invece di limitarti a votare.

— sud