go-git VS sapling

I interpret "aims to be fully compatible" as meaning the operations it implements are intended to be compatible with how Git implements those operations. I do not interpret this statement as saying they implement all features of Git.

They offer a document which directly shows what is and isn't supported, and it specifically notes quite a few things that aren't supported yet: https://github.com/go-git/go-git/blob/master/COMPATIBILITY.m...

The godoc also says right upfront it "nowadays covers the majority of the plumbing read operations and some of the main write operations, but lacks the main porcelain operations such as merges." - https://pkg.go.dev/github.com/go-git/go-git/v5#pkg-overview

> I'm saying it's not a reasonable choice over just using git directly, and is unlikely to ever be.

OK, that's apparently true for your use-case. But again, what go-git implements is directly useful to a number of very popular projects, as well as literally two thousand less popular ones.

I find the exported functionality to be high quality, at least for my own use-case. I'm not commenting on the code quality. If I need a shed for bikes, and someone is giving out free but ugly bikesheds, I'm thankful. I don't complain about the color of the bikeshed.

The go frameworks has some particular limitations at the moment (merge, rebase https://github.com/go-git/go-git/blob/master/COMPATIBILITY.md) but overall great framework.Used for some go tools..

You can monitor the sha of your config repos main branch with this I expect. https://github.com/go-git/go-git

I'm remaking a package named owl. One of the features of this package is the ability to clone remote repositories. The first time I affront this problem, I solved it using go.Cmd and git command. Is there a way to achieve something similar without importing or using a dependency like go-git. Something like download files via http, ssh or something similar.

I think there are already some Git SDKs out there. For example https://github.com/go-git/go-git

I see that you’re using go-git, which has a problem with worktree.Status being unusably slow—and in a prompt you’ll most certainly need to use it. I know because I tried writing my prompt using go-git, and had it hang on a work repo for a good minute. Eventually bit the bullet and switched to git2go (libgit2 bindings; uses cgo).

I am personally surprised that TFA didn't mention either jj or Sapling [0] given its emphasis on how both Git and svn were both made to be backwards compatible!

[0] https://github.com/facebook/sapling

Lots to digest here! I have been keeping an eye on Pijul so it is cool to see some of its features implemented in jj. Sapling[0], similarly, is a new VCS tool out there which can work with a git repo. It also has anonymous branches, no staging area, supports stacked commits and can track the history of a commit over time. I've been using a similar workflow to the article's author: git with a UI to handle commits of hunks of a file to group related changes. My working branch often has unrelated changes that get tossed from branch to branch as I am able to commit. I haven't figured out where these new tools fit into my workflow yet, but I am glad there's new options that will help making working on a project more flexible and organized.

[0]: https://sapling-scm.com

yep both extended it and have versions that can work against GitHub/git servers.

sapling scm from meta has I think the best cli and VS code UX https://sapling-scm.com/

jj from google is also mercurial derived with very similar cli features like histedit and has support for deferring conflict resolution https://github.com/martinvonz/jj