Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bit – A modernized Git CLI written in Go

github.com

Post reply on HN
Print view View original

51–60 of 132 posts

Re: Bit – A modernized Git CLI written in Go

#51

Post by imhoguy »

bartread wrote: post #43
stinos wrote: 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…

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.

Re: Bit – A modernized Git CLI written in Go

#52

Post by zaro »

OJFord wrote: 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 didn't even get to sync, stopped reading on 'save'.

Re: Bit – A modernized Git CLI written in Go

#53

Post by berkes »

imhoguy wrote: post #42
stinos wrote: 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…

The fact that many people are surprised when they find out that "whoa; 2003, that's like 17 years ago" only pushes this idea.

It probably depends on your goal, though. Whether you want to know "the (relative) age of something", or "the point in time of some event". I think most often the first is the usecase, which is probably why most projects choose that.

Re: Bit – A modernized Git CLI written in Go

#54

Post by agrajag »

stinos wrote: 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…

> personally never understood why one would pick this over date/hour

Providing a timestamp gives you the same information with higher precision _provided you know when now is_. I can tell you what day of the week it is, but not what the day of the month it is. Sometimes day of the week even takes extra cycles.

Relative time tells me the order of magnitude since last update. Was it today (I can assume they have complete context) or yesterday (they probably need a little background to catch up).

Order of magnitude since last update is generally more useful to me than knowing the time since last update.

Re: Bit – A modernized Git CLI written in Go

#55

Post by monadic2 »

oakmad wrote: post #38
stinos wrote: 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 write a lot of incident reports with timestamped logs. I think about these date formats a lot. I don't mind the informal formatting if you can click through to get a precise timestamp (either UTC or with timezone). However, in my experience, this is rare.

Re: Bit – A modernized Git CLI written in Go

#57

Post by papey »

OJFord wrote: 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…

Same here

Re: Bit – A modernized Git CLI written in Go

#58

Post by monadic2 »

pjmlp wrote: post #45
justincormack wrote: post #39

Earlier quoted context omitted.

It doesn’t use libgit2 it shells out to git. So it doesn’t improve security.

It still does, by adding yet another layer, written in a memory safe language. Just like a castle with a water pit can still be conquered, but it takes a bit more effort for achieving it.

Depends entirely on threat model. More code is more surface area for vulnerabilities to be found.

Re: Bit – A modernized Git CLI written in Go

#59

Post by nlitened »

qw wrote: post #50
oakmad wrote: 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.

The time displayed by git or other programs could simply be converted to the timezone you feel comfortable with?

From my experience, implementation of time zone conversions is too often wrong. I work with many time zones, and strongly prefer either GMT+0 or “x hours ago”.

Re: Bit – A modernized Git CLI written in Go

#60

Post by nemetroid »

OJFord wrote: 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 ability to write alternative CLIs on top of Git is often touted as a feature (as well as a defense against criticism of the existing CLI). I'm not terribly excited by save/sync either. But as long as it doesn't have adverse effects, e.g.:

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

Post reply on HN