JGit cassa vs `problemi checkout` git

Question

tl; dr JGit di checkout genera eccezioni mentre la linea di comando git checkout funziona bene

Attualmente sto cercando di utilizzare JGit di controllare alcune revisioni da un repository Git on-line, in Java (per lavoro). Il mio approccio attuale è (e io sono molto nuovo a Git, proveniente da un background SVN, quindi questo potrebbe essere sbagliato):

• clone del repository in una posizione temporanea sul mio disco rigido
• capire quale revisione che voglio, (ho provato a usare l'hash SHA-1 e il nome di un ramo)
• checkout che revisione
• da lì, vorrei utilizzare i file estratti come input per una parte successiva di il programma.
• checkout una revisione diversa
• uso tali file come input per un'altra parte del programma

In sostanza, voglio essere in grado di scambiare il contenuto della mia cartella Temp con qualsiasi revisione. Con l'interfaccia a riga di comando sono stato in grado di farlo con git checkout master e git checkout dylanbranch (dove dylanbranch è un ramo che ho creato sul mio clone con una revisione scelta arbitrariamente), ma il mio codice Java tenta di fare la stessa cosa non riesce:

Git git = Git.open(new File("checkout")); //checkout is the folder with .git 
git.checkout().setName("master").call(); //succeeds 
git.checkout().setName("dylanbranch").call(); //fails 

e le eccezioni stampato sulla console:

Exception in thread "main" org.eclipse.jgit.api.errors.JGitInternalException: Checkout conflict with files: 
src/sizzle 
test/qunit 
    at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:211) 
    at com.avi.scm.git.BranchCheckout.main(BranchCheckout.java:30) 
Caused by: org.eclipse.jgit.errors.CheckoutConflictException: Checkout conflict with files: 
src/sizzle 
test/qunit 
    at org.eclipse.jgit.dircache.DirCacheCheckout.checkout(DirCacheCheckout.java:387) 
    at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:162) 
    ... 1 more 

posso verificare che i file in questione sono contrassegnati come eliminati e non messo in scena per commettere utilizzando git status anche se non sono sicuro perché tali modifiche sono lì, e ritornano ogni volta che torno al master. Nonostante ciò, posso ancora cambiare con successo l'albero di lavoro con la riga di comando Git.

Quindi la mia domanda: Perché JGit non funzionerà per questa applicazione quando verrà eseguito il comando git? Qualsiasi altra informazione utile è appreciated- mi educare :)

Aggiornamento ho provato con il repository jQuery, e hanno notato un paio di problemi con JGit: Quando sto lavorando con il ramo "master", git status mi dice che sono #On branch master e che c'è nothing to commit (working directory clean), ma usando il comando di stato di JGit vedo che test/qunit e src/sizzle sono contrassegnati come Missing. Il reset di JGit sembra non fare nulla.

Answer 1

Le due directory menzionati nella traccia dello stack sono Git submodules (test/qunit e src/sizzle) che è più probabile che la causa del problema in quanto JGit non ha il supporto completo modulo ancora .

Questo potrebbe funzionare in modo diverso nella release 1.1 JGit prevista per questo mese in base a questo commit.

È possibile leggere ulteriori informazioni sullo stato corrente del supporto del modulo di supporto JGit here.

Answer 2

So che questo non è direttamente rispondere alla domanda, ma ho anche avuto problemi con le implementazioni Java di Git. Quello che ha funzionato meglio per me è stato semplicemente abbandonare le implementazioni java ed eseguire chiamate da riga di comando a git dall'interno dell'applicazione. Potrebbe non essere l'ideale, ma farà esattamente quello che vuoi dato che controllerai completamente il comando.

Basta chiamare Runtime.getRuntime().exec(...)

Link to Javadoc for Runtime class

Answer 3

Ho avuto un problema simile con Checkout. Penso che il fatto che tu possa cambiare ramo con contenuti non gestiti in Git è in realtà una tolleranza, non una funzionalità. JGit non è globalmente tollerante come Git, quindi di solito dovresti testare molti casi.

Sembra che non sia direttamente il tuo problema (che è legato ai sottomoduli), ma per i casi più generali vorrai confermare le modifiche prima di utilizzare il checkout per passare a un altro ramo.

Si noti che CheckoutCommand funziona perfettamente per l'avvio di un nuovo ramo da una revisione precedente (è necessario impostare il nome del ramo e la revisione iniziale).