Live data from Hacker News

Bit – A modernized Git CLI written in Go

github.com

61–70 of 132 posts

Re: Bit – A modernized Git CLI written in Go

#61
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…

I don’t quite understand what sync does. Regarding save, I think I don’t want the auto-amend functionality.

If sync does pull and rebase then that’s very nice.

Re: Bit – A modernized Git CLI written in Go

#62
post #47
post #38

Earlier quoted context omitted.

You’ve never worked across time zones have you? I find it’s a lot easier to say “that commit from 2 hours ago” than do the mental math during a code review or debug session. However I do think it should be opt in as I understand your POV and in my experience it’s never an issue until it’s a big one. In our ui we show ago, local and point of origin for all time zones we deal with in a popover.

You’ve never worked across time zones have you? Actually I have, and then we all use GMT when communicating timestamps. But it's like another commenter mentions: yes, 'that commit from 2 hours ago' is still doable (though if it matters we communicate SHAs), but when it goes to 'a day ago' it doesn't really work out anymore.

"GMT"

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

Re: Bit – A modernized Git CLI written in Go

#63
post #34
post #27

Honest question: what's up with the (2 hours ago) notation? I've seen this before in a couple of git-related and other applications but personally never understood why one would pick this over date/hour. Is this a cultural thing? Do some people actually find this better (from the point of conveying timestamp information)? My main problem with it, apart from not having a high resolution, is that it usually just leads…

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.

Re: Bit – A modernized Git CLI written in Go

#64
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…

I don’t quite understand what sync does. Regarding save, I think I don’t want the auto-amend functionality. If sync does pull and rebase then that’s very nice.

> If sync does pull and rebase then that’s very nice.

`git pull` does that fine for me. (`pull.rebase true` in git config)

Re: Bit – A modernized Git CLI written in Go

#65
post #47
post #38

Earlier quoted context omitted.

You’ve never worked across time zones have you? I find it’s a lot easier to say “that commit from 2 hours ago” than do the mental math during a code review or debug session. However I do think it should be opt in as I understand your POV and in my experience it’s never an issue until it’s a big one. In our ui we show ago, local and point of origin for all time zones we deal with in a popover.

You’ve never worked across time zones have you? Actually I have, and then we all use GMT when communicating timestamps. But it's like another commenter mentions: yes, 'that commit from 2 hours ago' is still doable (though if it matters we communicate SHAs), but when it goes to 'a day ago' it doesn't really work out anymore.

[deleted]

Re: Bit – A modernized Git CLI written in Go

#66
post #38
post #27

Honest question: what's up with the (2 hours ago) notation? I've seen this before in a couple of git-related and other applications but personally never understood why one would pick this over date/hour. Is this a cultural thing? Do some people actually find this better (from the point of conveying timestamp information)? My main problem with it, apart from not having a high resolution, is that it usually just leads…

You’ve never worked across time zones have you? I find it’s a lot easier to say “that commit from 2 hours ago” than do the mental math during a code review or debug session. However I do think it should be opt in as I understand your POV and in my experience it’s never an issue until it’s a big one. In our ui we show ago, local and point of origin for all time zones we deal with in a popover.

I work across time zones daily. If I'm using a UI, I expect dates to be displayed in my time zone. If I'm communicating with someone in another time zone, then I'll use relative time. However, in their head, they're still going to be converting that to local time. I don't see why you wouldn't just want to skip the middle man.

Re: Bit – A modernized Git CLI written in Go

#67
post #27

Honest question: what's up with the (2 hours ago) notation? I've seen this before in a couple of git-related and other applications but personally never understood why one would pick this over date/hour. Is this a cultural thing? Do some people actually find this better (from the point of conveying timestamp information)? My main problem with it, apart from not having a high resolution, is that it usually just leads…

Context matters.

If I want to know the age of something, i want "x time ago" to quickly determine age. For many OSS projects this is nice because I can quickly see how active a project is/has been.

Re: Bit – A modernized Git CLI written in Go

#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`

Re: Bit – A modernized Git CLI written in Go

#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 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.

Re: Bit – A modernized Git CLI written in Go

#70
post #47

Earlier quoted context omitted.

You’ve never worked across time zones have you? Actually I have, and then we all use GMT when communicating timestamps. But it's like another commenter mentions: yes, 'that commit from 2 hours ago' is still doable (though if it matters we communicate SHAs), but when it goes to 'a day ago' it doesn't really work out anymore.

"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.
Post reply on HN