La database de Git se atasca después de resolver el conflicto de combinación

Estoy ejecutando un rebase que golpea un conflicto:

$ git rebase master First, rewinding head to replay your work on top of it... Applying: Better `SelectMotifsView.js` Using index info to reconstruct a base tree... M browser/AddLinkView.js M browser/SelectMotifsView.js M browser/index.html Falling back to patching base and 3-way merge... Auto-merging browser/index.html CONFLICT (content): Merge conflict in browser/index.html Failed to merge in the changes. Patch failed at 0001 Better `SelectMotifsView.js` The copy of the patch that failed is found in: /Users/dmitry/dev/links/.git/rebase-apply/patch When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort". 

No hay problema, hice un pequeño cambio que sabía que causaría un conflicto:

 diff --cc browser/index.html index ba9c4f3,4c2a1c2..0000000 --- a/browser/index.html +++ b/browser/index.html @@@ -40,6 -40,7 +40,10 @@@ <label> <%= label %> <select class="form-control" name="motif"> ++<<<<<<< HEAD ++======= + <% console.log(exclude); %> ++>>>>>>> Better `SelectMotifsView.js` <% motifs.each(function(motif) { if (!exclude || exclude.indexOf(motif) < 0) { %> <option value="<%= motif.get('id') %>"><%= motif.get('name') %></option> <% } }); %> 

Quiero mantener la versión de HEAD , que está vacía, así que voy y elimino todo:

 ++<<<<<<< HEAD ++======= + <% console.log(exclude); %> ++>>>>>>> Better `SelectMotifsView.js` 

Guardo el file, browser/index.html , luego git add browser/index.html :

 $ git add browser/index.html $ git rebase --continue 

Pero entonces:

 Applying: Better `SelectMotifsView.js` No changes - did you forget to use 'git add'? If there is nothing left to stage, chances are that something else already introduced the same changes; you might want to skip this patch. When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort". 

Nunca he visto esto antes … el git status muestra que no quedan paths sin resolver. ¿Qué hacer? Leí en otras preguntas relacionadas que esto puede ser un buen uso de --skip , pero esto no parece ser un compromiso nulo. ¿O estoy equivocado?

Una posible causa de que una git rebase se atasque en un "bucle de rebase" es git gc .
Esto está arreglado en git 2.7.1 (6 de febrero de 2016)

Ver commit 8c24f5b (13 de enero de 2016) por Jeff King ( peff ) .
(Fusionado por Junio ​​C Hamano – gitster – in commit eefc461 , 26 de enero de 2016)

rebase : ignorar los fallos de " gc --auto "

Después de volver a basar, llamamos " gc --auto " para limpiar si creamos muchos objects sueltos. Sin embargo, lo hacemos dentro de una && -chain. Si " gc --auto " falla (p. Ej., Porque un background anterior gc nos bloqueó al dejar " gc.log " en su lugar), entonces:

  1. No limpiaremos el directory de estado, dejando al usuario atrapado en la rebase para siempre (incluso " git am --abort " no funciona, porque llama " gc --auto "!).
  2. En algunos casos, podemos devolver un código de salida falso de rebase, lo que indica un error cuando todo, excepto el auto-gc, tuvo éxito.

Podemos solucionar esto ignorando el código de salida de " gc --auto ".

Para solucionarlo solo necesita eliminar gc.log :

 rm .git/gc.log 

Parece que el parche está vacío, por lo que puedes omitirlo con security, como sugiere git:

 $ git rebase --skip