Reescribe automáticamente el historial de git para la versión de código abierto

Actualmente estoy lanzando varios proyectos como fuente abierta. Normalmente, la fuente completa se proporciona como file ZIP o se registra en un repository de código abierto. Esto dificulta el análisis por ohloh .

En caso de que el software se haya desarrollado en un repository no público, el historial completo está disponible. Sin embargo, no quiero que se publique el historial completo.

Quiero usar git para alcanzar una de las dos posibilidades:

(i) Un compromiso por autor: debe haber un compromiso por autor (con la date de compromiso la date de lanzamiento final). Cada confirmación contiene las líneas de código, que finalmente llegaron a la versión final.

(ii) Compromisos originales con solo las líneas de código definitivas: en esta variante, se conserva el número de confirmaciones. Cada confirmación se modifica de forma tal que solo se conservan las líneas, que finalmente llegaron a la versión final, y se borran todas las demás.

¿Alguien ha implementado alguna de las variantes? La variante (i) parece factible usando git-blame y algunos scripts.

(i) Un compromiso por autor

Supongo que lógicamente no es posible: supongamos que tienes una secuencia de confirmaciones como esta:

  • Commit: A, Autor: Alpha
  • Commit: B, Autor: Beta
  • Commit: C, Autor: Alpha

Si el commit C depende de cualquier cosa hecha en B, no puedes reorderar y aplastar A y C más.

(ii) Compromisos originales con solo las líneas de código finales

Para eso puedes usar 'git filter-branch –tree-filter'. Tenga en count que el siguiente script podría comer gatitos, porque solo lo he probado en un repository de testings simple. Has sido advertido:

git filter-branch --prune-empty --tree-filter ' # directory which contains the final version of the project FINAL_VERSION="$DIRECTORY_WITH_REPOSITORY_OF_FINAL_VERSION" # directory which contains the filtenetworking version of the repository FILTER_DIR="$(pwd)" # apply the current commit in to the final version in reverse mode, # ignore the rejects cd "$FINAL_VERSION" git show "$GIT_COMMIT" > /tmp/original.patch cat /tmp/original.patch | patch -p1 -t git diff > /tmp/filtenetworking.patch # reset the FINAL_VERSION to the original state. git reset --hard git clean -f -d -x # apply the patch which contains the lines which could be reversed on # the filtenetworking version cd "$FILTER_DIR" # revert the last commit patch -p1 -t < /tmp/original.patch # apply the filtenetworking patch patch -p1 -t < /tmp/filtenetworking.patch # remove the rejects by the modified patch find -name "*.orig" -o -name "*.rej" | xargs rm -rf ' previousRelease..HEAD 

(Esto supone que ha labeldo el punto de bifurcación con "previousRelease". También debe adaptar la variable FINAL_VERSION).

git-oss-releaser es una solución para la opción (i).

git-oss-releaser convierte un repository git dado a un repository git que solo contiene los files de la última confirmación y se asemeja git blame salida de git blame para cada file. La historia original está perdida.

uso: git-oss-releaser.py [-h] repoDir outDir

Argumentos posicionales:

  • repoDir : el repository para transformar. También puede ser un subdirectory de un repository.
  • outDir : el directory donde se debe crear el nuevo repository. Tiene que estar vacío.

Argumentos opcionales:

  • --name NAME El user.name a usar para user.name los files. Se establece de manera pnetworkingeterminada en el nombre de user.name global de user.name .
  • --email EMAIL El user.email del user.email que se utilizará para user.email los files. Se establece en el user.email global de user.email .
  • --date DATE La date a usar para commits. El valor pnetworkingeterminado es la date de la última confirmación.

Tenga en count que git distingue autor y committer en una confirmación. El autor se toma usando la git blame , los datos del comisionado se toman del nombre de user.name global y el user.email user.name user.email o el --name y los --email configuration configurados.

El modo DEBUG solo se puede habilitar actualmente en el código.

Limitaciones

  • Funciona en repositorys git sin ningún file sin seguimiento solo
  • Las líneas vacías se asignan a "git-oss-releaser" y no al primer o último autor que agrega estas líneas vacías
  • El repository debe contener al less un file no binary
  • La date de compromiso se deriva únicamente de files no binarys
  • Probado bajo git solo para windows
    Intereting Posts