Bit – A modernized Git CLI written in Go

Re:Bit – A modernized Git CLI written in Go by kace91 on Monday October 12, 2020 @06:48AM (#24753144)

My team doesn't write long format commit messages and it's never been an issue. When we need to track down changes we use the corresponding mr, which includes a description as well as a link to the relevant cards.

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.

[ Parent | on HN ]

Re:Bit – A modernized Git CLI written in Go by ryukafalz on Monday October 12, 2020 @08:00AM (#24753514)

If you ever switch from Gitlab to another git host, you’ll lose all that history though. Maybe you’re fine with that, but I wouldn’t be.

[ Parent | on HN ]

Re:Bit – A modernized Git CLI written in Go by dnsmichi on Monday October 12, 2020 @08:20AM (#24753651)

Hi, Developer Evangelist at GitLab here.

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.

[ Parent | on HN ]

Re:Bit – A modernized Git CLI written in Go by pdsOne on Monday October 12, 2020 @11:59AM (#24755786)

Unrelated question but why don't more people use Gerrit instead of Gitlab or Github? To me Gerrit flow makes the most sense.

[ Parent | on HN ]

Re:Bit – A modernized Git CLI written in Go by brandmeyer on Monday October 12, 2020 @12:34PM (#24756212)

Speaking only for myself: Because Gerrit's unit of review is a single commit instead of a branch. Commits are units of change, but the unit of work and review is almost always a series of related changes. Just because the changes are individually atomic (testable, cherry-pickable, etc) doesn't mean that I want to review them that way. The typical flow is for an engineer to produce a cluster of inter-related changes that motivate and rationalize each other.

Reviewing such a chunk in Gerrit is a PITA. It breaks up the flow of discussion and encourages a myopic perspective on the work.

[ Parent | on HN ]