modificar - rebase interactivo git

¿Cómo cambiar el nombre del autor y del remitente y el correo electrónico de los confirmaciones múltiples en Git?

Question

Estaba escribiendo un guión simple en la computadora de la escuela y comprometiéndome con los cambios a Git (en un repo que estaba en mi pendrive, clonado desde mi computadora en casa). Después de varias confirmaciones, me di cuenta de que estaba cometiendo cosas como usuario root.

¿Hay alguna manera de cambiar el autor de estos se compromete a mi nombre?

Answer 1

Usando Rebase interactivo

Podrías hacerlo

git rebase -i -p <some HEAD before all of your bad commits>

Luego marque todos sus compromisos erróneos como "editar" en el archivo de rebase. Si también desea cambiar su primer compromiso, debe agregarlo manualmente como primera línea en el archivo de rebase (siga el formato de las otras líneas). Luego, cuando git te pide que modifiques cada compromiso, haz

 git commit --amend --author "New Author Name <[email protected]>" 

Edite o simplemente cierre el editor que se abre, y luego haga

git rebase --continue

para continuar la rebase.

Puede omitir la apertura del editor completo aquí agregando --no-edit para que el comando sea:

git commit --amend --author "New Author Name <[email protected]>" --no-edit && /
git rebase --continue

Compromiso único

Como algunos de los comentaristas han señalado, si solo desea cambiar la confirmación más reciente, el comando rebase no es necesario. Solo haz

 git commit --amend --author "New Author Name <[email protected]>"

Esto cambiará el autor al nombre especificado, pero el git config user.name configurará como usuario configurado en git config user.name y git config user.email . Si desea configurar el remitente a algo que especifique, esto establecerá tanto el autor como el autor:

 git -c user.name="New Author Name" -c [email protected] commit --amend --reset-author

Nota sobre los compromisos de fusión

Hubo un ligero defecto en mi respuesta original. Si hay alguna confirmación de fusión entre la HEAD actual y su <some HEAD before all your bad commits> git rebase <some HEAD before all your bad commits> , git rebase los git rebase (y, por cierto, si usa las solicitudes de extracción de GitHub, habrá una tonelada de fusión Se compromete en su historia). Esto puede llevar muy a menudo a un historial muy diferente (ya que los cambios duplicados pueden ser "rebasados"), y en el peor de los casos, puede hacer que git rebase solicite resolver conflictos de fusión difíciles (que probablemente ya se resolvieron en las confirmaciones de fusión) ). La solución es utilizar el indicador -p para git rebase , que conservará la estructura de fusión de su historial. La página de git rebase advierte que el uso de -p y -i puede generar problemas, pero en la sección BUGS dice que "Editar confirmaciones y reformular sus mensajes de confirmación debería funcionar bien".

He añadido -p al comando anterior. En el caso de que solo esté cambiando la confirmación más reciente, esto no es un problema.

Answer 2

1. ejecutar git rebase -i <sha1 or ref of starting point>
2. Marque todas las confirmaciones que desee cambiar con edit (o e )

3. repite los dos comandos siguientes hasta que hayas procesado todos los confirmaciones:

   git commit --amend --reuse-message=HEAD --author="New Author <[email protected]>" ; git rebase --continue

Esto mantendrá toda la otra información de confirmación (incluidas las fechas). La --reuse-message=HEAD evita que el editor de mensajes se --reuse-message=HEAD .

Answer 3

1. Cambie el author name & email confirmación mediante Amend , y luego reemplace el old-commit with new-one :

   $ git checkout <commit-hash> # checkout to the commit need to modify
   $ git commit --amend --author "name <[email protected]>" # change the author name and email
   $ git replace <old-commit-hash> <new-commit-hash> # replace the old commit by new one
   $ git filter-branch -- --all # rewrite all futures commits based on the replacement
   $ git replace -d <old-commit-hash> # remove the replacement for cleanliness
   $ git push -f origin HEAD # force push

2. Otra forma Rebasing :

   $ git rebase -i <good-commit-hash> # back to last good commit
   # Editor would open, replace ''pick'' with ''edit'' before the commit want to change author
   $ git commit --amend --author="author name <[email protected]>" # change the author name & email
   # Save changes and exit the editor
   $ git rebase --continue # finish the rebase

Answer 4

Adapté esta solution que funciona mediante la ingestión de un simple author-conv-file (el formato es el mismo que el de git-cvsimport ). Funciona cambiando todos los usuarios como se define en el author-conv-file en todas las ramas.

Utilizamos esto junto con cvs2git para migrar nuestro repositorio de cvs a git.

Ejemplo de author-conv-file

john=John Doe <[email protected]>
jill=Jill Doe <[email protected]>

La secuencia de comandos:

 #!/bin/bash
export $authors_file=author-conv-file
git filter-branch -f --env-filter ''
get_name () {
grep "^$1=" "$authors_file" |
sed "s/^.*=/(.*/) <.*>$//1/"
}
get_email () {
grep "^$1=" "$authors_file" |
sed "s/^.*=.* </(.*/)>$//1/"
}
GIT_AUTHOR_NAME=$(get_name $GIT_COMMITTER_NAME) &&
GIT_AUTHOR_EMAIL=$(get_email $GIT_COMMITTER_NAME) &&
GIT_COMMITTER_NAME=$GIT_AUTHOR_NAME &&
GIT_COMMITTER_EMAIL=$GIT_AUTHOR_EMAIL &&
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL &&
export GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL
'' -- --all

Answer 5

Al asumir una confirmación no combinada de otro autor, hay una manera fácil de manejar esto.

git commit --amend --reset-author

Answer 6

Al utilizar la rebase interactiva, puede colocar un comando de modificación después de cada confirmación que desee modificar. Por ejemplo:

pick a07cb86 Project tile template with full details and styling
x git commit --amend --reset-author -Chead

Answer 7

Cambiar el autor (o comentarista) requeriría volver a escribir todo el historial. Si estás de acuerdo con eso y crees que vale la pena, entonces deberías revisar git filter-branch . La página de manual incluye varios ejemplos para comenzar. También tenga en cuenta que puede usar variables de entorno para cambiar el nombre del autor, el autor, las fechas, etc. - vea la sección "Variables de entorno" de la página de manual de git .

Específicamente, puede corregir todos los nombres de autores y correos electrónicos incorrectos para todas las ramas y etiquetas con este comando (fuente: ayuda de GitHub ):

#!/bin/sh
git filter-branch --env-filter ''
OLD_EMAIL="[email protected]"
CORRECT_NAME="Your Correct Name"
CORRECT_EMAIL="[email protected]"
if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_COMMITTER_NAME="$CORRECT_NAME"
export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_AUTHOR_NAME="$CORRECT_NAME"
export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
'' --tag-name-filter cat -- --branches --tags

Answer 8

Como mencionó el docgnome, reescribir la historia es peligroso y romperá los repositorios de otras personas.

Pero si realmente quieres hacer eso y estás en un entorno bash (no hay problema en Linux, en Windows, puedes usar git bash, que se proporciona con la instalación de git), usa git filter-branch :

git filter-branch --env-filter ''
if [ $GIT_AUTHOR_EMAIL = bad@email ];
then GIT_AUTHOR_EMAIL=correct@email;
fi;
export GIT_AUTHOR_EMAIL''

Para acelerar las cosas, puede especificar un rango de revisiones que desea reescribir:

git filter-branch --env-filter ''
if [ $GIT_AUTHOR_EMAIL = bad@email ];
then GIT_AUTHOR_EMAIL=correct@email;
fi;
export GIT_AUTHOR_EMAIL'' HEAD~20..HEAD

Answer 9

Debo señalar que si el único problema es que el autor / correo electrónico es diferente de su habitual, esto no es un problema. La solución correcta es crear un archivo llamado .mailmap en la base del directorio con líneas como

Name you want <email you want> Name you don''t want <email you don''t want>

Y de ahí en adelante, los comandos como git shortlog considerarán que esos dos nombres son los mismos (a menos que específicamente les digas que no lo git shortlog ). Consulte http://schacon.github.com/git/git-shortlog.html para obtener más información.

Esto tiene la ventaja de todas las otras soluciones aquí en que no tiene que volver a escribir el historial, lo que puede causar problemas si tiene una conexión ascendente, y siempre es una buena manera de perder datos accidentalmente.

Por supuesto, si cometió algo como usted mismo y realmente debería ser otra persona, y no le importa volver a escribir la historia en este punto, cambiar el autor es probablemente una buena idea para fines de atribución (en cuyo caso lo dirijo a mi otra respuesta aquí).

Answer 10

En el caso de que solo algunos de los primeros cometidos tengan malos autores, puede hacer todo esto dentro de git rebase -i usando el comando exec y el comando --amend , de la siguiente manera:

git rebase -i HEAD~6 # as required

que te presenta la lista editable de los compromisos:

pick abcd Someone else''s commit
pick defg my bad commit 1
pick 1234 my bad commit 2

Luego agregue las líneas exec ... --author="..." después de todas las líneas con autores incorrectos:

pick abcd Someone else''s commit
pick defg my bad commit 1
exec git commit --amend --author="New Author Name <[email protected]>" -C HEAD
pick 1234 my bad commit 2
exec git commit --amend --author="New Author Name <[email protected]>" -C HEAD

Guardar y salir del editor (para ejecutar).

Esta solución puede tardar más en escribirse que otras, pero es altamente controlable. Sé exactamente qué cometido golpea.

Gracias a @asmeurer por la inspiración.

Answer 11

Encontré que las versiones presentadas son agresivas, especialmente si confiesas parches de otros desarrolladores, esto esencialmente robará su código.

La versión a continuación funciona en todas las ramas y cambia el autor y el comitter por separado para evitarlo.

Felicitaciones a leif81 por la opción all.

#!/bin/bash
git filter-branch --env-filter ''
if [ "$GIT_AUTHOR_NAME" = "<old author>" ];
then
GIT_AUTHOR_NAME="<new author>";
GIT_AUTHOR_EMAIL="<[email protected]>";
fi
if [ "$GIT_COMMITTER_NAME" = "<old committer>" ];
then
GIT_COMMITTER_NAME="<new commiter>";
GIT_COMMITTER_EMAIL="<[email protected]>";
fi
'' -- --all

Answer 12

Github tiene una buena solución , que es el siguiente script de shell:

#!/bin/sh
git filter-branch --env-filter ''
an="$GIT_AUTHOR_NAME"
am="$GIT_AUTHOR_EMAIL"
cn="$GIT_COMMITTER_NAME"
cm="$GIT_COMMITTER_EMAIL"
if [ "$GIT_COMMITTER_EMAIL" = "[email protected]" ]
then
cn="Your New Committer Name"
cm="Your New Committer Email"
fi
if [ "$GIT_AUTHOR_EMAIL" = "[email protected]" ]
then
an="Your New Author Name"
am="Your New Author Email"
fi
export GIT_AUTHOR_NAME="$an"
export GIT_AUTHOR_EMAIL="$am"
export GIT_COMMITTER_NAME="$cn"
export GIT_COMMITTER_EMAIL="$cm"
''

Answer 13

Hoy hemos tenido un problema en el que un carácter UTF8 en el nombre de un autor estaba causando problemas en el servidor de compilación, por lo que tuvimos que volver a escribir el historial para corregirlo. Los pasos tomados fueron:

Paso 1: cambie su nombre de usuario en git para todas las confirmaciones futuras, según las instrucciones aquí: https://help.github.com/articles/setting-your-username-in-git/

Paso 2: Ejecuta el siguiente script de bash:

#!/bin/sh
REPO_URL=ssh://path/to/your.git
REPO_DIR=rewrite.tmp
# Clone the repository
git clone ${REPO_URL} ${REPO_DIR}
# Change to the cloned repository
cd ${REPO_DIR}
# Checkout all the remote branches as local tracking branches
git branch --list -r origin/* | cut -c10- | xargs -n1 git checkout
# Rewrite the history, use a system that will preseve the eol (or lack of in commit messages) - preferably Linux not OSX
git filter-branch --env-filter ''
OLD_EMAIL="[email protected]"
CORRECT_NAME="New Me"
if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_COMMITTER_NAME="$CORRECT_NAME"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_AUTHOR_NAME="$CORRECT_NAME"
fi
'' --tag-name-filter cat -- --branches --tags
# Force push the rewritten branches + tags to the remote
git push -f
# Remove all knowledge that we did something
rm -rf ${REPO_DIR}
# Tell your colleagues to `git pull --rebase` on all their local remote tracking branches

Visión general rápida: lleve su repositorio a un archivo temporal, revise todas las ramas remotas, ejecute el script que reescribirá el historial, haga un impulso forzoso del nuevo estado y pídale a todos sus colegas que hagan un tirón de rebase para obtener los cambios.

Tuvimos problemas para ejecutar esto en OS X porque de alguna manera arruinaba los finales de línea en los mensajes de confirmación, por lo que tuvimos que volver a ejecutarlos en una máquina Linux después.

Answer 14

La forma más rápida y fácil de hacer esto es usar el argumento --exec de git rebase:

git rebase -i -p --exec ''git commit --amend --reset-author --no-edit''

Esto creará una lista de tareas que se verá así:

pick ef11092 Blah blah blah
exec git commit --amend --reset-author --no-edit
pick 52d6391 Blah bloh bloo
exec git commit --amend --reset-author --no-edit
pick 30ebbfe Blah bluh bleh
exec git commit --amend --reset-author --no-edit
...

y esto funcionará todo automáticamente, lo que funciona cuando tienes cientos de confirmaciones.

Answer 15

Ocurre cuando no tienes $ HOME / .gitconfig inicializado. Puedes arreglar esto como:

git config --global user.name "you name"
git config --global user.email [email protected]
git commit --amend --reset-author

probado con git version 1.7.5.4

Answer 16

Para un solo compromiso:

git commit --amend --author="Author Name <[email protected]>"

(extraído de la respuesta de asmeurer)

Answer 17

Puedes usar este alias para que puedas hacer:

git change-commits GIT_AUTHOR_NAME "old name" "new name"

o para las últimas 10 cometer:

git change-commits GIT_AUTHOR_EMAIL "[email protected]" "[email protected]" HEAD~10..HEAD

Alias:

change-commits = "!f() { VAR=$1; OLD=$2; NEW=$3; shift 3; git filter-branch --env-filter /"if [[ ///"$`echo $VAR`///" = ''$OLD'' ]]; then export $VAR=''$NEW''; fi/" $@; }; f "

Fuente: https://github.com/brauliobo/gitconfig/blob/master/configs/.gitconfig

Espero que sea útil.

Answer 18

Si está utilizando Eclipse con EGit, entonces hay una solución bastante fácil.
Supuesto: tiene confirmaciones en una rama local ''local_master_user_x'' que no se puede enviar a una rama remota ''maestra'' debido a que el usuario no es válido.

1. Comprobación de la rama remota ''maestro''
2. Seleccione los proyectos / carpetas / archivos para los cuales ''local_master_user_x_usuario'' contiene cambios
3. Haga clic con el botón derecho - Reemplazar con - Rama - ''local_master_user_x''
4. Confirme estos cambios nuevamente, esta vez como el usuario correcto y dentro de la rama ''maestra'' local
5. Empujar a control remoto ''maestro''

Answer 19

Si las confirmaciones que desea corregir son las más recientes, y solo un par de ellas, puede usar una combinación de git reset y git stash para volver a enviarlas nuevamente después de configurar el nombre y el correo electrónico correctos.

La secuencia será algo como esto (para 2 confirmaciones erróneas, sin cambios pendientes):

git config user.name <good name>
git config user.email <good email>
git reset HEAD^
git stash
git reset HEAD^
git commit -a
git stash pop
git commit -a

Answer 20

Si usted es el único usuario de este repositorio o si no le importa romper el repositorio para otros usuarios, entonces sí. Si has presionado estos compromisos y existen en otro lugar donde puedes acceder a ellos, entonces no, a menos que no te importe romper los repositorios de otras personas. El problema es que al cambiar estas confirmaciones, generará nuevos SHA que harán que se traten como confirmaciones diferentes. Cuando alguien más intenta extraer estos cambios modificados, el historial es diferente y kaboom.

Esta página http://inputvalidation.blogspot.com/2008/08/how-to-change-git-commit-author.html describe cómo hacerlo. (No he probado esto así que YMMV)

Answer 21

Si usted es el único usuario de este repositorio, puede reescribir el historial usando git filter-branch (como escribió svick ), o git fast-export / git fast-import plus filter script (como se describe en el artículo al que se hace referencia en docgnome answer ), o rebase interactiva. Pero cualquiera de los dos cambiaría las revisiones desde el primer compromiso cambiado en adelante; esto significa problemas para cualquiera que haya basado sus cambios en la pre-reescritura de su sucursal.

RECUPERACIÓN

Si otros desarrolladores no hubieran basado su trabajo en la versión de reescritura, la solución más sencilla sería volver a clonar (clonar de nuevo).

Alternativamente, pueden probar git rebase --pull , que git rebase --pull rápidamente si no hubiera cambios en su repositorio, o rebautizar sus sucursales sobre las confirmaciones reescritas (queremos evitar la fusión, ya que seguiría siendo reescribir comits para siempre). Todo esto asumiendo que no tienen trabajo comprometido; usa git stash para esconder los cambios de lo contrario.

Si otros desarrolladores usan ramas de características y / o git pull --rebase no funciona, por ejemplo, porque no está configurado en sentido ascendente, tienen que rebase a rebase su trabajo sobre los confirmaciones posteriores a la reescritura. Por ejemplo, justo después de obtener nuevos cambios ( git fetch ), para una rama master basada en / forked de origin/master , es necesario ejecutar

$ git rebase --onto origin/master origin/master@{1} master

Aquí origin/master@{1} es el estado de reescritura (antes de buscar), vea gitrevisions .

Una solución alternativa sería utilizar refs / replace / mechanism, disponible en Git desde la versión 1.6.5. En esta solución, usted proporciona reemplazos para las confirmaciones que tienen un correo electrónico incorrecto; entonces cualquiera que busque refires de "reemplazo" (algo como fetch = +refs/replace/*:refs/replace/* refspec en el lugar apropiado en su .git/config ) obtendría reemplazos de manera transparente, y aquellos que no obtengan esos refs ver viejos compromisos.

El procedimiento es algo como esto:

1. Encuentre todos los confirmaciones con un correo electrónico incorrecto, por ejemplo usando

   $ git log [email protected] --all

2. Para cada confirmación errónea, cree una confirmación de reemplazo y agréguela a la base de datos de objetos

   $ git cat-file -p <ID of wrong commit> |
   sed -e ''s/user@wrong/.email/[email protected]/g'' > tmp.txt
   $ git hash-object -t commit -w tmp.txt
   <ID of corrected commit>

3. Ahora que ha corregido la confirmación en la base de datos de objetos, tiene que decirle a git que reemplace de forma automática y transparente la confirmación incorrecta mediante la corrección de uno usando el comando git replace :

   $ git replace <ID of wrong commit> <ID of corrected commit>

4. Finalmente, enumere todos los reemplazos para verificar si este procedimiento tuvo éxito

   $ git replace -l

   y compruebe si los reemplazos tienen lugar

   $ git log [email protected] --all

Por supuesto, puede automatizar este procedimiento ... bueno, todos excepto el uso de git replace que no tiene (todavía) el modo por lotes, por lo que tendría que usar el bucle de shell para eso, o reemplazar "a mano".

¡NO PROBADO! YMMV.

^{Tenga en cuenta que es posible que encuentre algunas esquinas ásperas al usar refs/replace/ mecanismo: es nuevo y aún no está muy bien probado} .

Answer 22

También puedes hacer:

git filter-branch --commit-filter ''
if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
then
GIT_COMMITTER_NAME="<New Name>";
GIT_AUTHOR_NAME="<New Name>";
GIT_COMMITTER_EMAIL="<New Email>";
GIT_AUTHOR_EMAIL="<New Email>";
git commit-tree "$@";
else
git commit-tree "$@";
fi'' HEAD

Tenga en cuenta que si está usando este comando en el símbolo del sistema de Windows, entonces necesita usar " lugar de '' :

git filter-branch --commit-filter "
if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
then
GIT_COMMITTER_NAME="<New Name>";
GIT_AUTHOR_NAME="<New Name>";
GIT_COMMITTER_EMAIL="<New Email>";
GIT_AUTHOR_EMAIL="<New Email>";
git commit-tree "$@";
else
git commit-tree "$@";
fi" HEAD

Answer 23

Tenga en cuenta que git almacena dos direcciones de correo electrónico diferentes, una para el autor (la persona que realizó el cambio) y otra para el autor (la persona que escribió el cambio).

La información del git log -1 --format=%cn,%ce no se muestra en la mayoría de los lugares, pero puede verla con git log -1 --format=%cn,%ce (o use show lugar de log para especificar un compromiso en particular).

Si bien cambiar el autor de su último compromiso es tan simple como git commit --amend --author "Author Name <[email protected]>" , no hay una sola frase o argumento para hacer lo mismo con la información del git commit --amend --author "Author Name <[email protected]>" .

La solución es (temporalmente, o no) cambiar su información de usuario, luego enmendar el compromiso, que actualizará el remitente a su información actual:

git config user.email [email protected]
git commit --amend

Answer 24

Tu problema es muy común. Consulte " Uso de Mailmap para arreglar la lista de autores en Git "

Para simplificar, he creado un script para facilitar el proceso: git-changemail

Después de poner ese script en su ruta, puede emitir comandos como:

• Cambiar coincidencias de autor en la rama actual

  $ git changemail -a [email protected] -n newname -m [email protected]

• Cambie las coincidencias entre el autor y el interlocutor en <branch> y <branch2>. Pase -f a la rama de filtro para permitir la reescritura de copias de seguridad

  $ git changemail -b [email protected] -n newname -m [email protected] -- -f <branch> <branch2>

• Mostrar usuarios existentes en repo

  $ git changemail --show-both

Por cierto, después de realizar los cambios, limpie la copia de seguridad de la rama de filtro con: git-backup-clean

Answer 25

Una línea, pero tenga cuidado si tiene un repositorio multiusuario, esto cambiará todos los compromisos para tener el mismo (nuevo) autor y autor.

git filter-branch -f --env-filter "GIT_AUTHOR_NAME=''Newname''; GIT_AUTHOR_EMAIL=''new@email''; GIT_COMMITTER_NAME=''Newname''; GIT_COMMITTER_EMAIL=''new@email'';" HEAD

Con saltos de línea en la cadena (que es posible en bash):

git filter-branch -f --env-filter "
GIT_AUTHOR_NAME=''Newname''
GIT_AUTHOR_EMAIL=''new@email''
GIT_COMMITTER_NAME=''Newname''
GIT_COMMITTER_EMAIL=''new@email''
" HEAD

Answer 26

Uso lo siguiente para volver a escribir al autor para un repositorio completo, incluidas las etiquetas y todas las ramas:

git filter-branch --tag-name-filter cat --env-filter "
export GIT_AUTHOR_NAME=''New name'';
export GIT_AUTHOR_EMAIL=''New email''
" -- --all

Luego, como se describe en la página MAN de filter-branch , elimine todas las referencias originales respaldadas por filter-branch (esto es destructivo, primero haga una copia de seguridad):

git for-each-ref --format="%(refname)" refs/original/ | /
xargs -n 1 git update-ref -d

Answer 27

Esta es una versión más elaborada de la versión de @ Brian:

Para cambiar el autor y el interlocutor, puedes hacer esto (con linebreaks en la cadena que es posible en bash):

git filter-branch --env-filter ''
if [ "$GIT_COMMITTER_NAME" = "<Old name>" ];
then
GIT_COMMITTER_NAME="<New name>";
GIT_COMMITTER_EMAIL="<New email>";
GIT_AUTHOR_NAME="<New name>";
GIT_AUTHOR_EMAIL="<New email>";
fi'' -- --all

Puede obtener uno de estos errores:

1. El directorio temporal ya existe.
2. Refs comenzando con refs / original ya existe
   (Esto significa que se ha ejecutado previamente otra rama de filtro en el repositorio y se hace una copia de seguridad de la referencia de la rama original en los refs / original )

Si desea forzar la ejecución a pesar de estos errores, agregue el indicador --force :

git filter-branch --force --env-filter ''
if [ "$GIT_COMMITTER_NAME" = "<Old name>" ];
then
GIT_COMMITTER_NAME="<New name>";
GIT_COMMITTER_EMAIL="<New email>";
GIT_AUTHOR_NAME="<New name>";
GIT_AUTHOR_EMAIL="<New email>";
fi'' -- --all

Es posible que se necesite una pequeña explicación de la opción -- --all : hace que el filtro-rama funcione en todas las revisiones en todas las referencias (que incluye todas las sucursales). Esto significa, por ejemplo, que las etiquetas también se reescriben y son visibles en las ramas reescritas.

Un "error" común es usar HEAD lugar, lo que significa filtrar todas las revisiones solo en la rama actual . Y entonces no existirían etiquetas (u otras referencias) en la rama reescrita.

Answer 28

Probar esto. Hará lo mismo que se mencionó anteriormente, pero interactivamente.

bash <(curl -s https://raw.githubusercontent.com/majdarbash/git-author-change-script/master/run.sh)

Referencia: https://github.com/majdarbash/git-author-change-script

Answer 29

Quiero añadir mi ejemplo también. Quiero crear una función bash con un parámetro dado.

Esto funciona en mint-linux-17.3.

# $1 => email to change, $2 => new_name, $3 => new E-Mail
function git_change_user_config_for_commit {
# defaults
WRONG_EMAIL=${1:-"[email protected]"}
NEW_NAME=${2:-"your name"}
NEW_EMAIL=${3:-"[email protected]"}
git filter-branch -f --env-filter "
if [ /$GIT_COMMITTER_EMAIL = ''$WRONG_EMAIL'' ]; then
export GIT_COMMITTER_NAME=''$NEW_NAME''
export GIT_COMMITTER_EMAIL=''$NEW_EMAIL''
fi
if [ /$GIT_AUTHOR_EMAIL = ''$WRONG_EMAIL'' ]; then
export GIT_AUTHOR_NAME=''$NEW_NAME''
export GIT_AUTHOR_EMAIL=''$NEW_EMAIL''
fi
" --tag-name-filter cat -- --branches --tags;
}

Answer 30

git rebase -i YOUR_FIRTS_COMMIT_SHA^
while true; do git commit --amend --author="Name Surname <[email protected]>" --no-edit && git rebase --continue; done

Presione ^ C # después de que se complete la rebase (el ciclo seguirá actualizando el último compromiso)