31–40 of 78 posts
There is also Shit, a git implementation in an almost POSIX shell [0]. Not my software. [0]: https://git.sr.ht/~sircmpwn/shit
Earlier quoted context omitted.
FWIW, since Git 2.23 I prefer using "git switch" and "git restore" instead of "git checkout".
This is correct, ‘git restore’ is the way to do this in the current version of git. ‘checkout —-‘ still works, but the ‘help’ text in ‘git status’ now recommends using ‘restore’. Not only is it more semantic, it reduces the complexity of ‘git checkout’ which is a common complaint. Really, It doesn’t make much sense to tack on some random ’--‘ flag on ‘checkout’ for that functionality. ‘restore’ is clear and describes…
It doesn’t since the feature can’t be removed from git checkout for BC reasons.
Earlier quoted context omitted.
Something tells me I wouldn't want to work in whatever team you work with. git blame is extremely useful for knowing when something was added, and what the context was. It is not about "blaming" people for mistakes.
Yea, it strikes me as a poor name. Cheeky perhaps. I once had someone take me aside and ask me if it was rude to use "blame" in github to figure out who touched a specific line. They thought the name implied some sort of finger pointing and fault.
Other VCS have aliases like « annotate » for the operation.
this is cool! but I'm curious to see a git blame implementation.
You mean the most conflict driven and passive aggressive feature in any programming tooling?
It's not meant to be a finger pointing tool but can be used for that.
Earlier quoted context omitted.
This is correct, ‘git restore’ is the way to do this in the current version of git. ‘checkout —-‘ still works, but the ‘help’ text in ‘git status’ now recommends using ‘restore’. Not only is it more semantic, it reduces the complexity of ‘git checkout’ which is a common complaint. Really, It doesn’t make much sense to tack on some random ’--‘ flag on ‘checkout’ for that functionality. ‘restore’ is clear and describes…
> Not only is it more semantic, it reduces the complexity of ‘git checkout’ which is a common complaint. It doesn’t since the feature can’t be removed from git checkout for BC reasons.
Now we can treat git restore like it is a separate thing.
In general I think it's an amazing way of learning, I remember reading the gobyexample.com website and writing the same thing for go assembly: https://davidwong.fr/goasm/add
So, I'm going to put that out there, but I really wish I could read security-sensitive code like this. TLS implementations, cryptographic implementations, etc. It would be really amazing if there was a way for Github to automatically display code like this by extracting comments out. In general I think it's an amazing way of learning, I remember reading the gobyexample.com website and writing the same thing for go as…
Earlier quoted context omitted.
FWIW, since Git 2.23 I prefer using "git switch" and "git restore" instead of "git checkout".
This is correct, ‘git restore’ is the way to do this in the current version of git. ‘checkout —-‘ still works, but the ‘help’ text in ‘git status’ now recommends using ‘restore’. Not only is it more semantic, it reduces the complexity of ‘git checkout’ which is a common complaint. Really, It doesn’t make much sense to tack on some random ’--‘ flag on ‘checkout’ for that functionality. ‘restore’ is clear and describes…
So, I'm going to put that out there, but I really wish I could read security-sensitive code like this. TLS implementations, cryptographic implementations, etc. It would be really amazing if there was a way for Github to automatically display code like this by extracting comments out. In general I think it's an amazing way of learning, I remember reading the gobyexample.com website and writing the same thing for go as…
See http://www.literateprogramming.com/ for more information and examples.
Earlier quoted context omitted.
FWIW, since Git 2.23 I prefer using "git switch" and "git restore" instead of "git checkout".
This is correct, ‘git restore’ is the way to do this in the current version of git. ‘checkout —-‘ still works, but the ‘help’ text in ‘git status’ now recommends using ‘restore’. Not only is it more semantic, it reduces the complexity of ‘git checkout’ which is a common complaint. Really, It doesn’t make much sense to tack on some random ’--‘ flag on ‘checkout’ for that functionality. ‘restore’ is clear and describes…
No, that’s incorrect. `git checkout` is the way to do this in the current version of Git.
The current version of Git allows you to use `git restore`, but the documentation says this about it:
> THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
Until that warning goes away in a future version of Git, `git checkout` is the way to do this.