The last Python-only version of git-branchless is version 0.1.0, and the first Rust-only version is version 0.2.0. I accomplished this by calling between Rust and Python as appropriate at runtime. I wanted a stable end result, rather than to have to deal with occasional bugs after the initial porting process, so I preferred to use an incremental approach and port the project one module at a time.īy incremental, I’m referring to the method of porting modules individually, rather than all at once.
RUST THE METHOD MAP EXISTS BUT CODE
The small amount of code in the project could conceivably have been rewritten all at once, but I figured it would take a long time to iron out all the bugs that way. However, OCaml is similar to Rust (as Rust descends from OCaml), and I had already read a couple of papers on linear types, so the language didn’t surprise me very much. I didn’t have any experience working with a significant amount of Rust code. This was also a case of interoperating between Rust and another programming language. I was working in an OCaml codebase, and implemented one module in Rust for performance reasons. Previous Rust experienceīefore this project, I had a small amount of experience with Rust. The Python codebase was already statically-checked with Mypy and written in an ML style, so it was largely a line-by-line port. I chose Rust because I had some prior experience with it, and I liked the ML-style type system. Python interop, to support an incremental porting approach.Bindings to SQLite, libgit2 (or equivalent).These were the requirements for my choice of language: Instead, I decided to rewrite the project in Rust to address the startup time issue. I considered incorporating a long-running background process into the architecture, but I hate the amount of additional complexity and edge-cases associated with such an approach. The Python interpreter takes tens or hundreds of milliseconds to start up, which degrades performance in the situation where we invoke it many times serially. For example, a rebase of a stack of several commits will trigger several post-commit hooks in sequence. However, some Git operations can result in many Git hook invocations, and therefore Python invocations. For example, when a user makes a commit, it triggers the post-commit hook, which then tells git-branchless to register the commit in its internal database. This is an event that triggers when specific actions occur in the repository. The git-branchless executable can be invoked in one of two ways: Initially, I prototyped a working version of git-branchless using Python. This post details various aspects of the porting process.
I originally wrote it in Python, but later ported it to Rust.
See PR Add ::each_ref and ::each_mut #75490 for the name discussion.I’ve been working on git-branchless, a Git workflow similar to the Mercurial “stacked-diff” workflows used at Google and Facebook. Use the names each_ref and each_mut or change it to something else? Alternatives: each_as_ref/ each_as_mut, as_refs/ as_mut_refs.Stabilization PR ( see instructions on rustc-dev-guide).Adjust documentation ( see instructions on rustc-dev-guide).Change feature names of all methods that are not yet stabilized to something specific.
0 kommentar(er)
