Bit – A modernized Git CLI written in Go(github.com)
github.com
Bit – A modernized Git CLI written in Go
https://github.com/chriswalz/bit
130 comments
Anyone have a direct link to the linux x64 binary?
Git is an awesome tool – so awesome that it has a vast plethora of options and commands to do just about anything. Bit attempts to alleviate some of that pain.
Thanks for making such a cool tool. Does it intergrate anything like gitflow ?
Thanks! Right now it has no special configuration or setup as I want it to be as easy to install as possible (simply run a curl command or go command). Perhaps down the road it will – totally depends on what direction bit will go based on feedback from users :)
And all of those commands have an incompatible syntax.
SVN is much better in these regards.
SVN is much better in these regards.
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 because you have to know all the internal tricks.
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.
I just personally use BFG to scrub files from history https://rtyley.github.io/bfg-repo-cleaner/
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!
- rant mode on
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.
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.
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.
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.
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 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
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
First: I apologize for not reading your original post closely enough. I agree that "curl | sh" is no worse than "git clone && make"; I think both are terrible. I will say that I can't recall ever seeing anyone recommend "git clone && make".
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 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.
Memory safety?
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.
Just like a castle with a water pit can still be conquered, but it takes a bit more effort for achieving it.
I do not care about memory safety only, I would be pissed if it removed my files, for example. :D Security is too broad a term anyways, hence this thread.
Depends entirely on threat model. More code is more surface area for vulnerabilities to be found.
Got would have been a better name.
It includes Go and sounds like Git.
It includes Go and sounds like Git.
There is already a git compatible VCS called got, it is developed from some OpenBSD pople.
https://gameoftrees.org/
https://gameoftrees.org/
Next up for anyone willing to take the bite: Build a unified for CLI for Mercurial and Git. It's a challenge but it's worth it :)
Bit, bite? I see what you did there
Atlassian tried to do the GUI version of this with SourceTree. Unfortunately mercurial performance was terrible!
There is one (though incomplete)! And it's called Mercurial. Since 5.4 released earlier this year, Mercurial is slowly gaining [1] the ability to operate on local Git repositories with its bundled git extension [2].
[1]: https://www.mercurial-scm.org/repo/hg/log?rev=keyword%28%27g... [2]: https://www.mercurial-scm.org/wiki/GitExtension
[1]: https://www.mercurial-scm.org/repo/hg/log?rev=keyword%28%27g... [2]: https://www.mercurial-scm.org/wiki/GitExtension
There’s also even the option of using hg as a git client since forever, though iirc the extension broke somewhat regularly (though I was using it on OS X which may not have helped).
It’s not mentioned in the README, but is WSL2 on the Windows Terminal app supported?
I could run gnome terminal but then I have to configure X11 and that’s a pain.
Thanks, this looks awesome.
I could run gnome terminal but then I have to configure X11 and that’s a pain.
Thanks, this looks awesome.
I'm not sure. I encourage you to try it out. If it ends up not working please file an issue and we'll get it sorted out.
Will do, I’ll give it a shot sometime this week and report back.
Still not sure how much of a niche WSL is, but it’s my daily driver.
Still not sure how much of a niche WSL is, but it’s my daily driver.
WSL2 is barely esoteric at all, especially because it's hard to find anything that works in your chosen linux distro that doesn't work in it (except GUI has to be set up separately). WSL1 that's a bit more hit-and-miss, anything not quite low-level should be fine though.
While WSL1 had a bunch of compatibility caveats, WSL2 is just a VM. It's generally safe to assume that everything is compatible until evidence surfaces otherwise.
It should be, there's a Linux and a Windows release at https://github.com/chriswalz/bit/releases - you could just run it natively without WSL though?
Incidentally, I've actually found it much less painful to use urvxt through VcXsrv for WSL than anything else. The config at that point is just identical to my linux boxes but it interacts with windows in normal, sane ways and X11 programs generally run just fine
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.
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.
try typing `bit` and press <enter> or `bit checkout` <enter>
That sorted it, thanks. Perhaps a word in the README? The impressive gif makes it seem as if it should just appear.
try using bash, maybe zsh autocompletion interfering with it?
Same outcome, but using enter works. It's possible I've done something to both bash and zsh, I like to tinker :)
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 <enter> is the right trigger.
> https://news.ycombinator.com/item?id=24173238
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.
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.
I love the initiative, however the autocomplete popup doesn't work so well.
i made a typo and i can't backspace to delete it.
i made a typo and i can't backspace to delete it.
Please file an issue . This is OS/Terminal/Shell specific
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 to me trying to calculate the actual date from it because that just works for me, being used to it. Same with e.g. Thunar: to me it's maddening that it defaults to displaying 'today/sunday/saturday' and then mixes that with plain dates for timestamps older than a week (or so). Can be me, but this is just so confusing and harder to parse?
Depends, for some things (e.g. the timestamp of a blog post) it just doesn't need to be precise.
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.
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.
It does depend on the context but I mostly use the '2 hours ago notation'.
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.
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.
It's timezone independent... I think it makes sense when hour time scales make sense. For days/week dates work just fine
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 infuriating. This is the kind of thing that should just always be a setting.
[deleted]
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.
"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.
I think of it as a tangent because for the people I pointed to it's not a preference. It's not "easier" but rather, there is no other option but absolute directions.
On another tangent, there are some fields which use relative date almost exclusively, like Ma used in paleontology and geology - https://en.wikipedia.org/wiki/Year#SI_prefix_multipliers and https://en.wikipedia.org/wiki/Myr . And "BP" is used in archeology and some other fields as a date before 1950 - https://en.wikipedia.org/wiki/Before_Present .
On another tangent, there are some fields which use relative date almost exclusively, like Ma used in paleontology and geology - https://en.wikipedia.org/wiki/Year#SI_prefix_multipliers and https://en.wikipedia.org/wiki/Myr . And "BP" is used in archeology and some other fields as a date before 1950 - https://en.wikipedia.org/wiki/Before_Present .
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).
It depends whether you want to see age or point in time, a.k.a do you want to compare it to now or to some other specific time.
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.
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.
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.
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.
The time displayed by git or other programs could simply be converted to the timezone you feel comfortable with?
This is always such a ball of yarn, but working in a UI where both “absolute” and “relative to the locale of where it happened” are important contextual information, I’ve come to the conclusion that it is actually quite sensible to show both UTC and “local to where the event occurred” time at the same time, every time.
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”.
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.
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]
"GMT"
That alone hints you're either working in the UK or you're confusing GMT with UTC, or both.
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.
GMT stays the same throughout the year. The UK switches to BST for the summer.
https://en.wikipedia.org/wiki/British_Summer_Time
https://en.wikipedia.org/wiki/British_Summer_Time
Crazy enough your statement is equally right and wrong. There is really a lot of confusion between GMT, BST, UK time and Greenwich time. ^^
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.
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.
They weren't wrong at all; they were right.
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.
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.
I don't understand why his statement was wrong. GMT does not change according to daylight savings time as far as I know?
GMT = Greenwich Meridian Time
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.
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 have to say that the level of confidence you have while being so misinformed is rather comical.
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.
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.
See, you agree that Greenwich is not under GMT time half of the year.
That's all I am saying. You don't have to resort to name calling.
That's all I am saying. You don't have to resort to name calling.
GMT = Greenwich Mean Time, not Meridian Time.
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
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 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.
It's pain in the ass when you troubleshoot CI problems as well. Was the issue before or after this particular commit? Can't tell, have to check in some other tool.
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 timestamps would be quicker to scan.
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.
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.
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.
Sometimes a library can just be done.
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.
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.
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 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 my local timezone!
Just hover over "...ago" to get a full date.
I hovered my finger over my tablet screen but nothing happened...
I just hovered over the "6 hours ago" in
> imhoguy 6 hours ago | parent
but nothing happened :P
> imhoguy 6 hours ago | parent
but nothing happened :P
HN for one does not support that. :/
> 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.
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.
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.
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.
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".
"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".
I hate it. “17 days ago” - yeah, thanks, now let me manually figure out _when_ that was. I can see how some folks would like “30 minutes ago” but why not give both (a timestamp and relative offset)?
It's especially frustrating when you need to compare two timestamps.
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).
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).
Pro-tip: If you go to https://hn.algolia.com/ and search for the comments there, you should be able to see their exact timestamps.
I've never had a problem with HN's relative time. Exact ordering and times of events don't matter to me for comments on HN - their order is not relatively important aside from parent-child relationships. Times do matter when I'm debugging a release that made it to prod with a bug or if I'm comparing events that happen in time.
I've updated branch suggestions to now show both relative and absolute times. Cheers!
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.
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.
This is something I’ve been working on!
Autocomplete popovers / CLUIs seem like a really natural way to enhance discoverability in the terminal.
https://github.com/withfig/completion-specs
Autocomplete popovers / CLUIs seem like a really natural way to enhance discoverability in the terminal.
https://github.com/withfig/completion-specs
There are some default completion replacements out there, such as fzf-tab for zsh: https://github.com/Aloxaf/fzf-tab
Take a look at fzf, it’s quite generic
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 doesn't match my attitude towards git at all.
Which is a shame, because the autocomplete stuff looks really nice.
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.
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.
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.
Most people don't really use version control, they just use version control programs because they've been told they're supposed to. They might as well be using rsync.
Most of them would benefit from learning to actually use it, but this is unfortunately niche.
Most of them would benefit from learning to actually use it, but this is unfortunately niche.
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.
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.
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.
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.
If you ever switch from Gitlab to another git host, you’ll lose all that history though. Maybe you’re fine with that, but I wouldn’t be.
Unrelated question but why don't more people use Gerrit instead of Gitlab or Github? To me Gerrit flow makes the most sense.
Speaking only for myself: Because Gerrit's unit of review is a single commit instead of a branch. Commits are units of change, but the unit of work and review is almost always a series of related changes. Just because the changes are individually atomic (testable, cherry-pickable, etc) doesn't mean that I want to review them that way. The typical flow is for an engineer to produce a cluster of inter-related changes that motivate and rationalize each other.
Reviewing such a chunk in Gerrit is a PITA. It breaks up the flow of discussion and encourages a myopic perspective on the work.
Reviewing such a chunk in Gerrit is a PITA. It breaks up the flow of discussion and encourages a myopic perspective on the work.
Hi, Developer Evangelist at GitLab here.
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.
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.
That's what a bug tracker is for, stories, specs, and lengthy discussion. Commit message can then be "FOO-1234, add tests." Modern tools auto link those.
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.
* 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.
I didn't even get to sync, stopped reading on 'save'.
Thank god you did! I’ve seen too many “make it easier for normal people” projects ruined by trying to appease people that have muscle memory for the old way.
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.
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.
Same here
Cool project! Love the autocomplete feature. Just my 2 cents about the custom commands, hiding the complexity of git commands is not something I'd like personally (not accounting for alias, aliases are cool). In most cases you'd much rather know which exact git command did/does what to debug/fix, so it's better to invest that time learning early on..
There is another alternative called gitgud if you want more of a gui interface.
https://github.com/GitGud-org/GitGud
> Think in the age of the cloud
What does this mean? Especially for a git client?
What does this mean? Especially for a git client?
The code completion thing is amazing. How does bit do it? I want to do that for all sorts of cli utilities I write.
The README mentions go-prompt[0] which is based on python-prompt-toolkit[1]
[0] https://github.com/c-bata/go-prompt
[1] https://github.com/prompt-toolkit/python-prompt-toolkit
[0] https://github.com/c-bata/go-prompt
[1] https://github.com/prompt-toolkit/python-prompt-toolkit
[deleted]
I recommend updating the install instructions to point to the binaries in the Release section, and not bundling the Windows ones in tar.gz.