2009-06-24 8 views
5

La documentazione dice: "Poiché git-cherry confronta il changeset piuttosto che l'id di commit (sha1), puoi usare git-cherry per scoprire se un commit è stato eseguito localmente è stato applicato con un diverso ID di commit. "git cherry confusion - non funziona come descritto nel documento

Vediamo:

$ git cherry master release-1.1.0 | head -1 
- 533e2559342910fbffa2be5b38fdd7f2ddb2ed53 
$ git show 533e2559342910fbffa2be5b38fdd7f2ddb2ed53 
... 
(cherry picked from commit 409c61b3304373a73c787fdf9c08cc338934b74d) 
... 

git spettacolo mostra la stessa di modifiche per 409c .. e 533e

$ git br --contains 533e2559342910fbffa2be5b38fdd7f2ddb2ed53 
release-1.1.0 
$ git br --contains 409c61b3304373a73c787fdf9c08cc338934b74d 
master 
release-1.0.4 

Ciò significa che il changeset è in entrambi i master e rilascio-1.1.0. Allora, come mai Git Cherry mostra 533e ..?

risposta

3

Inoltre, dice "I commit vengono confrontati con il loro id di patch, ottenuto dal programma git-patch-id.". Quando è stato applicato il tuo diff tra quelli raccolti in ciliegio, forse si è trattato di una differenza leggermente diversa?

In tal caso, non solo l'ID di commit differirà, ma anche l'id di patch come git-patch-id riporterà ID di patch diversi per i commit e quindi non saranno considerati tra di loro .

E 'facile controllare questo:

git show 533e2559342910fbffa2be5b38fdd7f2ddb2ed53 | git-patch-id 
git show 409c61b3304373a73c787fdf9c08cc338934b74d | git-patch-id 

Se la prima SHA1 restituito da git-patch-id è diverso tra le piste entrambi, questo è ciò che è successo.

Lettore - Non ho provato la mia teoria, ma è così che interpreto le pagine man.

+1

Non ho git-patch-id nel mio percorso, ma 'git id-patch' funziona. –