You should check out git reflog
if you don't know about it already. It allows you to view the history of commit changes which is very handy if you want to undo an --amend or rebase for example
You should check out git reflog
if you don't know about it already. It allows you to view the history of commit changes which is very handy if you want to undo an --amend or rebase for example
You probably don't have to worry about the compatability of so just use that. The only reasons to not use it is if it's important to only use standard compliant c for whatever reason or if you need to support some arcane compiler that doesn't support
. Realistically, neither of these are situations that you'll ever be put in and if you are you probably have much larger things that you need to worry about.
The first thing I already have problem with [...]
For the record: headers suck. There's a good reason why most programming languages don't use them. They're like a realy primitive version of setting things to public/private in modules, where public things go in the header and private things don't. Modules are a very useful abstraction over this where you don't have to do as much mucking around.
I don't really think it's much of a problem that h
isn't on a touch typing key because you don't need to press h very often. I probably use :
way more than h
. (:
requiring shift isn't ideal though, although that's another can of worms)
I might be suffering from stockholms syndrome here, but my prefered ways of working with git are the cli and the fugitive vim plugin which is a fairly thin wrapper around the cli. It does take a middle ground approach on hiding the magic and forcing you to learn the magic which I suppose can be confusing for beginners when you work collaboratory and something happens that forces you to go beyond pull/add/commit/push
I was curious about why people would run git push --force on a shared branch. Some reasons people gave were:
- they’re working on a collaborative feature branch, and the feature branch needs to be rebased onto main. The idea here is that you’re just really careful about coordinating the rebase so nothing gets lost.
A safer solution would be to make a new branch and do the rebase on it instead, that way the shared branch won't be impacted. You might still lose changes if they're pushed after merging to main but that's not really rebases fault. You can always cherry pick or something then from the original un-rebased branch (hopefully without any merge issues...)
I'm not in charge of many open source projects but the last one I actually put up on gitlab instead. We use gitlab at internally at work and it's completely fine. I mostly use my github account to interact with repos that other people host on github.
Another accessibility reason for tabs: when using a braille display, each space takes up one character cell, so indenting with four spaces eats up four cells. Indenting three times with four spaces each eats up 12 characters already. Tabs only take one character cell each, so three indents = three character cells used.
The fact that there (I assume?) isn't a braille oriented text editor that can handle space-based indentation in a smarter way is a bit depressing. Maybe the solution should be better tools based around accessibility rather than convincing everyone to switch to tabs, which is a project that will just never succeed.
To me the main advantage would be that it makes regexes more readable, not more writable. Integrating melody in to a project seems like it would add more indirection which would make it more inconvenient to read. Feels like this would be more useful as a rust proc macro for example so that you can actually have it alongside your code in a convenient way rather than have it compile to ES6 regexes.
On many terminal emulators you can also use Alt-. to search through your history of previous arguments, so mkdir foo
followed by cd [Alt-.]
will populate your command line with cd foo
for example. If you have some other command in between you can just hit Alt-. repeatedly
Honestly I do think java is kinda bad, but that doesn't really matter that much if you're not developing in it. Haven't looked through the thread but it sounds like people are just being armchair elitists. I would prefer not to code in java but when I'm just using software there are a lot of things that are more important than what language is written in.