¿Cómo extraer un compromiso a la vez desde un repository remoto de git?

Estoy tratando de configurar un espejo darcs de un repository git. Tengo algo que funciona bien, pero hay un problema importante: si presiono un montón de confirmaciones para el repository de git, esas confirmaciones se fusionan en un solo parche de darcs. Realmente quiero asegurarme de que cada commit de git se configure como un único parche de darcs. Apuesto a que esto es posible haciendo algún tipo de git fetch de git fetch seguida de un interrogatorio de la copy local de la sucursal remota, pero mi git fu no está a la altura.

Aquí está el código (ksh) que estoy usando ahora, más o less:

 git pull -v # pulls all the commits from remote --- bad! # gets information about only the last commit pulled -- bad! author="$(git log HEAD^..HEAD --pretty=format:"%an <%ae>")" logfile=$(mktemp) git log HEAD^..HEAD --pretty=format:"%s%n%b%n" > $logfile # add all new files to darcs and record a patchset. this part is OK darcs add -q --umask=0002 -r . darcs record -a -A "$author" --logfile="$logfile" darcs push -a rm -f $logfile 

Mi idea es

  1. Prueba git fetch para get una copy local de la twig remota (no estoy seguro exactamente de qué arguments se necesitan)
  2. De alguna manera, interrogue la copy local para get un hash para cada confirmación desde la última operación de duplicación (no tengo ni idea de cómo hacerlo)
  3. Pasa por todos los hashes, tirando de esa confirmación y grabando el patchset asociado (estoy bastante seguro de que sé cómo hacerlo si tengo en mis manos el hash)

Me gustaría recibir ayuda para dar forma al escenario anterior o sugerencias sobre otra cosa que debería intentar.

Ideas?

¿Has intentado ver algunas soluciones existentes para mover sets de cambios entre sistemas de control de versiones, como Tailor , que dice que incluye soporte para git y darcs? (También hay sugerencias para sistemas similares en esa página).

De lo contrario, si desea utilizar su enfoque sugerido, puede usar el git checkout en cada confirmación después de HEAD al origin/master para realizar el pago en el modo "HEAD desconectado". Por ejemplo, para modificar el ejemplo que das (y en bourne shell, me temo, ya que no uso ksh):

 # Update all remote-tracking branches from origin git fetch origin for c in `git log --pretty=format:"%h" HEAD..origin/master` do git checkout $c author=$(git log -1 --pretty=format:"%an <%ae>") logfile=$(mktemp) git log -1 --pretty=format:"%s%n%n%b%n" > $logfile darcs add -q --umask=0002 -r . darcs record -a -A "$author" --logfile="$logfile" darcs push -a rm -f $logfile done # Now go back to master, and merge to keep your master branch up to date: git checkout master git merge origin/master 

Tenga en count que esto linealizará la historia de git, que no sería lo que yo quería, personalmente. 🙂 Creo que es mejor usar una herramienta existente para esto, pero el enfoque anterior podría funcionar.

Podrías hacer algo como esto:

 #!/bin/bash git fetch count=$(git log --pretty=oneline | wc -l) git merge origin/master git reset --hard HEAD~$((count-1)) 

Creé un repository para este script y lo probé. Lo siguiente es antes y después de la fusión:

enter image description here

enter image description here

Ahora no tenía un repository remoto, así que falsifiqué la búsqueda de git y la twig remota con un local (llamado kalle), pero ya entendiste la idea. Solo haz la fusión completa y luego haz una copy de security del puntero HEAD hasta llegar al primer compromiso desde el origen / maestro.

git remote update # fetch all remotes I like it better than just fetch

git log origin/master # can be any remote/branch

git cherry-pick origin/master # example remote/branch you can also specify a sha1

cherry-pick seleccionará el parche superior por defecto.

para la tercera parte, creo que tendrás que escribir un guión para hacerlo por ti. hay otras forms de get los hash y muchas opciones para el logging. De hecho, puede haber un gancho para cherry-pick o tal vez solo post commit … para ejecutar el código de darcs. echa un vistazo a los ganchos git.

de hecho, en esa nota, cada parche aplicado en una rebase podría llamar a un gancho de commit de git para que puedas escribir eso y luego hacer un git pull –rebase y tener ese código clavado en cada aplicación …

Use esto para recuperar hashes de una twig:

 git log --pretty=format:"%h" HEAD..origin/master 

Luego use git cherry-pick -n <hash> para aplicar cada uno.

Otra opción, citada por @xenoterracide, es usar githooks.