Bit – A modernized Git CLI written in Go
github.com
github.com
This thing has the advantage that you don't need to know the current time and subtract the timestamp from it to see it is 2h old.
For a lot of other stuff it doesn't make any sense at all. E.g. when you have a lot of things all with "2 hours ago" the precision is too low, when you are more interested in the time of day something was happening etc.
Sure, if you're looking for a specific timestamp or something that happened 2 months ago, it's not useful and then I switch to the timestamp format.
Majority of the time I care about stuff like what happened today, yesterday just to get the rough idea.
"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.
I personally take longer to parse an ISO formatted timestamp when all I want to know is age (i.e. difference from now). An "x [unit] ago" is much faster for me.
The absolute timestamp is probably more handy when I have other dates to compare it to, because I could line them up vertically and visually diff the digits.
I think it boils down to the fact that I don't have enough working memory to precisely memorize all numbers in a complete timestamp.
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.
That alone hints you're either working in the UK or you're confusing GMT with UTC, or both.
Greenwich is a borough in East London, there is an old museum with the line on the ground that defined the meridian. You can visit if you come across London.
GMT, namely Greenwich Meridian Time is not actually the time of the meridian of Greenwich for half of the year. When you find yourself working with GMT, you really need to think about how you got there because it's wrong. 90% of the time you meant to use UTC and the other 10% you meant Europe/London timezone.
The time at the greenwich meridian = not GMT
See the problem here? I know it sounds like a bad pun but it's a real problem that every developer in the UK struggled with. To make thing worse, Greenwich the location is right next to the financial district of London where thousands of developers make financial software that are one hour wrong.
I lived in Greenwich, I don't remember entering a new space-time continuum when getting off the DLR at Cutty Sark. You know, compasses spinning eratically, GPS going haywire, cuckoo clocks spinning out of control, because the bubble around the Greenwich Meridian transcends the mortal plane.
GMT is the timezone we have between the end of October and the end of March. Between the end of March and the end of October, it shifts an hour ahead and becomes BST, or GMT/UTC+1.
Greenwich is also South East London, not East London, as it is south of the Thames.
That's all I am saying. You don't have to resort to name calling.
Nobody but you seems to care about what time it is in Greenwich, including, it seems, other people who've lived in Greenwich. So GMT is fine.
It's the "Mean Solar Time[1]" at the Royal Observatory in Greenwich, London, not the legal time observed there.
The legal time switches back and forth between GMT and BST, but the mean solar time doesn't.
[1] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time
I suspect you are the one who is confused: the UK is on BST in the summer, and GMT in the winter. GMT is identical to UTC to the nearest second. GMT is not defined as "the current time in Greenwich", and I suspect your confusion is because you think it's "Greenwich Meridian Time". It's actually "Greenwich Mean Time".
The maritime museum at Greenwich is pretty cool though, as is the old observatory. You can see Harrison's clocks there.
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.
Regarding unmaintained projects, usually my next step is to check recent PRs list or Network Graph page to see if there is some more active fork.
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.
Sometimes a library can just be done.
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 my local timezone!
> imhoguy 6 hours ago | parent
but nothing happened :P
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.
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.
"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".
The problem also exists on HN. For example, in a discussion you might want to check who said something first. But if both comments say "3 days ago", then that's kinda difficult (unless you want to wait until one of them flips to 4 days ago).
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 doesn't match my attitude towards git at all.
Which is a shame, because the autocomplete stuff looks really nice.
Luckily bit doesn’t do anything that would prevent someone from using git on the same repo. You can co-exist.
I’ll make this prediction based on decades of observations:
1. There will be many projects like this.
2. Eventually one will win out and the others will fade.
3. The winner will be the one that focused on a particular audience AND successfully ignored so-called experts that didn’t see the need for such a project.
4. After one tool wins out, the nay-sayers start to adopt it. Forums like HN get flooded with posts about how “I wish I had tried it sooner”.
But seriously... if you don’t need this kind of tool do the other 98% of the world develop it in peace.
* 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.
If sync does pull and rebase then that’s very nice.
`git pull` does that fine for me. (`pull.rebase true` in git config)
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.
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.
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.
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.
Reviewing such a chunk in Gerrit is a PITA. It breaks up the flow of discussion and encourages a myopic perspective on the work.
Most of them would benefit from learning to actually use it, but this is unfortunately niche.
SVN is much better in these regards.
The most popular git questions on stackoverflow tells a story on which tasks are more complex on git because you have to know all the internal tricks.
Having used most SCM since RCS days, I get to differ, but since I am left without another option, so just like with C and JavaScript, I suck it up and get the job done by whatever means.
- rant mode off
Thanks for bringing a bit more of security into the IT world with a Go version though.
Just like a castle with a water pit can still be conquered, but it takes a bit more effort for achieving it.
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 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.
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.
It sounds like we agree that blindly downloading code and building/executing it is a bad idea. That's all I was trying to assert.
There's a spectrum of safe/acceptable between "download a random binary" and "build yourself, from trusted source". I think "curl | sh" and "git clone && make" are just one step above "download a random binary" on that spectrum. We can and should do better than that.
It includes Go and sounds like Git.
Super cool and thanks for this! I commented a few weeks ago on how it'd be nice to have a git CLI that actually helps you find the command you're looking for because you don't really know what to search for unless you know what command to use with git. It's sort of this chicken-and-egg problem that this seems to help solve.
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.
Autocomplete popovers / CLUIs seem like a really natural way to enhance discoverability in the terminal.
I could run gnome terminal but then I have to configure X11 and that’s a pain.
Thanks, this looks awesome.
Still not sure how much of a niche WSL is, but it’s my daily driver.
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.
[1]: https://www.mercurial-scm.org/repo/hg/log?rev=keyword%28%27g... [2]: https://www.mercurial-scm.org/wiki/GitExtension
i made a typo and i can't backspace to delete it.
What does this mean? Especially for a git client?