Could some more detailed examples of submit usage be provided?

[maxhaton]

Let's suppose I have a stack of commits, and I'd like to push them to a (self-hosted) gitlab, what should -F branch actually do? It doesn't seem to want to push anything because the upstream branch doesn't exist yet (e.g. I branched off to make a stack, incorrect?)

"Ideally" (I don't like gitlab, but this'll help) it could push them as separate ephemeral branches of some kind that I can twine together with MRs. Is such a thing possible?

[arxanas]

• Unfortunately, there is currently no specific integration with Gitlab.
• You're correct that nothing will be created unless you pass --create. This doesn't automatically create any MRs.
• There are a few instances on this discussion board (search for "gitlab") where people have posted their custom scripts to create the MRs.
  • In Gitlab, this is actually quite easy. You just need to set push options as part of git push: https://docs.gitlab.com/ee/user/project/push_options.html
• You could add support for Gitlab to git-branchless-submit yourself! There are examples for Phabricator and Github.
  • It might be possible to do everything with push options and never touch the Gitlab API directly?
  • Note: make sure to test and handle the case of reordering commits in a stack.
    • Normally, it suffices to visit/push commits in topological order. The current bottom-most commit has no dependencies, so you can safely push it and set its dependencies (to the empty set).
    • However, the forge itself may cause you problems. IIRC Github will automatically close a PR if it looks like its base branch has all its commits. If you reorder two commits without updating the base branch metadata, you can enter a brief state where it looks like one PR subsumes the other, and it gets auto-closed. So you need to set dependencies for each individual commit as you go, not do all the pushes first and all the dependencies second. (Shouldn't be a problem if using Gitlab push options?)
  • Note: beware the partial merge problem: if you merge some of the bottom-most commits, then git submit the remaining commits, you may lose the dependency information for the newest bottom-most unmerged commit, as it now appears to be directly based on the main branch.
    • This isn't incorrect, it's just really annoying in the forge UI because it's useful for historical reasons to know what the full stack was.
    • None of the forges at present address this. It might be possible to factor the forge interface better and somehow centralize the logic in the calling code.
    • To fix properly, I think this requires some kind of persistent state for each commit (or forge-side code review object) to check what its historical dependencies were.

[maxhaton]

I actually went away and wrote some scripts using the push options (have already used these for too long at this point). Already a massive time saver (gitlab seems to be ideal for teams who want to spend time waiting rather than coding, I digress).

Thus far (i.e. mostly linear stacks) the most annoying thing by far has been how slow gitlab merges can be, although I haven't had to any particular dramatic changes in response to review - the UI has mostly been fine just with the correct target branch, it changes to master when said target is no longer interesting.

[maxhaton]

The reordering I suspect may be pain; I don't really have a clear picture of how to do this just yet although its possible that simply force pushing where appropriate (and rm when not) might actually go a very long way (e.g. currently the MRs get their metadata from the commits, there isn't actually that much to update).

Wrt to persistent state we had some internal chatter about using git notes for this kind of thing, with enough contortion I suspect its actually pretty possible to make them stick ('git post-it'?) properly, but the foreign aspect could be a disaster.

In line with the latter point I'd be completely fine with shoving information in the commit message itself - its not exactly pretty but it works without much thought (other than the distributed systems aspects - to have identity, how shall we agree? - which while interesting also don't matter that much). Phabricator could be slightly annoying here in that (AFAICT / for us) the differential number didn't always make it into the commit message so getting a proper slug from a commit could be a bit of a pain.

[maxhaton]

Wrt to me contributing: Happy to (/ have a chat also?)

I think it might be prudent to nail down the semantics, implement them in our tool, then work out how to make submit give enough info to said tool, then upstream specifics (the API surface area used won't be very extensive but sufficiently large to make wrong turns expensive for a tool that isn't specifically for gitlab - let alone a non-self hosted gitlab)

[arxanas]

For the first version, think it would be fine to just implement something that doesn't store any extra metadata for now (and is annoying for some cases of landing stacks), without much extra design work. I'm guessing it would be simple to translate/migrate an existing script into git-branchless-submit by following the other forge code examples.

[claytonrcarter]

I have had idle day dreams of a mechanism by which we could a. have a GitLab forge (I agree that push args look promising) and b. read the MR data from a file, similar to how we use a lightly structured file with reword. So, an input file like this:

++ branch feature-a
# ... MR Title ...

... MR description ...

++ branch feature-b
# ... MR Title ...

... MR description ...

Could then be used by the SubmitForge to correlate the MR title/description to a particular branch, and then those values could up sent via push args.