2011-04-14 18 views
8

Estoy usando un código para el cual no se usa SCM + y recibo actualizaciones ocasionales en la forma de todos los archivos del proyecto, aunque solo algunos de ellos han sido cambiados solo un poco. Hasta ahora solo puse mis propios cambios en un git repo y resolví estas "actualizaciones" con una sesión manual de git add -p que se vuelve cada vez más molesta con la cantidad de mis propios cambios (aquellos que aún no se han determinado para ser publicados) aumentando , y puesto que por suerte lo hice git commit --author "the others" de "parches" antes mencionados, me gustaría saber:git: ¿Cómo volver a establecer la base de todas las confirmaciones de un determinado autor en una sucursal diferente?

¿Cómo pueden todos los envíos realizados por un autor puede separar en una nueva rama?

(no me importa volver a escribir la historia, en este caso, la cesión temporal sólo se utiliza por mí)

La solución ideal sería incluir una combinación de la rama de los otros en la mía después de cada 'parche', pero por ahora una fusión final al final puede ser suficiente.


+ sí, el Jedi hicieron sienten temblar no

+0

solo unas pocas notas para mí mismo con lo que intentaré responder la próxima semana: 'git log --reverse --pretty = formato:"% H% an " HEAD | nl' –

+1

un 'git rev-list' podría estar más adaptado a una solución de script, mientras que ofrece opciones de clasificación y limitación que lo ayudarán a aislar los commits correctos (aquí, por autor). http://www.kernel.org/pub/software/scm/git/docs/git-rev-list.html – VonC

+0

Gracias @VonC, lo investigaré después de las vacaciones –

Respuesta

6

Hace poco hicieron esto para alguien:

git checkout -b other_work <sha1_of_where_to_rebase> 
git log --reverse --author=others --format=%H <sha1_range> | xargs -n 1 git cherry-pick 

Esperanza esto ayuda

+0

Puede agregar --no-merges a el comando de registro si tiene alguno en el rango –

+0

no use 'git log' para scripting, use' git rev-list' en su lugar – knittl

+0

gracias, para la fusión final lo seguiría al volver a basar la rama original (bueno, un copie) en 'other_work', luego seleccione con cuidado todas estas confirmaciones rebasadas a una nueva rama de' 'y finalmente fusione. Tal vez amplíe esto en un script después de mis vacaciones ... –

2

No estoy bastante comprensivo de lo que está haciendo, pero el problema que describe con una base de código de un tercero se llama "proveedor br Anch ". Aquí es cómo lo manejaría:

Cree una rama para la versión de terceros, p. vendor. Supongo que su rama se llama master. Cuando publican una nueva versión, puede hacer lo siguiente:

git stash # If you have any uncommitted files 
git checkout vendor 
tar -xzvf [new files] # This might be unzip or whatever, rather than tar 
git commit -am "Version xxx from upstream" # Adjust commit message to suit 
git checkout master 
git merge vendor # Bring changes into your branch (you could use rebase here if you prefer to keep all your changes on top of all their changes) 
git stash pop # Restore your uncommitted files 

ps. en lugar de git add -p, usaría git gui. Yo era escéptico de usar una interfaz gráfica para empezar, pero no podía vivir sin git gui y gitk ahora (o gitx en un Mac).

+0

gracias, este es de hecho el procedimiento ahora.Por alguna razón, no puedo recordar que solía realizar los cambios de los demás en mi rama principal así que mi pregunta era cómo dividir retroactivamente esa única rama en una historia que parece que siempre he ramificado de la manera en que describes –

+0

En el momento en que respondí esto, no me había dado cuenta de que fue escrito en abril del año pasado, en lugar de abril del mes pasado :-) – rjmunro

Cuestiones relacionadas