I do not understand how people can live with only a single line for the commit message. For a new feature, I need to provide some details what is added and how it can be used. For a bugfix, a single line is rarely enough to describe the problem, what you changed, and why this change solves the problem.
Writing good commit messages is an essential part of using a version control system with a team. When trying to make the git interface easier, this should not be dumbed down. I would rather expect the tool to provide assistance with the usual format of a short subject and a body for a longer explanation.
Most of them would benefit from learning to actually use it, but this is unfortunately niche.
I often go through list of recent commits and rebase them before sending PRs. That way, I save a bit of time not having to switch contexts with code and commit messages.
I personally like this format more because it lets you both be "dirty" in your branch writing commits for yourself, and not have to use amends/rebasing. I can see how it would be annoying for someone that does all the digging on the terminal through git log and blame, but we all use gitlab instead.
While we do not want you to leave ... :-) ... you'll have great tools to export your data from projects, for example https://docs.gitlab.com/ee/user/project/settings/import_expo...
Another way is to programmatically work with the REST API and export the needed data (https://docs.gitlab.com/ee/api/). This can be needed to specific backup and persistence routines for data compliance too. I personally recommend to use the Python, Ruby, etc. library bindings for easier API requests.
This won't solve the import into another tool, yet it opens a migration possibility with full access via an API.
Reviewing such a chunk in Gerrit is a PITA. It breaks up the flow of discussion and encourages a myopic perspective on the work.
* promotes bad history patterns
* makes it easier to miss when unwanted changes are included
* makes it easy to accidentally push
...I see it as a good thing to have new UI patterns tried out. If nothing else, it can act as a counterpoint to show that the complexity of the Git CLI actually is necessary for some of the flexibility.
EDIT: I see now that "bit save" encourages using single-line commit messages, which to me promotes bad history patterns. That's too bad.
If sync does pull and rebase then that’s very nice.
`git pull` does that fine for me. (`pull.rebase true` in git config)
Luckily bit doesn’t do anything that would prevent someone from using git on the same repo. You can co-exist.
I’ll make this prediction based on decades of observations:
1. There will be many projects like this.
2. Eventually one will win out and the others will fade.
3. The winner will be the one that focused on a particular audience AND successfully ignored so-called experts that didn’t see the need for such a project.
4. After one tool wins out, the nay-sayers start to adopt it. Forums like HN get flooded with posts about how “I wish I had tried it sooner”.
But seriously... if you don’t need this kind of tool do the other 98% of the world develop it in peace.
That's not how I want to work, and it's not how I want other people to work in a repository I'm using. I know 'I don't have to use them then I can just use the git subcommands', but that's not the point, it's a big signal ('90% of the time the above commands will have you covered.') about the motivation/angle/philosophy of the project that doesn't match my attitude towards git at all.
Which is a shame, because the autocomplete stuff looks really nice.