2010-11-25 12 views

Respuesta

6

¡Parece que estás haciendo algo bastante loco! :)

Dicho esto, veo algunas opciones, ninguna de las cuales es particularmente automática.

  1. Si usted tiene un montón de confirmaciones con ese archivo está presente, simplemente admitir el error, crea una nueva rama fuera de su cabeza, y poner aún más las confirmaciones con esa característica en esa rama hasta que estén estables . Si su repo es compartido, esta se convierte en la única opción real. Nadie quiere tener una historia divergente, especialmente si esa característica se cometió en lo profundo de la historia.

  2. Si sólo está hablando de 10 o menos se compromete a que en realidad han tocado ese archivo, y son relativamente poco tiempo, sin muchos cometidos otra confirmación intercalada, se puede comprobar a cabo una nueva rama en la cabeza, y revertir la rama no desea volver a esta función antes de agregar la función, y luego seleccionar las confirmaciones que necesita de la rama de características hasta que esté listo para enviarlas todas en una fecha posterior.

  3. Si usted está tratando con un montón de historia, un montón de intercalado comete, y que realmente no quiere tener esa característica presente en todos, usted podría escribir un script de shell poco que toma la salida de git log y cherry lo recoge en una nueva sucursal. Algo a lo largo de las líneas de:

    $ cd git-repo 
    $ git checkout -b feature-x 
    $ the-perfect-shell-script `git log --pretty=format:"%H" path/to/feature.c` 
    

    vez que haya esa rama de la característica con toda la cereza compromete elegido, a continuación, puede utilizar git filter-branch para filtrar todas las confirmaciones que hacen referencia a ese archivo. El man page tiene un ejemplo simple que hace exactamente eso.

    Una vez que tenga eso, puede entonces git rebase feature-x --onto <filtered-branch> y debería estar listo para empezar.

    Por supuesto que debería ser bastante desaconsejado, especialmente si cualquiera de eso se publica.

+1

afortunadamente, no hay nada publicado, mi idea de la ramificación de características se produjo en el "qué considerar antes de la publicación" de la fase :) así que intentaré 3. –

+0

+1 por 'the-perfect- shell-script 'git log --pretty = format:"% H "path/to/feature.c''. Ver [mi propia respuesta] (http://stackoverflow.com/questions/4278264/git-split-history-of-some-files-into-a-separate-branch/4283970#4283970) para mi idea de ello –

+0

en su lugar de 'git log ...' uno también puede usar 'git rev-list master - feature.c' –

2

Ok, aquí está mi ir:

si yo no se compromete la manipulación <feature.c>, podría haber ramificado de <feature.c> 's primero comprometerse y luego se usa git cherry-pick con git log en un bucle, como suggested por Tim Visher. A partir de maestro que supongo que esto debería funcionar:

#!/bin/bash 
# create the feature branch starting from feature.c's first commit 
FIRSTCOMMIT=$(git log --pretty=format:"%H" feature.c | tail -n1) 
git checkout -b feature $FIRSTCOMMIT 

# find all commits concerning feature.c... 
for i in $(git log feature..master --reverse --pretty=format:"%H" feature.c) 
do 
    # ... cherry-pick them ... 
    git cherry-pick $i 
    # ... and copy ONE modified tag of it if existing 
    git describe --tags --exact-match $i && xargs taghelperscript 
done 
# now eliminate feature.c from master 
git filter-branch --prune-empty --tag-name-filter "cat" --index-filter 'git rm --cached --ignore-unmatch feature.c' $FIRSTCOMMIT..master 

Con taghelperscript siendo algo así como git tag prefix.$1 (tal vez esto se puede hacer mejor?). La parte de etiquetado probablemente solo funcione para las etiquetas livianas que uso. También tenga en cuenta que esto no funciona si la característica <.c > ha sido renombrado en algún momento, y si ya existía en la confirmación inicial esto podría causar dos historias separadas, o (mi conjetura) una confirmación en master que contiene la eliminación de <feature.c> que es probable que cause un conflicto de fusión o confusión posterior.


El problema es que algunos de mis compromete modificar otros archivos, lo que provoca git cherry-pick para desencadenar una fusión sin resolver, o introduce estos otros archivos. Entonces, en cambio, probaré un poco de magia git filter-branch. Más tarde. Estén atentos ...

Cuestiones relacionadas