Live data from Hacker News

Bit – A modernized Git CLI written in Go

github.com

71–80 of 132 posts

Re: Bit – A modernized Git CLI written in Go

#71

The autocomplete popups are really cool. Does anyone know if there's a generic way to provide this for all tools with CLI's with help text? What about being able to parse a Programmable Completion file. I don't know much about this stuff, but the thought popped into my mind.

Take a look at fzf, it’s quite generic

Re: Bit – A modernized Git CLI written in Go

#72
post #63
post #34

Earlier quoted context omitted.

I agree: to me this is like a car giving you driving directions by saying "turn north" instead of "turn left"; there are people who legitimately find either way to be easier, and if you give them the wrong way they are just going to have to convert it... I find absolutely dates and times to be super intuitive, and I have most of my life laid out in my head with absolute dates, and find relative dates and times to be…

Isn't your analogy flipped the other way around? "North" is technically correct but an absolute reference, just like a date. While "Left" is relative just like "two hours ago" With the relative reference you don't need to know which direction you are heading, or what time it is right now.

On a tangent, https://en.wikipedia.org/wiki/Guugu_Yimithirr_language "The language is notable for its use of pure geographic directions (north, south, east, west) rather than egocentric directions (left, right, forward, backward),[7] though such "purity" is disputed.[8] Still, it has given its speakers a remarkable sense of direction."

Re: Bit – A modernized Git CLI written in Go

#75
post #69
post #48

I really liked the look of this, until I got to `save`/`sync` in the readme... 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…

The save command also accepts the commit message on command line only instead of opening an editor. 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 com…

I started to write longer format commit messages, and it was such a pleasure to do so and I can see that others appreciate them too, in core reviews and PRs. I also like the easy grepping capabilities.

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.

Re: Bit – A modernized Git CLI written in Go

#76
post #70

Earlier quoted context omitted.

"GMT" That alone hints you're either working in the UK or you're confusing GMT with UTC, or both.

Or, nobody cares about fractions of a second when organising a meeting, so to all intents and purposes they are the same.

Point being, they are not the same. There is one hour difference between UK Time, GMT and UTC for half of the year, due to daylight saving time.

Re: Bit – A modernized Git CLI written in Go

#77
post #68

The autocomplete/help popups didn't happen for me, is there something I need to do? I'm using zsh on a Mac, perhaps it assumes bash. Aside from that, I'm going to persist with this for a little while and see how it goes, the git interface does bother me.

I don't see autocomplete popups either - Fish on iTerm2 here. First thing I did was type `bit` and hit tab and I got a Go traceback - `panic: COMP_POINT env should be integer`

Sounds like one for the issue list! You've probably seen it but chriswalz replied below and is the right trigger.

Re: Bit – A modernized Git CLI written in Go

#78
post #26

Earlier quoted context omitted.

Yes! A git cli with a good syntax which is the same for every command would be useful. It would not have to do every nifty git feature, just uses a senseful subset: git push/bull branching/merging/rebasing and add some nifty common problems like delete file from history, remove last x commits already pushed etc. The most popular git questions on stackoverflow tells a story on which tasks are more complex on git becau…

https://github.com/tj/git-extras/blob/master/Commands.md does it pretty well. Everything you've listed is covered there I think.

Thanks, this is really awesome!

Re: Bit – A modernized Git CLI written in Go

#79
post #70

Earlier quoted context omitted.

Or, nobody cares about fractions of a second when organising a meeting, so to all intents and purposes they are the same.

Point being, they are not the same. There is one hour difference between UK Time, GMT and UTC for half of the year, due to daylight saving time.

GMT stays the same throughout the year. The UK switches to BST for the summer.

https://en.wikipedia.org/wiki/British_Summer_Time

Re: Bit – A modernized Git CLI written in Go

#80
post #69
post #48

I really liked the look of this, until I got to `save`/`sync` in the readme... 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…

The save command also accepts the commit message on command line only instead of opening an editor. 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 com…

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.

Post reply on HN