User-configurable branch names

[jonathanloske]

Branch names are useful for identifying features that are part of the branch. It would be nice if maiao could give the user some leeway over their naming.

Current behavior
Branch names are auto-generated without any way of configuration. The resulting names contain the prefix maiao. and then a (seemingly) random assortment of characters like maiao.Ia53828902fbe392126f1ee6cfd595d24a2b425f0.

Desired behavior
The prefix of the message is configurable via CLI option

Bonus: Create ascending numbers with the given prefix, ie prefix ASD-123-introduce-header, resulting branches: ASD-123-introduce-header-1, ASD-123-introduce-header-2, etc.

[joaoqalves]

Hi Jonathan! Thanks for raising this issue.

Branch names are useful for identifying features that are part of the branch. It would be nice if maiao could give the user some leeway over their naming.

I want a bit more context here. What would be different, from your perspective, if that was possible? Currently, you can also do something like this:

git checkout -b my-feature
# Changes
git-review

This will create a message in the Pull Request with the following:

Commiter details

Local-Branch: my-feature

Another alternative would be to use topics that relate to a change, with:

git-review -t my-feature

This would result in linked PRs to a topic, with a message similar to this one.

Would any of these suit your workflow?

Current behavior
Branch names are auto-generated without any way of configuration. The resulting names contain the prefix maiao. and then a (seemingly) random assortment of characters like maiao.Ia53828902fbe392126f1ee6cfd595d24a2b425f0.

The terminology is not random. Ia53828902fbe392126f1ee6cfd595d24a2b425f0, in the example you mentioned, is the Change-Id associated with the change set (or Pull Request, in Github's jargon).

I'd need some help from @tjamet here, but I think these IDs are necessary to understand what to ensure that one change set has only one PR open.

[jonathanloske]

Topics are a great starting point, would try out those!

[tjamet]

@joaoqalves the change-id is indeed generated as a sha of the intended changes (see it as a partial commit sha).

It is a git hash including remarkably the initial parent commit sha, the changes to be committed, the author, and the original commit message.

It is used to identify the original intention to change, before any code review.
It is added to the commit message so it is kept over time and rebases.

While the commit SHA handles a very similar need, there is no way to identify an earlier version of a commit. the commit SHA changes every time you rebase it or amend it (either by changing the commit message or changing the files).
By storing the ID in the commit message when absent, the Change-ID ensures that you can link all the versions' evolution of a given change intent, regardless of whether it has been amended or rebased.

Maiao aims at providing a developer experience similar to what Gerrit can provide but on top of GitHub and all its ecosystem of bots and actions.
This means that it relies exclusively on commits (mapped to PRs) and uses branches only as an implementation detail to be able to use github.
This is the reason why the branch name is not customizable.

As you mentioned @joaoqalves, topics are here to serve a very similar purpose and should work across multiple repositories.

This said, we could indeed backport the gerrit's git-review behaviour where, by default, the topic is the name of the local branch.