GitBolt 0.9.7

Open in GitBolt comes to Finder on macOS, and a folder inside a
repository now opens that repository on every platform. Also: Fetch
and Push run in a bare repository instead of wherever GitBolt was
started, linked worktrees and submodules refresh on their own, Edit
URL keeps a remote's upstream branches, GitBolt's links follow the
project to its new home at github.com/Inverian/GitBolt, and there is a
security policy for reporting vulnerabilities privately.

Added

• Open in GitBolt from Finder (macOS): right-click a folder in
  Finder and choose Open in GitBolt (in the Services submenu when there
  are several) to open its repository, whether GitBolt is running or
  not. It is a macOS service that comes with GitBolt.app, so there is
  nothing to install; it shows once GitBolt has been opened once (if
  it doesn't, turn it on in System Settings › Keyboard › Keyboard
  Shortcuts… › Services › Files and Folders). Folders dropped on
  GitBolt's Dock icon, and open -a GitBolt <folder>, now open too;
  before, GitBolt ignored them.

Changed

• A folder inside a repository opens that repository, from Finder,
  File › Open Repository, Explorer, Nautilus or gitbolt <path>.
  Before, only the repository's own folder opened, and Nautilus offered
  Open in GitBolt only there. The search stops at your home folder: a
  repository there (dotfiles, say) never claims a folder below it that
  is in no repository of its own.
• A folder that is in no repository now says so ("… is not in a
  Git repository."), instead of showing libgit2's error.
• A minimized window comes back when a folder is sent to GitBolt
  (Open in GitBolt from Finder or Explorer, a Dock drop,
  gitbolt <path>, and Nautilus on X11). Before, the repository opened
  in the window while it stayed minimized. Under Wayland GitBolt isn't
  told that its window is minimized, so it can't bring it back there.
• Links: the project moved to the Inverian organization on GitHub,
  and GitBolt's links went with it: Help › User manual, Report an
  issue and Check for updates, the About box, the home screen's
  Develop and Issues links, the privacy policy link in Settings, the
  Windows installer's help link and the Linux AppStream metadata now
  point to github.com/Inverian/GitBolt. The old links still redirect
  there.

Fixed

• Bare repositories: with a bare repository open, Fetch, Push,
  Pull, the background fetch and the other commands GitBolt runs
  through git ran in GitBolt's own working folder instead of the
  repository. Started from a terminal inside another repository, Push
  pushed that repository's commits to its remote. They now run in the
  bare repository, also where git's safe.bareRepository setting is
  explicit. Pull and Commit, which need a working tree, are off
  there. File Explorer, Git bash and GitK open the bare repository,
  and Open Externally and Edit .gitignore (and the other working-tree
  files) say it has no working tree.
• GIT_DIR, GIT_WORK_TREE and git's other repository variables in
  GitBolt's own environment (a shell that exports them for a bare
  dotfiles repository, say) no longer reach anything GitBolt starts:
  its git commands, its Console and Git bash terminals, GitK, or an
  editor that Open Externally opens. They sent git's commands to that
  repository: Push pushed its commits while GitBolt showed the one
  that was open. An exported GIT_CONFIG hid the repository's own fetch
  settings from Fetch's prune check, so a fetch could delete local tags
  that the server doesn't have, and it left Settings › Git › Git Config
  empty, with Apply saving nothing.
• Crashes on config lines with no value (a name and no = value,
  which git reads as true, and refuses where it needs text): a
  committed .gitmodules whose path had none, or an empty one,
  crashed GitBolt as it opened the repository, a freshly cloned one
  included, and so did an extensions.objectformat with none. A
  url.<base>.insteadOf or pushInsteadOf with none, in any git
  config, your global one included, crashed Repository › Remote
  repositories and Plugins › Statistics, and a branch.<name>.remote
  with none crashed removing a remote. The repository now opens, or,
  for objectformat, says what is wrong with it.
• A submodule that leads back out of its repository: a
  .gitmodules whose submodule path is /, or goes through a committed
  symlink to . or .. (one submodule down or several), made GitBolt
  open a repository it was already reading as a submodule of its own,
  over and over, until it crashed, as it opened the repository, a
  freshly cloned one included. Such a submodule is now taken as not
  checked out, and, like git, GitBolt no longer follows a submodule's
  path through a symlink.
• Linked worktrees and submodules opened in GitBolt now refresh
  when a commit, staging or a branch switch happens outside GitBolt.
  Their .git is a file pointing elsewhere, and GitBolt never watched
  the git dir it points to, so only changes to the files in the working
  tree were noticed.
• Edit .git/info/exclude works in a linked worktree (it edits the
  repository's shared info/exclude), and Sparse Working Copy › Edit
  patterns shows the worktree's own current patterns. Both looked
  for a .git folder that a linked worktree doesn't have: the first
  couldn't save, the second started empty.
• Edit URL (Repository › Remote repositories) changes only the
  remote's URL, as git remote set-url does. It used to remove the
  remote and add it back, which also dropped every branch's upstream
  link to it (Pull then failed, saying no branch was given), its
  remote-tracking branches, and its push URL, refspecs and options.
  A remote defined outside the repository's own config (in your global
  git config, a file a config includes, or a worktree's own
  config.worktree) is refused before anything changes, with a note
  saying where it is defined; before, Edit URL failed on such a remote
  only after dropping its remote-tracking branches and every branch's
  upstream link to it. A remote with several URLs (git remote set-url --add) is refused with a note that lists them and says where they
  are, or how to change them.

Security

• Security policy: SECURITY.md says how to report a vulnerability
  privately, through GitHub's private vulnerability reporting, who
  reviews reports, and what to expect.