Live data from Hacker News

Bit – A modernized Git CLI written in Go

github.com

101–110 of 132 posts

Re: Bit – A modernized Git CLI written in Go

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

Unless you have half a dozen commits from 2 hours ago, which is pretty common in active repositories. It's never been very hard for me to tell whether a time stamp was a month ago, a day ago, or a few minutes ago, but it's impossible to figure out the roughly what time the commit from "1 day ago" was.

Re: Bit – A modernized Git CLI written in Go

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

It was a demonstration of the premise of relative vs. absolute, not an attempt to argue that one is somehow more obvious and should be considered better to everyone (which I disagree with).

Re: Bit – A modernized Git CLI written in Go

#103
post #42
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…

Honestly, when I enter a project page I glance these to quickly evaluate how active the development is. E.g. for Ruby library when I see "9 years ago" everywhere then likely the code needs some work to get it working with the latest Ruby version. But when there is just one "2 months ago" on `lib` directory it tells me somebody came back here to maintain the things. I am not sure if list of accurately formated timesta…

That's one thing I really like about Common Lisp: a project can be untouched for over a decade and still work perfectly with the very latest versions of SBCL/LispWorks/Allegro/CLISP/whatever.

Sometimes a library can just be done.

Re: Bit – A modernized Git CLI written in Go

#104
post #72
post #63

Earlier quoted context omitted.

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

This isn't actually a tangent, and is a reason I knew there were people who prefer absolute direction.

Re: Bit – A modernized Git CLI written in Go

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

What bugs me with this is the resolution that is usually truncated.

"2 hours ago" might be fine enough. 2 days ago (instead of a longer "2 days 3 hours ago") maybe not, especially when I quickly want to see what's freshest or oldest and everything just says "2 days ago".

Re: Bit – A modernized Git CLI written in Go

#108
post #51

Earlier quoted context omitted.

Agree. Timezone issues aside (which this does simplify), I'd like to see both "N hours ago", plus the actual date and time it happened (in my local timezone). With hours it's not so bad, but gets worse with longer time periods. I find it incredibly aggravating when services say "N days ago", or "N weeks ago", because this simply serves to obscure when an event actually occurred. Just give me the damn date and time in…

Just hover over "...ago" to get a full date.

I just hovered over the "6 hours ago" in

> imhoguy 6 hours ago | parent

but nothing happened :P

Re: Bit – A modernized Git CLI written in Go

#109
post #82

Earlier quoted context omitted.

Why would a different CLI (presumably still using libgit2) improve security? Especially if it's installed like this: curl -sf https://gobinaries.com/chriswalz/bit | sh;

> Especially if it's installed like this: curl -sf https://gobinaries.com/chriswalz/bit | sh What's wrong with this? It's no worse than git clone && make or any of the other hundred incantations of executing code from the web.

It's much worse. At least with `git clone` you can verify that the code you're building matches something you trust. You have to trust the code and your make tool. You can inspect the code if you're concerned and validate that it's going to do what it says.

It's true that the vast majority of the time a "curl | sh" works fine and does just what you expect it to do, but that's not really the point. The point is that you have no idea what that script your piping will do. You also have no idea whether in this case the binary it fetches is actually built from the code the service says it is; downloading the script first and inspecting it is a good idea, but still not as good as building directly from the code.

This is why we see people do things like publish a hash sum alongside binaries they offer, or use a digital signature. Then we can at least verify that a binary matches what the author says they released, or better yet ensure that the binary was produced by a trusted source.

Re: Bit – A modernized Git CLI written in Go

#110
post #82

Earlier quoted context omitted.

> Especially if it's installed like this: curl -sf https://gobinaries.com/chriswalz/bit | sh What's wrong with this? It's no worse than git clone && make or any of the other hundred incantations of executing code from the web.

It's much worse. At least with `git clone` you can verify that the code you're building matches something you trust. You have to trust the code and your make tool. You can inspect the code if you're concerned and validate that it's going to do what it says. It's true that the vast majority of the time a "curl | sh" works fine and does just what you expect it to do, but that's not really the point. The point is that y…

> You can inspect the code if you're concerned and validate that it's going to do what it says.

You can just not pipe the curl script to shell and inspect it [0]. Executing that is no worse than executing a random make command or `brew install`

> downloading the script first and inspecting it is a good idea, but still not as good as building directly from the code

No, you need to inspect the code too if you're that worried. I can write a makefile that just does this: build: curl http://example.com -o bad.txt && cat bad.txt

Either you're actually vetting what you run on your machine, or you're not. curl | sh isn't any worse than git clone && make.

> This is why we see people do things like publish a hash sum alongside binaries they offer, or use a digital signature. Then we can at least verify that a binary matches what the author says they released, or better yet ensure that the binary was produced by a trusted source.

So just publish the hash/signature next to "install instructions" that contains the curl command, and let the user verify the hash themselves. Again, that has nothing to do with the install method.

[0] https://pastebin.com/atHcYR8x

Post reply on HN