Support safely (read-only) syncing `.git` directories

Abierto
  • ¿Algo no está bien?
#164 0 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
git, swift
Área
desktop

Línea de trabajo

Comienza revisando los enfoques propuestos en este issue, issue #130, y la documentación de sincronización de Mutagen enlazada. Define cómo se configuraría la sincronización unidireccional de .git, excluyendo .git/index, y cómo la UI y la documentación comunicarían la dirección, el comportamiento de solo lectura y las ventajas y desventajas; para completar el trabajo es necesario establecer un enfoque, ya que no se especifican archivos ni tests concretos.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Git was not developed with bi-directional file syncing of the metadata in mind - it doesn't expect anything other than the local git process to modify its contents, be it the git config folder or the index. As such, Coder Desktop doesn't sync .git directories.
This is also explained in the Mutagen documentation: https://mutagen.io/documentation/synchronization/version-control-systems/

However, it's not uncommon or unreasonable to want git available on both machines.
On the local machine, the git metadata is obviously required to use Git IDE integrations, but on the workspace it may be required in build scripts, such as to populate version strings from Git tags. Or, it may be the case that the workspace is the only machine authorised to push to the remote.

Whilst we can't include the .git directory in the bidirectional sync session, Mutagen supports the one-way-replica sync mode, where conflicts cannot happen, and changes made to one side immediately replace the contents on the other. We can use this to mitigate these issues, but not without a few caveats:

  • The .git/index file is going to be deleted and recreated on the side it is being synced to each time a git operation is performed. On repos with a large number of files, this will affect the performance of git commands, as it first has to recreate that index.
    • We can work around this by ignoring .git/index, but this doesn't change the fact that the staged/unstaged files will never be synchronised on both sides. (Though what's staged/unstaged on the side being copied to is irrelevant, this may be confusing to see).
  • Whilst the Git metadata on the side being synced to will be read-only, the behavior when attempting to make changes on that side is undefined. In my testing I found that git just errors when attempting to switch branch or make a commit, as the file IDs stored in the config don't match those in the index. Whilst this appears consistent, we have no guarantees this is always the case.
  • The user still needs to be conscious about which side of the file sync the repository is cloned to. If they need to be able to push from the workspace, they need to clone on the workspace (or perform a one time cut & paste of .git, which is fine), and vice versa.

There's two ways we can approach this:

  1. Add a file sync checkbox to additionally create this one-way-replica sync of the .git directory excluding the index file.
  2. Support configuring both the sync mode, and ignored directories when creating sync sessions (#130), allowing users to manually setup this workflow.

Supporting one-way syncs via either approach will also require an update to the UI to indicate which way the sync is.

Regardless of the method, there's a lot we have to communicate to the user about what's going on. They need to be aware of the tradeoffs of this approach, and inform them how to best set up their workflow. With the first approach, we'll likely need to link to documentation, and with the second we'll need to direct the user to documentation to learn how to set up their file-sync.

Unfortunately, there's no approach here that 'just works', that doesn't require the user to be aware of what's going on. For that reason I think the second approach is preferable, as it requires the user to be explicit about how they set up their workflow.

Sibling issue of https://github.com/coder/coder-desktop-windows/issues/105

Lenguaje dominante
Swift
Estrellas
29
Forks
9
Merge medio
1 d 17 h
PR fusionados (30 d)
5

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de coder/coder-desktop-macos

Todos los issues de coder/coder-desktop-macos

Issues similares

Más issues de Swift

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.