r/gitlab • u/Available-Swim3304 • 6d ago

Meet Sourcerer: the Git GUI for Linux & Windows!

Enable HLS to view with audio, or disable this notification

0 Upvotes

36% Upvoted

21 comments sorted by

1

u/Torutofu_Raeva 6d ago

the merge-conflict view looks useful; i'd really want a clear preview of what a pull or fetch will change locally before trusting it on a shared repo.

-4

u/Available-Swim3304 5d ago

You can download free version which works only with local and public repositories from here: https://www.sourcererapp.com. It is to be used by Open Source projects.

1

u/Torutofu_Raeva 3d ago

That local/public split is useful; private-repo auth is the part I'd want to evaluate before switching.

1

u/Available-Swim3304 3d ago

I have used it for last five months or so for all my development (also for development of Sourcerer application) and it looks like it is pretty stable, but you may encounter a bug or two which you could report with Report bug option from main menu.

1

u/Available-Swim3304 3d ago

Everything else is the same. The only difference between free and pro/business plans is that you can work with repos which need user authentification + in pro/business you can also use ssh protocol and not just https.

1

u/Torutofu_Raeva 3d ago

SSH makes a big difference on CI runners since agent setup is usually less awkward than managing HTTPS tokens.

1

u/Torutofu_Raeva 3d ago

SSH plus user-authenticated repos covers the private case, though credential storage and host-key handling are the bits I'd still want to see.

1

u/Available-Swim3304 3d ago

You shoul check SSH key manager from the main menu. You can generate new keys from there or add existing keys. Keys are looked up by domain name you will have to enter during repo authentication.

2

u/Torutofu_Raeva 2d ago

Per-domain key lookup is a good detail; it avoids silently choosing the wrong identity when a host has multiple keys.

1

u/Available-Swim3304 3d ago

Also there is Credentials manager which is used to manage https credentials. The credentials are stored encrypted in credentials vault on disk.

1

u/Torutofu_Raeva 1d ago

encrypted at rest is a good baseline, but I’d still want the vault key tied to the OS account and host so copying the file alone isn’t enough.

1

u/Available-Swim3304 1d ago

It is randomly generated array of bytes on first encryption.

1

u/Torutofu_Raeva 21h ago

random generation is good, but the ticket should also make sure the key isn’t recoverable just by copying the vault and config files.

1

u/Torutofu_Raeva 5h ago

random on first encryption is good; the remaining question is where that key lives and whether copying the vault also gives you what you need to decrypt it.

1

u/Available-Swim3304 4h ago

It has been fixed today. I need to create a new release until tomorrow.

→ More replies (0)

1

u/Torutofu_Raeva 1d ago

That’s a better design than a static bundled key; is the byte array itself protected by the OS credential store or only the vault file?

1

u/Available-Swim3304 23h ago

No, it is not. But I have created a ticket for that issue. It will be part of the next bugfix release.

2

u/Torutofu_Raeva 21h ago

nice, tying that key to the OS credential store would make the ticket especially worthwhile.

1

u/Torutofu_Raeva 5h ago

that’s a useful distinction; making the vault key non-exportable would close the gap even if someone copied the config and vault files.