Accessing additional rebase metadata

[inferiorhumanorgans]

So there was some back and forth in #382 about this and I'm happy to work on this as it sounds like both myself and @davidkna have similar use cases. However I could use a bit of guidance beforehand.

First thing is, renaming git-rebase to git-sequencer as even within git the sequencer code is shared between cherry-pick, rebase, and revert.

The next part revolves around how the API should be shaped. As git-repository is mostly a higher level wrapper around other crates, what would the functions in git-sequencer accept as input? A Path-like object that points to the .git directory? Or? Likewise, what's the preference for output shape? Most of the metadata in question are relatively simple things like strings or references. At what point would it be appropriate to go from functions per attribute to something returning a "platform" struct?

Lastly, (and this is perhaps more directed at @davidkna) what sort of metadata should be exposed? It's all relatively easy to get at, and should all be listed in sequencer.c. Off the top of my head:

• completed commands – GIT_PATH_FUNC(rebase_path_msgnum, "rebase-merge/msgnum")
• total commands – GIT_PATH_FUNC(rebase_path_msgtotal, "rebase-merge/end")
• commit being edited – GIT_PATH_FUNC(rebase_path_amend, "rebase-merge/amend")
• merge strategy – GIT_PATH_FUNC(rebase_path_strategy, "rebase-merge/strategy")

[Byron]

First thing is, renaming git-rebase to git-sequencer as even within git the sequencer code is shared between cherry-pick, rebase, and revert.

I have created an empty git-sequencer crate for that purpose, and am sure there will be plenty of rebase-specific logic left to go into the git-rebase crate.

The next part revolves around how the API should be shaped. As git-repository is mostly a higher level wrapper around other crates, what would the functions in git-sequencer accept as input? A Path-like object that points to the .git directory?

It's hard to tell without knowing sequencer.c in detail, which isn't helped by it being a ~4600SLOC behemoth. A git_dir Path would certainly be a starting point. Thus far I managed to avoid binding any plumbing crate to git-odb, the act of finding an object of a particular type is a closure being passed as parameter.

Most of the metadata in question are relatively simple things like strings or references. At what point would it be appropriate to go from functions per attribute to something returning a "platform" struct?

I really don't know, it probably depends on you after understanding sequencer.c and plotting a course through it. Which features are most important to you to support. Where do you want to be when done? With gitoxide crates the only real baseline is that it must at least be as correct (at least in aspiration) as git itself, and shouldn't be slower needlessly. From my experience, as one digs in the code writes itself, and then demands a refactor or two until it finally settles.

I would, however, be part of the journey of tackling this and we learn together as it proceeds.

Once it's clearer what the initial goal is regarding what data to retrieve, everything else can be sketched out in a first draft PR.

Last but not least, let me state that I am excited about seeing this line of work being started.

[davidkna]

What sort of metadata should be exposed?

I was mostly interested in completed/total progress, as there hasn't been any demand for anything beyond that (in starship). Beyond what you've mentioned, that would include rebase-apply/next and rebase-apply/last.
Beyond that, the commit being edited sounds like it could be worth exposing.