11 KiB
fxg — pomysły na QoL (Quality of Life)
Dokument roboczy. Każdy pomysł ma tytuł, opis, przykład użycia i szacunkową trudność implementacji.
Wysoki priorytet
1. fxg clone — pobierz wszystkie repozytoria jedną komendą
Problem: Na nowym laptopie masz 50 repo na GitHubie. Musisz je klonować jedno po drugim. Żmudne.
Rozwiązanie: Komenda pobierająca listę repo z API i klonująca je do workspace_root.
fxg clone --mine # repo których jesteś właścicielem
fxg clone --contributed # repo w których robiłeś commity (contributor)
fxg clone --org mojaFirma # wszystkie repo organizacji
fxg clone --starred # repo które oznaczyłeś gwiazdką
# z filtrowaniem
fxg clone --mine --filter "frontend" # tylko repo z "frontend" w nazwie
fxg clone --mine --limit 20 # max 20 repo
Implementacja: Wywołać provider.list_repos() (nowa metoda w trait Provider), przefiltrować, wywołać git clone dla każdego. Wyświetlić progress w TUI podobny do sync.
Trudność: średnia — wymaga nowej metody w każdym providerze (GitHub/GitLab/Gitea API wszystkie to obsługują).
2. Tagi jako organizacja folderów lokalnych
Problem: Masz 50 repo i wszystkie są w jednym workspace_root/. Chaos.
Rozwiązanie: Tag przypisany do repo = podfolder w workspace_root. repo z tagiem dev ląduje w workspace_root/dev/, repo z tagiem client-acme ląduje w workspace_root/client-acme/.
# przy tworzeniu repo
fxg init moj-projekt --tags dev,frontend
# retroaktywnie
fxg tag moj-projekt add client-acme
fxg tag moj-projekt remove dev
# reorganizacja lokalna — przenieś foldery według tagów
fxg workspace organize # pyta o potwierdzenie przed każdym przeniesieniem
fxg workspace organize --dry-run # pokaż co by się przeniosło, bez wykonania
Wynikowa struktura:
~/projekty/
├── dev/
│ ├── api-backend/
│ └── shared-utils/
├── client-acme/
│ ├── acme-website/
│ └── acme-mobile/
└── archived/
└── stary-projekt/
Implementacja: Przechowywać tagi per-repo w workspaces.toml lub osobnym tags.toml. Komenda organize tworzy podfoldery i przenosi repo (lub tworzy symlinki — symlinki są bezpieczniejsze, bo oryginał zostaje w miejscu).
Trudność: średnia — logika przenoszenia + aktualizacja workspace_root per-repo.
3. Domyślna paczka plików przy fxg init
Problem: Przy tworzeniu repo trzeba pamiętać o zaznaczeniu README, CHANGELOG, .env.example w wizardzie. Zawsze się o czymś zapomni.
Rozwiązanie: Konfigurowalna lista plików tworzonych domyślnie (bez pytania), z możliwością wyłączenia.
# ~/.fxg/config.toml
default_init_files = ["README.md", "CHANGELOG.md", ".env.example", ".gitignore"]
fxg init moj-projekt # tworzy domyślny zestaw
fxg init moj-projekt --no-defaults # tworzy puste repo
fxg init moj-projekt --files readme,license # tylko te dwa
Dodatkowo: szablony zawartości pliku README konfigurowalne w config.toml (readme_template = "heartbyte-default" już istnieje w konfigu, ale nie jest zaimplementowane).
Trudność: niska — już mamy InitConfig z polami readme, changelog itd., wystarczy ustawić domyślne wartości z configa zamiast false.
4. fxg sync branch cleanup — sprzątanie zmergowanych gałęzi
Problem: Po miesiącach pracy masz 30 lokalnych gałęzi, z których 25 jest już zmergowanych do main. Zajmują miejsce, mylą.
Rozwiązanie:
fxg sync branch cleanup # interaktywny wybór (TUI lista)
fxg sync branch cleanup --all # usuń wszystkie zmergowane bez pytania
fxg sync branch cleanup --dry-run # pokaż co by się usunęło
Usuwa gałęzie które są już zmergowane do main/master — lokalnie i opcjonalnie zdalnie.
Implementacja: git2 — repo.branches(), sprawdzenie czy jest zmergowana przez repo.merge_analysis(). Już mamy delete_branch() w sync/mod.rs.
Trudność: niska — wszystkie potrzebne funkcje git2 już są w kodzie.
Średni priorytet
5. Shell completions (bash / zsh / fish / PowerShell)
Wpisanie fxg <Tab> podpowiada:
- subkomendy (
status,sync,init...) - nazwy repo dla
fxg status <Tab>→ lista repo z workspace_root - nazwy workspace dla
--workspace <Tab> - aliasy kont dla
fxg auth switch <Tab>
fxg completions bash >> ~/.bashrc
fxg completions zsh >> ~/.zshrc
fxg completions fish > ~/.config/fish/completions/fxg.fish
fxg completions powershell >> $PROFILE
Implementacja: clap ma wbudowany generator completion przez crate clap_complete. Dynamiczne uzupełnianie nazw repo wymaga osobnego skryptu który wywołuje fxg --list-repos (nowa ukryta flaga).
Trudność: niska (statyczne) / średnia (dynamiczne nazwy repo).
6. fxg status --watch — live monitoring workspace
fxg status --watch # odświeża TUI co 30 sekund
fxg status --watch --interval 10 # co 10 sekund
TUI pokazuje kiedy ostatnio odświeżono. Przy zmianie statusu (np. nowy commit na serwerze) wiersz miga przez chwilę na żółto.
Implementacja: Tokio timer w pętli TUI, wywołuje scan_workspace() co N sekund. Detekcja zmian przez porównanie ahead/behind z poprzednim stanem.
Trudność: niska — już mamy scan_workspace() i pętlę TUI.
7. Szablony projektów (fxg init --template)
fxg init moj-projekt --template react-app
fxg init moj-projekt --template rust-cli
fxg init moj-projekt --template python-fastapi
fxg init moj-projekt --template node-express
Każdy szablon tworzy kompletną strukturę katalogów i pliki startowe:
react-app→src/,public/,package.jsonz React,.eslintrc, Dockerfilerust-cli→src/main.rs,Cargo.tomlz clap+anyhow,README.mdpython-fastapi→main.py,requirements.txt,.env.example,Dockerfile
Szablony przechowywane w ~/.fxg/templates/ jako foldery — użytkownik może dodać własne.
Trudność: średnia — logika tworzenia plików jest już w init/mod.rs, potrzebny nowy system szablonów.
8. fxg pr list — przegląd otwartych PR
fxg pr list # wszystkie PR we wszystkich repo workspace
fxg pr list --repo moj-projekt # tylko jedno repo
fxg pr list --mine # tylko PR gdzie jesteś autorem lub reviewerem
Wyświetla TUI tabelę: repo | numer | tytuł | autor | data | etykiety.
Enter na PR otwiera URL w przeglądarce.
Implementacja: Nowa metoda list_pull_requests() w trait Provider, wywołanie API. GitHub/GitLab/Gitea wszystkie to mają.
Trudność: średnia — nowa metoda w każdym providerze.
9. Globalny .fxgignore — repo do pominięcia
# ~/.fxg/ignore
archived-* # wszystkie repo zaczynające się od "archived-"
old-monorepo # konkretne repo po nazwie
scan_workspace() pomija pasujące foldery. Przydatne gdy workspace_root zawiera też foldery inne niż repo git.
Implementacja: Dodać ignore_patterns: Vec<String> do AppConfig, sprawdzać przy scan_workspace().
Trudność: niska.
10. fxg stats --trend — wykres aktywności w czasie
fxg stats --trend # ostatnie 30 dni
fxg stats --trend --days 90
fxg stats --trend --repo api-backend
ASCII wykres słupkowy commitów per dzień:
Aktywność (ostatnie 30 dni) — api-backend
May 01 ████████░░░░░░░░░░░░░ 8
May 08 ████████████░░░░░░░░░ 12
May 15 ██████░░░░░░░░░░░░░░░ 6
May 22 ██████████████████░░░ 18
Implementacja: revwalk po historii commitów + grupowanie po dniach. Już mamy git2 w projekcie.
Trudność: niska.
Przyszłość / ambitne
11. VSCode Extension — automatyczne time tracking
Aktualnie fxg stats time czyta pliki JSON z ~/.fxg/vsc-data/. Trzeba je tworzyć ręcznie lub osobnym narzędziem.
Rozwiązanie: Towarzyszące rozszerzenie VS Code które automatycznie zapisuje czas spędzony na plikach w formacie rozumianym przez fxg.
fxg stats time # pokazuje automatycznie zbierane dane
12. Webhook przy każdym sync
Opcjonalny URL w config.toml:
sync_webhook = "https://discord.com/api/webhooks/..."
Po każdym udanym push wysyła embed z: repo, branch, commit message, autor.
Identyczny mechanizm jak audit log w innych projektach z tego zespołu.
Trudność: niska — prosty reqwest::post po każdym push_repo().
13. AI-assisted commit messages
fxg sync commit --ai # generuje wiadomość z diff za pomocą AI API
fxg sync commit --ai --edit # generuje, ale otwiera edytor do poprawki przed commitem
Wysyła git diff --staged do API (np. Claude lub OpenAI), dostaje propozycję wiadomości w stylu conventional commits.
Wymaga klucza API w konfiguracji.
14. fxg release multi-platform publish
Po stworzeniu release tagu — automatyczne wyzwolenie publishu na:
crates.io(dla Rust)npm(dla Node.js)PyPI(dla Python)
Wykrywa typ projektu przez detect_project_type() (już istnieje w summary/mod.rs).
15. Interaktywny diff viewer
W widoku szczegółowym repo (fxg status <repo>) — klawisz d otwiera inlinowy diff zmienionych plików z kolorowym podświetleniem:
M src/components/Nav.tsx [d] diff [s] stage [r] revert
─────────────────────────────────────────
- const navItems = ["Home", "About"];
+ const navItems = ["Home", "About", "Contact"];
Trudność: wysoka — wymaga parsowania diff output i renderowania w ratatui.
Szybkie podsumowanie priorytetów
| # | Pomysł | Priorytet | Trudność |
|---|---|---|---|
| 1 | fxg clone --mine/--contributed |
Wysoki | Średnia |
| 2 | Tagi → organizacja folderów | Wysoki | Średnia |
| 3 | Domyślna paczka plików przy init | Wysoki | Niska |
| 4 | branch cleanup |
Wysoki | Niska |
| 5 | Shell completions | Średni | Niska–Średnia |
| 6 | status --watch |
Średni | Niska |
| 7 | Szablony projektów | Średni | Średnia |
| 8 | pr list |
Średni | Średnia |
| 9 | .fxgignore |
Średni | Niska |
| 10 | stats --trend |
Średni | Niska |
| 11 | VSCode extension | Przyszłość | Wysoka |
| 12 | Webhook przy sync | Przyszłość | Niska |
| 13 | AI commit messages | Przyszłość | Średnia |
| 14 | Multi-platform publish | Przyszłość | Wysoka |
| 15 | Diff viewer w TUI | Przyszłość | Wysoka |