Oxidize GitButler

[Byron]

Used Git2 Features

The list is probably not completely exhaustive, omitting smaller features intentionally as they are covered, and focussing on the bigger picture.

• [x] refspecs
• [x] init (and fail if present already) , bare or non-bare
• [x] get configuration by scope
• [x] set configuration by scope and write it back while keeping comments/nonedestructively
  • [ ] writes are convenient through high-level API
• [x] read and traverse git configuration
• [x] fetch a remote (and handle credentials like Git would)
• [ ] given a remote tracking branch like refs/heads/remotes/origin/foo/bar, provide the reverse mapping to the remote ref name, like refs/heads/foo/bar all while respecting refspecs. The question is if this can work reliably without guessing too much.
• [ ] in-memory .gitignore rules, so that any user of excludes gets these automatically
• [ ] add ODB alternates
• [ ] add submodule
• [ ] use git-remote helpers, i.e. codecommit or rad.
• [ ] 'is descendant of' query
• [ ] merge base query
• [ ] create a new remote (primitives exist, but there is no higher-level method for it)
• [ ] rename reference (there is no shortcut for this, just lower-level primitives delete+create)
• [ ] git add . - with proper worktree filtering (add currently unsupported, but worktree filter could help already)
• [ ] diff tree to workdir (primitives exist)
• [ ] merge trees
• [ ] rebase
• [x] find remotes
• [x] find head and deal with refs in general (peeling, etc)
• [x] diff tree with tree
• [ ] reset
• [x] find objects and deal with them in various ways
• [x] revwalk (even though it's still to be seen if the algorithm is what's expected, see the topo-walk discussion
• [x] query excludes/.gitignore - but should be performed on all available paths
• [x] get the index
• [ ] cherry pick
• [x] create a new commit
• [ ] create a new signed commit (and respect these settings even when rebasing)
• [ ] build a new tree by API
• [x] obtain remote branch names in various flavours
• [ ] git status (primitives exist, WIP)
• [ ] checkout head/index/tree (checkout exists, but this needs 'reset' functionality)
• [ ] optionally run hooks on commit (and other events maybe, just like Git)
• [x] walk a tree
• [ ] index to tree
• [x] tree to index
• [ ] complete diff based on git status equivalent (primitives exist)

Wanted

What follows is prominent issues from the GitButler tracker.

• Windows Support
  • [x] natively supported
  • [ ] there may be rough edges around program and hook invocations, to be smoothed out of time (probably this is about more than Git though, currently unclear)
• SSH Authentication
  • [x] ssh is used, which is exactly what git does.
  • [ ] on Windows, there is no native ssh transport yet which might be worse than git2 right now. See #1246 for more.
• Git LFS support
  • [x] checkouts will call filter programs, thus checkout LFS files
  • [x] diffs will apply all diff-related features and handle LFS files correctly
  • [ ] additions, i.e. git add, aren't possible yet, but when they are they will call worktree filters
• Opening Submodules
  • [x] Works in theory, even though it's unclear what's happening that it's not working currently
• Local ref handling
  • Making these entirely transparent to git log --all might be possible with namespaces. Maybe worth a try.

Here is the repo: https://github.com/gitbutlerapp/gitbutler

Guiding Principles

After our in-person meet, I kept mentioning a few driving principles that I find valuable to keep in mind when planning the next steps.

• The transition to gitoxide should be step-wise.
• Each step should yield meaningful, perceivable value for the user of the application.
• It's OK to not reach goals directly, i.e. use intermediate mechanisms that help now, knowing that they will be removed later.

gitoxide is an implementation detail, but ultimately it will drive down the implementation complexity of the application while improving its performance and compatibility.

Notes on issues

From time to time, one can look into issues that are waiting for feedback.

Try to fix this when converting to gitoxide

Check the `gitoxide label for more.

Big Problems

Architecturally, there might be issues in resolving these:

• https://github.com/gitbutlerapp/gitbutler/issues/3319 (resolving conflicts with the usual set of tools)

Requested features

Roughly in order of effort-for-value

• Open gitbutler in a repository from the terminal with gitbutler . (see this comment)
• Better handling of being offline (see this issue as example)

Authentication

Use this label to list them all.

Profile Picutures

• https://github.com/gitbutlerapp/gitbutler/issues/2589
• https://github.com/gitbutlerapp/gitbutler/issues/3512

Pre-commit hooks

• https://github.com/gitbutlerapp/gitbutler/issues/2551
• https://github.com/gitbutlerapp/gitbutler/issues/2551

[darleybarreto]

Hey Sebastian,

Thanks for this! I was planning on doing this discovery later this week, because I'm off due to Carnival. I actually opened a discussion in the repo.

[Byron]

Thanks for kicking this off and for pointing to the original discussion! It helped me to understand what's going on as I was a little confused - now I see that a migration is happening to the -git crate and all makes sense.

I was pretty quick in creating this issue and I welcome you to double-check, or ask for clarification where you see fit or need. This can only make it better.

[krlvi]

Thank you @Byron for this! It was such a treat meeting you, and I am so excited about oxidising GitButler :) I fully agree about the general principles that you outlined, it's very much how we like to approach problems too.

[Qix-]

add ODB alternates

While this is something Gitoxide should of course support, we're actually moving away from needing this long-term.

on Windows, there is no native ssh transport yet which might be worse than git2 right now.

Check out https://docs.rs/russh - they've been great maintainers and I used to use this crate for testing SSH stuff locally. Might work as a native transport. It's a maintained, spruced up version of Pijul's thrussh.

[Byron]

Thanks for the suggestions! I have just linked the gitoxide native #1246 issue, and believe that also lists russh as very strong candidate.