Guía de colaboración del proyecto OrejanOS

Guía de colaboración y filosofía de contribuciones del proyecto OrejanOS (y de proyectos en general de Entropía binaria).

¡Hola! Si estás acá con ganas de aportar, te doy la bienvenida.

Crear software en comunidad es infinitamente más valioso y enriquecedor que construir en solitario. Trabajar en equipo es un placer, y este proyecto existe y crece gracias al impulso del software libre y de la comunidad que lo sostiene.
Sin embargo, para que este espacio sea sostenible y para que yo pueda mantener más de 60 proyectos activos sin quemarme, necesitamos acordar las reglas de colaboración desde el primer momento.

Mi visión sobre la ayuda.

Partamos de una premisa simple: la ayuda tiene que sumar, no complicar. Si una colaboración exige una carga mental abrumadora para ser auditada o genera estrés en el mantenedor, deja de ser ayuda para esa persona.
Esto no es por soberbia ni por rechazo a otras formas de trabajar. Simplemente reconozco mis propios límites cognitivos: no pertenezco ni deseo encajar en el flujo de trabajo tradicional basado en la burocracia de Git. Revisar pull requests, merges, diffs o patches que potencialmente alteran múltiples archivos al mismo tiempo me genera un ruido y una ansiedad innecesarios.
Por eso, este proyecto se gestiona mediante un modelo de colaboración modular e integrada, diseñado para que colaborar sea claro, concreto y predecible para todos.

Cómo colaborar (estos aportes son bienvenidos y se agradecen de corazón).

Acepto con gusto y gratitud cualquier aporte que mantenga un límite claro de impacto y no requiera auditar metainformación ruidosa.

• Módulos enteros aislados: si construís una funcionalidad o módulo completo listo para anexar al proyecto (tipo "plugin" o componente), bienvenido sea. Sé exactamente lo que hace y cómo se conecta.
• Funciones aisladas: código nuevo, cerrado y encapsulado (por ejemplo, una función específica que resuelva un problema puntual).
• Reescritura de funciones específicas: si detectás una función mal optimizada o mal escrita y me alcanzás la versión corregida de esa función concreta.
• Reportes de errores precisos y visuales: descripciones claras de bugs ("al presionar Z en el menú X, el programa se cierra") o capturas/pasos exactos para reproducir un comportamiento.

Cómo NO colaborar.

Para proteger el ritmo del proyecto y la tranquilidad de quien lo mantiene, no se procesará lo siguiente.

• Pull Requests (PRs), Merge Requests o parches tradicionales.
• Cambios que toquen múltiples archivos en simultáneo o alteren la estructura global.
• Diffs o revisiones que requieran auditar metadatos de control de versiones.

Un puente para todos.

Exigir el dominio y el uso de flujos complejos de control de versiones a menudo deja afuera a muchísima gente que sabe programar y que quiere y puede dar una mano. Este modelo busca abrir la puerta a aportes directos, prácticos y modulares.
Si querés colaborar dentro de este esquema, tu código y tu tiempo van a ser enormemente valorados.

¡Gracias por respetar la casa, comprender, cuidar la energía de quienes mantenemos esto vivo y ser parte del software libre que cada día ebulliciona y viene con efervescencia en Entropía binaria!

Read More

Cómo sobrescribir un repositorio remoto en Codeberg con archivos locales.

Sobrescribir un repositorio remoto con tus archivos locales.

Es normal que hayamos subido un proyecto a CodeBerg en el momento en el que el mismo era funcional, y que luego hayamos seguido trabajando en él "localmente" para "pulirlo", actualizarlo, agregarle funcionalidades, etc.

En esta entrada vamos a ver cómo hacer para que dichas actualizaciones y cambios se reflejen en CodeBerg. ¡Mirá qué fácil que es!

1. Abrí una terminal en el directorio raíz de tu proyecto (es decir, en la carpeta de tu proyecto).

2. Agregá todos los archivos locales (nuevos, modificados, "borrados", etc.):
git add .

3. Confirmá los cambios con un mensaje informativo que te parezca acorde:
git commit -m "Actualización general del proyecto."

4. Forzá el "push" al repositorio remoto para sobreescribir todo en la rama "main":
git push origin main --force

¡Listo! Tus archivos locales han reemplazado a todos los que estaban en tu proyecto, en Codeberg.

Podés tener plena seguridad de que tu repositorio remoto será un espejo exacto de tu directorio local, ya que el "--force" del script se encarga exactamente de eso. Y si llegara a haber archivos en el repositorio remoto que ya no deberían estar allí, se borrarán con el push forzado, ya que git entenderá que si no existen localmente, no deberían estar presentes remotamente, tampoco. Dicho de manera simple: el directorio que "manda", es el local.

Read More

Cómo subir más archivos o carpetas a un proyecto existente de Codeberg.

 

Cómo subir más archivos o carpetas a un proyecto existente de Codeberg.

1. Verificá si estás en la rama correcta en CodeBerg (por ejemplo, "main" o "master"):

git branch

Esto te mostrará la rama actual (marcada con un "*"). Si ves que no estás en la rama correcta, cambiala con:

git checkout nombre_de_la_rama

2. [OPCIONAL] Confirmá, también, que los archivos estén en el repositorio local:

ls -R

Esto listará todos los archivos y carpetas de tu proyecto en tu computadora. Si los mismos no aparecen, verificá si realmente los creaste (o copiaste, o moviste) correctamente al directorio local del proyecto.

3. Añadí los archivos y/o directorios al control de versiones del próximo "commit":

git add directorio_1
git add directorio_2
git add archivo_1
git add archivo_2
etc.

Si los elementos son muchos y querés agregarlos a todos de una sola vez, podés hacer "git add ."

Nota: Git ignora a las carpetas vacías: de ser este el caso, Git no las subirá. Asegurate de que los archivos necesarios estén dentro.

4. Creá un "commit" con los cambios. Ejemplo:

git commit -m "Se agrega un directorio conteniendo 3 archivos."

5. Subí todo a la rama remota:

git push origin nombre_de_la_rama

¡Pronto!

Read More

Brevísimo manual para subir scripts BASH a Codeberg

Brevísimo manual para subir scripts BASH a Codeberg.

Este proceso asume que ya tenés a git instalado.
Ante cualquier error, consultá la última sección (NOTAS IMPORTANTES).

 

Paso 1: inicializar un repositorio git local.

• Abrí tu terminal en el directorio en donde tengas el script y las carpetas con los sub-archivos del mismo.
• Una vez ahí, inicializá un repositorio git local con "git init" (esto creará una carpeta oculta ".git" en tu directorio, la cual git utilizará para rastrear los cambios)

La salida que verás en la terminal luego de ejecutar "git init", será similar a esta:

hint: Usando 'master' como el nombre de la rama inicial. Este nombre de rama predeterminado
hint: está sujeto a cambios. Para configurar el nombre de la rama inicial para usar en todos
hint: de sus nuevos repositorios, reprimiendo esta advertencia, llama a:
hint:
hint: git config --global init.defaultBranch <nombre>
hint:
hint: Los nombres comúnmente elegidos en lugar de 'master' son 'main', 'trunk' y
hint: 'development'. Se puede cambiar el nombre de la rama recién creada mediante este comando:
hint:
hint: git branch -m <nombre>
hint:
hint: Disable this message with "git config set advice.defaultBranchName false"

Paso 2: añadir tus archivos al repositorio.

Ahora, hay que decirle a git qué archivos querés que incluya en tu primer "paquete" de cambios. Vas a querer incluir el script junto con las carpetas del mismo, si es que las hay.

• git add script.sh
• git add carpeta/

Si tenés otros archivos importantes (licencia, archivos tipo "info", etc.), también agregalos utilizando el mismo procedimiento.

Si querés agregar todos los archivos nuevos y modificados en el directorio actual (cuidado con esto, asegurate de no incluir cosas que no querés), podés hacer "git add ." (el punto importa, y significa "todo lo que está acá").

Si quisieras subir casi todo, pero no todo (por ejemplo, podrías tener una carpeta llamada "respaldos" en donde fuiste guardando copias de tu proyecto, las cuales sería innecesario que luego quedaran en el repositorio de CodeBerg -es mi caso-), podés hacer esto:

- Creá un archivo llamado ".gitignore" en el directorio raíz del proyecto.
- Dentro del mismo, escribí el nombre exacto de los archivos y directorios que no quieras que sean subidos a CodeBerg. Guardalo.
- Ejecutá "git add ." y automáticamente se subirá todo al repositorio, excepto los archivos y carpetas cuyos nombres coincidan con exactitud con las líneas introducidas en ".gitignore".

NOTA: el uso de comodines (*) está soportado.

Paso 3: confirmar los cambios (commit).

Ahora, git ya sabe qué archivos añadir. Creá una "instantánea" de esos cambios con un mensaje que describa lo que hiciste. Esto se llama "commit".

• git commit -m "Menú interactivo con barra en reversa."

El mensaje es importante para que vos (y otros) entiendan qué contiene ese commit.

Paso 4: crear un repositorio en Codeberg.

• Ahora andá a la web de Codeberg en el navegador: https://codeberg.org/
• Iniciá sesión.
• Hacé clic en el botón "+" (arriba, a la derecha) y seleccioná "Nuevo repositorio".
   
  
  
  
• Ponele un nombre representativo (ej: menu).
• Podés añadir una descripción opcional.
• Desmarcá la opción "Inicializar el repositorio" si vas a subir tus propios archivos "README". De no ser así, podés pedirle a CodeBerg que lo haga por vos, marcando esta opción.
• Definí el tipo de licencia que quieras para tu proyecto. En nuestro caso, utilizamos "GPL 3.0 or later". Para que te aparezca esta opción, debés marcar la casilla "inicializar el repositorio".
• Hacé clic en el botón azul "Crear repositorio".
• Una vez creado, Codeberg te mostrará unas instrucciones. Buscá la sección que dice algo así como "enviar un repositorio existente desde la línea de comandos". Vas a necesitar las dos líneas de comando que te dará. Si CodeBerg simplemente crea el repositorio y no te brinda esta información, simplemente andá arriba, a la derecha, y copiá la línea "https://codeberg.org ... script.git".
  
  
  

Paso 5: conectar tu repositorio local con Codeberg.

• Volvé a tu terminal.
• Utilizá las dos líneas que te dio Codeberg (van a ser algo como esto, pero con tu nombre de usuario y el nombre de tu repo):
  
  git remote add origin https://codeberg.org/tu_usuario/tu_script.git
  
  git pull origin main --rebase
  
  git branch -m main

Acordate de que si no te dio esa información, podés obtenerla manualmente en el paso anterior (es la que figura en azul).
La primera línea (la azul) le dice a tu repositorio local dónde está el repositorio remoto en Codeberg.
La segunda, renombra tu rama principal a "main" (es la convención moderna).
La tercera, sincroniza los cambios iniciales (README/licencia).

Paso 6: subir tus cambios a Codeberg (push).

• Finalmente, enviá todos tus cambios locales (el commit que hiciste) al repositorio en Codeberg con "git push -u origin main"

Te pedirá tu nombre de usuario y tu contraseña de Codeberg (o un token de acceso, si configuraste SSH).

¡Listo! Ahora, toca ir a la página de tu repositorio en Codeberg y ver que están todos tus archivos ahí, y que se actualizaron (o subieron) "hace 1 minuto".

NOTAS IMPORTANTES:

Si por alguna razón tenés que empezar de nuevo (te equivocaste, algo salió mal, etc.), tenés que borrar el directorio oculto ".git" que fue creado cuando hiciste "git init".

Si te "salta" este error en rojo

error: falló el empuje de algunas referencias a 'https://codeberg.org/tu_usuario/tu_script.git'

solucionalo así:

git pull --rebase origin main
git push origin main

Si en algún momento ves este mensaje:

Identidad del autor desconocido

*** Por favor cuéntame quién eres.

Ejecuta

git config --global user.email "you@example.com"
git config --global user.name "Tu Nombre"

para configurar la identidad por defecto de tu cuenta.
Omite --global para configurar tu identidad solo en este repositorio.

fatal: no es posible auto-detectar la dirección de correo (se obtuvo 'entropia@entropia-artix.(none)')

podés resolverlo ingresando las siguientes líneas en la terminal:

git config --global user.email "entropiabinaria38911@gmail.com"
git config --global user.name "Entropía binaria"

y volvé a repetir la línea que habías ejecutado sin éxito.
Esto generalmente sucede al procesar, por ejemplo:

git commit -m "Menú interactivo con barra en reversa."

Read More