Commits
- Commit:
e2b601a4f5570a25ca7066833b2a2d46b0b28bfa- From:
- ale <ale_bnes@tuta.com>
- Date:
Prepare first public release: reorganize, translate, add release infra
- Split the single flat package into cli/changes/checkin/history/update/
settings/actions/roots by responsibility, mirroring how larger VCS
integrations (e.g. git4idea) are organized.
- Translate all comments and user-facing strings to English; trim
narrative/session-referential comments down to concise explanations of
non-obvious behavior only.
- Add a Gradle Wrapper for CI use; build.gradle.kts now falls back to
downloading a matching IntelliJ IDEA build when no local ideLocalPath
is configured (moved out of the versioned gradle.properties into
~/.gradle/gradle.properties, since it is machine-specific).
- Add LICENSE (GPLv3), a plugin icon (light/dark), a fuller <description>
and <vendor> with contact info, and rename the plugin from
'Game of Trees (got) VCS' to 'Got' per Marketplace naming guidelines.
- Rewrite README.md in English: what the plugin does, how each feature
maps to a got command, building, contributing, and releasing.
- Add .github/workflows/release.yml: on any v* tag, build, verify, create
a GitHub Release with the plugin ZIP, and publish to JetBrains
Marketplace once a PUBLISH_TOKEN secret is configured.
- Commit:
c906d176d6192246f1f8c1e27cab8acf5f59fa1e- From:
- ale <ale_bnes@tuta.com>
- Date:
Asigna Ctrl+Shift+K a Got.Send (mismo atajo que Push en git)
- Commit:
a0933fcf1efe249f441a565134b07c98252f2716- From:
- ale <ale_bnes@tuta.com>
- Date:
Agrega 'Send (got send)' al menú VCS
Se evaluó implementar el diálogo nativo de Push (Ctrl+Shift+K) vía
PushSupport, pero requiere Repository/RepositoryManager completos
(GotRepository, GotPushSource/Target/Pusher/OutgoingCommitsProvider,
etc.) -- tamaño comparable a todo el resto del plugin junto, con
APIs sin documentar que habría que descubrir a los tumbos. Se optó por
un AnAction simple: 'got send' (sin argumentos, usa 'origin' y la rama
actual por defecto) corrido en background sobre las raíces got del
proyecto, con el resultado reportado vía notificación. Cubre el caso
de uso real sin esa complejidad.
Registrado en el grupo Vcs.Operations.Popup, junto a las demás
acciones de VCS.
- Commit:
dc516d22dbdaa1a1fc249bf404a61903d33135eb- From:
- ale <ale_bnes@tuta.com>
- Date:
Documenta el estado final: las 6 fases completas
- Commit:
6a971241693ebe7b14f89526ae517b1e97b5a6e8- From:
- ale <ale_bnes@tuta.com>
- Date:
Fase 6: agrega <description> y corrige API deprecada del Verifier
<description> era obligatorio para gradle verifyPlugin (fallaba con
'Invalid plugin descriptor'). Además, GotVcsRootChecker.isRoot(String)
está marcado 'scheduled for removal' en la plataforma 261/262
(confirmado con el Plugin Verifier real, no solo un warning de
compilación) -- se sobreescribe isRoot(VirtualFile) en su lugar, la
sobrecarga moderna.
- Commit:
e508740b86451a34024db9d279843f7168c3df94- From:
- ale <ale_bnes@tuta.com>
- Date:
Fase 6: panel de configuración (Settings > Version Control > got)
GotSettingsState (PersistentStateComponent, gotvcs.xml) persiste dos
rutas: binario got y SSH_AUTH_SOCK. GotConfigurable expone un panel con
un file chooser para el binario y un campo de texto para el socket,
registrado como applicationConfigurable bajo el grupo 'vcs'.
GotCommandLineWrapper.binaryPath()/sshAuthSock() ahora consultan estos
settings primero; si están vacíos (default), caen a la misma detección
automática de antes (/run/current-system/sw/bin/got o PATH; System.getenv
o el socket fijo de gpg-agent). Esto reemplaza los hardcodes de ruta
que quedaron marcados como deuda desde la Fase 1, y da una forma real
de resolver a mano el problema de SSH_AUTH_SOCK=null encontrado hoy si
vuelve a pasar en otra sesión de IntelliJ.
- Commit:
513258b76f2bcdaf8deeca03c0f1745660bd13b4- From:
- ale <ale_bnes@tuta.com>
- Date:
Corrige duplicados en Show History (segunda causa): doble append
Confirmado con 'got log flake.lock' en terminal: got devuelve cada
commit una sola vez, así que la duplicación era enteramente nuestra.
El fix anterior seguía duplicando porque llamaba TANTO
session.appendRevision(revision) COMO partner.acceptRevision(revision)
para la misma revisión -- partner.acceptRevision() ya actualiza esa
misma sesión (la que se le pasó a reportCreatedEmptySession) por su
cuenta, así que ambas llamadas terminaban agregando la revisión dos
veces a la misma lista. Se quita el appendRevision manual; solo
partner.acceptRevision() por entrada.
- Commit:
ef703742ea3a2738787bec65d589b4cc7390a124- From:
- ale <ale_bnes@tuta.com>
- Date:
Corrige commits duplicados en Show History y agrega logging real
Reportado en vivo: cada commit aparecía duplicado en el panel de Show
History. Causa: 'Show History' usa reportAppendableHistory(), no
createSessionFor() -- pero reportAppendableHistory() llamaba a
createSessionFor() para obtener una sesión YA POBLADA con todos los
commits, se la pasaba a reportCreatedEmptySession() (que espera una
sesión realmente vacía) y encima recorría cada revisión llamando
acceptRevision() de nuevo: cada commit terminaba contado dos veces.
Fix: reportAppendableHistory() ahora resuelve raíz/ruta con un helper
compartido (resolveRootAndPath, antes duplicado con createSessionFor),
construye la sesión con una lista vacía, y agrega cada revisión una
sola vez vía session.appendRevision() + partner.acceptRevision().
Esto también explica por qué el 'Unknown error' de README.md nunca
había quedado logueado: el logging que se agregó antes vivía en
createSessionFor(), un método que este camino real (reportAppendableHistory)
ni siquiera invocaba. Ahora tiene su propio logging con stack trace
completo para diagnosticar si el fallo persiste.
- Commit:
04a83492a79c046ffccb7e66432c2826f77894f3- From:
- ale <ale_bnes@tuta.com>
- Date:
Corrige el parseo de got update: 'Already up-to-date' no es un archivo
Reportado en vivo tras arreglar el SSH: Update Project mostraba un
archivo creado falso '/nixdots/eady up-to-date'. got update imprime
texto libre ('Already up-to-date') cuando no hay nada que traer, sin
el patrón 'código + 2 espacios + path' de las líneas de estado reales.
El filtro anterior solo descartaba líneas que empezaran con espacio, y
'Already...' empieza con 'A' -- que además coincide con un código de
estado válido -- así que se parseaba como code='A',
path='eady up-to-date' (substring(3) de 'Already up-to-date').
Fix: exigir que las posiciones 1 y 2 sean espacios antes de tratar la
línea como una entrada de estado. También se quita el -v de got fetch
(era solo diagnóstico temporal, ya no aportaba nada una vez identificado
el problema real de SSH_AUTH_SOCK).
- Commit:
d34058df636afd1f3e5d6930c7cb3a324cb1ae0e- From:
- ale <ale_bnes@tuta.com>
- Date:
Fix real: SSH_AUTH_SOCK llegaba null al proceso de IntelliJ mismo
Confirmado en vivo con el diagnóstico anterior: [SSH_AUTH_SOCK=null] en
el mensaje de error. No era un problema de GeneralCommandLine ni de su
snapshot de entorno -- System.getenv("SSH_AUTH_SOCK") es null en el
proceso de IntelliJ mismo esa sesión (depende de cómo Hyprland lo haya
lanzado). Ningún override dentro del plugin puede inventar un valor
que no existe en el proceso.
Fix: sshAuthSock() cae a la ruta fija del socket ssh de gpg-agent
(/run/user/1000/gnupg/S.gpg-agent.ssh, uid 1000, único usuario de esta
máquina) cuando System.getenv() no lo tiene, verificando que el
archivo exista antes de usarlo. Mismo patrón que ya se usa para la
ruta del binario got -- deuda pendiente de hacer configurable en la
Fase 6.
- Commit:
9be28298176a33ce9e66c71491a8542868357c44- From:
- ale <ale_bnes@tuta.com>
- Date:
Refuerza el fix de entorno: ParentEnvironmentType.SYSTEM + diagnóstico
'got fetch -v' no aportó líneas de debug adicionales de ssh (confirmado
reproduciendo el mismo -v sin SSH_AUTH_SOCK desde una shell normal:
sale idéntico, sin más detalle) -- ese camino de diagnóstico no sirve
para este fallo en particular.
Se refuerza el fix anterior: en vez de solo sobreescribir SSH_AUTH_SOCK
sobre el snapshot de entorno CONSOLE (cacheado por la plataforma), se
fuerza ParentEnvironmentType.SYSTEM para que GeneralCommandLine use
System.getenv() completo como base -- el mismo entorno que ya se
confirmó correcto vía /proc/<pid>/environ del proceso de IntelliJ.
Además, el mensaje de VcsException ahora incluye el valor real de
SSH_AUTH_SOCK visto por la JVM en el momento del fallo, para confirmar
en vivo sin más rondas de adivinar si el valor que llega al subproceso
es el correcto.
- Commit:
a3b2a2982f2e4086fe074ca7a16f14c241d40576- From:
- ale <ale_bnes@tuta.com>
- Date:
Diagnóstico: got fetch -v para depurar el fallo SSH en vivo
El fix anterior (forzar SSH_AUTH_SOCK) no resolvió 'Permission denied
(publickey)' desde el plugin; peor aún, el usuario reporta que la
YubiKey ni siquiera se activa (a diferencia de antes del fix, cuando sí
reproducía el mismo error). Se agrega -v a got fetch, que got reenvía
a ssh(1), para capturar en el mensaje de error qué identidades intenta
ssh y si realmente consulta el agente. Sin esto no hay forma de saber
por qué el subproceso no llega ni a pedir la firma a la llave.
- Commit:
7ac4cd03f42b9a358ea84d07102683763f2235c4- From:
- ale <ale_bnes@tuta.com>
- Date:
Corrige got fetch (SSH_AUTH_SOCK) y agrega logging al historial
Reportado en vivo: 'Update Project' fallaba con 'Permission denied
(publickey)' contra el remoto por SSH, pese a que el gpg-agent (soporte
ssh, clave de YubiKey) funciona perfecto desde una shell normal.
Confirmado: el proceso de IntelliJ SÍ tiene el SSH_AUTH_SOCK correcto
(verificado leyendo /proc/<pid>/environ), pero GeneralCommandLine usa
por defecto un snapshot de entorno cacheado por la plataforma
(EnvironmentUtil), no el entorno real del proceso -- ese snapshot no
coincidía. Fix: se copia explícitamente SSH_AUTH_SOCK desde
System.getenv() al entorno del subproceso antes de cada invocación.
También: 'Show History' reportó 'Unknown error' sin rastro en el log
de IntelliJ (ninguna excepción nuestra debería dar mensaje null).
GotVcsHistoryProvider.createSessionFor() ahora loggea el stack trace
completo de cualquier excepción no-VcsException y la envuelve con un
mensaje no nulo, para poder diagnosticar la próxima vez que ocurra en
vivo -- no se pudo reproducir el fallo original con 'got log' desde
terminal (salió limpio), así que sigue pendiente de reproducir.
- Commit:
f2c271a1a7eb4bc7a6000c5b8ff246338d3ea016- From:
- ale <ale_bnes@tuta.com>
- Date:
Fase 5: historial (got log) y update/fetch desde la UI
GotVcsHistoryProvider + GotVcsHistorySession + GotFileRevision exponen
'got log' en el diálogo nativo de 'Show History': parsea el formato
verbose por defecto (bloques separados por líneas de guiones, 'commit
<hash>', 'from:', 'date:', mensaje indentado) y usa
'got cat -c <hash> -P <path>' para cargar el contenido de cada revisión
bajo demanda.
GotUpdateEnvironment implementa 'Update Project': por cada raíz
seleccionada corre 'got fetch' (best-effort, got.conf puede no tener
remoto) seguido de 'got update', parseando sus códigos de estado
(U/G/C/D/A/!/#) a los FileGroup estándar de IntelliJ.
GotCommandLineWrapper gana log/fetch/update/catAt (cat contra un
commit arbitrario, no solo :base).
- Commit:
86002dd96cc41e1d71f2bcd80782da4e6c1f4d0e- From:
- ale <ale_bnes@tuta.com>
- Date:
Corrige bug real: el commit no ejecutaba got commit
CheckinEnvironment.commit() tiene 3 sobrecargas con implementación
default que se encadenan: la de 2 argumentos delega en la de
CommitContext, que delega en la de NullableFunction, que devuelve null
(no-op). Confirmado con javap -c sobre la interfaz real de la
plataforma (261): la plataforma invoca directamente la sobrecarga con
CommitContext al hacer 'Commit' desde la UI, no la de 2 argumentos.
Como solo se había sobreescrito la de 2 argumentos, el pipeline de
commit de IntelliJ terminaba llamando al no-op por defecto: reportaba
'checkinSuccessful' (sin excepciones) sin que 'got commit' se
ejecutara nunca. Reportado en vivo por el usuario: el diff se veía
bien, no había errores, pero got log no mostraba ningún commit nuevo.
Fix: se sobreescribe también la sobrecarga con CommitContext, y ambas
delegan a la misma lógica (doCommit).
- Commit:
b462f47784c7203ab8c1953668f7f02818d9d4f8- From:
- ale <ale_bnes@tuta.com>
- Date:
Corrige 'Synchronous execution on EDT' en GotContentRevision
GotContentRevision.getRevisionNumber() ejecutaba 'got info' de forma
síncrona; el renderer del árbol de Commit y el título del diff nativo
la invocan directamente desde el hilo de UI (EDT), que IntelliJ prohíbe
para I/O bloqueante (OSProcessHandler#checkEdtAndReadAction). Reportado
en vivo: no rompía el commit en sí (confirmado con 'got log' en
/nixdots), pero inundaba el log del IDE con excepciones en cada
repintado del panel de Commit.
Fix: revisionNumber ahora se resuelve una sola vez fuera del EDT, por
quien construye la instancia -- GotChangeProvider lo resuelve una vez
por raíz (no por archivo) dentro de getChanges(), y
GotDiffProvider.createFileContent() reusa el revisionNumber que ya
recibe como parámetro. getRevisionNumber() pasa a ser una simple
lectura de campo, sin I/O.
- Commit:
ba7062dfbcc4fbe591ab7ce9766e2e1a09a837a8- From:
- ale <ale_bnes@tuta.com>
- Date:
Documenta el estado Fase 1-4 y el flujo de tags firmados por SSH
- Commit:
f6dbcd6e78bee67c9aa0d8594048ff3763574c09- From:
- ale <ale_bnes@tuta.com>
- Date:
Fase 4: commit y rollback desde la UI (got commit / got revert)
GotCheckinEnvironment.commit() no usa 'got stage': commitea exactamente
los paths seleccionados en el panel de Commit vía
'got commit -m msg <paths>', agrupados por raíz got. También implementa
scheduleUnversionedFilesForAddition ('got add') y
scheduleMissingFileForDeletion ('got remove -f') para los flujos de
añadir/eliminar desde la UI.
GotRollbackEnvironment.rollbackChanges()/rollbackMissingFileDeletion()
ejecutan 'got revert -R' sobre los paths afectados; got revert ya
restaura tanto modificaciones como archivos borrados o añadidos
localmente, así que ambos casos comparten la misma implementación.
GotCommandLineWrapper gana commit/add/remove/revert.
- Commit:
ba570446954968ad7b2feb330d7b6371087d413b- From:
- ale <ale_bnes@tuta.com>
- Date:
Fase 3: GotDiffProvider para el gutter de líneas y Show Diff
GotRevisionNumber envuelve el hash del commit base ('got info'). Nuevo
GotDiffProvider resuelve la raíz VCS y ruta relativa de un archivo vía
ProjectLevelVcsManager, y usa GotContentRevision (got cat -c :base) como
contenido de referencia para el line-status-tracker y las acciones de
diff nativas. GotContentRevision ahora reporta el hash real en vez de
VcsRevisionNumber.NULL. Por ahora solo compara contra el commit base
del work tree; comparar contra revisiones históricas queda para la
Fase 5 (historial).
- Commit:
201cc4e4a6b34d9ad7518c89b4cbe0d4a7a8907a- From:
- ale <ale_bnes@tuta.com>
- Date:
Corrige el build: Gradle 9, bundledModule y tipos de ChangeProvider
- nixpkgs.gradle (8.14.4) no alcanza el mínimo de Gradle 9.0.0 que exige
el plugin org.jetbrains.intellij.platform 2.18.1; el devShell ahora usa
gradle_9 (9.5.1).
- com.intellij.modules.vcs es un módulo bundleado, no un plugin:
bundledPlugin(...) -> bundledModule(...).
- processUnversionedFile espera FilePath, no VirtualFile; LocallyDeletedChange
tiene un solo argumento (FilePath). Ignora .intellijPlatform/ (caché del
Gradle plugin, análogo a .gradle/).
'nix develop -c gradle buildPlugin' genera build/distributions/gotvcs-intellij-0.1.0.zip.
- Commit:
701fffebad34d0f36f5fd2165569f42d177ffef9- From:
- ale <ale_bnes@tuta.com>
- Date:
Implementa estado de archivos read-only vía got status
GotCommandLineWrapper centraliza la ejecución de got (GeneralCommandLine +
ExecUtil) y parsea 'got status' (formato XY path). GotChangeProvider mapea
los códigos de estado a FileStatus y reporta al ChangelistBuilder.
GotContentRevision expone el contenido base ('got cat -c :base -P') como
beforeRevision, para que el preview de diff del panel de Commit funcione.
- Commit:
8f270315ac1a03425e7daccc1db3b14cd7080df8- From:
- ale <ale_bnes@tuta.com>
- Date:
Registra el VCS got: plugin.xml, GotVcs y GotVcsRootChecker
Detecta carpetas .got/ como raíces de VCS y expone el nombre 'got' en
Settings > Version Control. Sin funcionalidad de status/diff/commit todavía.
- Commit:
edc0c44350371dc0b3e15d49841846c50800bf67- From:
- ale <ale_bnes@tuta.com>
- Date:
Scaffold inicial: flake devShell (JDK21+Gradle), Gradle build para IntelliJ Platform Plugin 2.18.1 apuntando al IntelliJ local, README
