HackerTrans
TopNewTrendsCommentsPastAskShowJobs

chaitanya

no profile record

Submissions

Input Metrics vs. Output Metrics

thenorth.io
2 points·by chaitanya·3 anni fa·0 comments

naive-date: a tiny JavaScript lib for Date like objects that aren’t timestamps

github.com
1 points·by chaitanya·4 anni fa·0 comments

The many variations of the return statement in Kotlin

twitter.com
2 points·by chaitanya·4 anni fa·1 comments

India Accidentally Fired Missile into Pakistan

ndtv.com
3 points·by chaitanya·4 anni fa·0 comments

vfork() is still evil

lisper.in
5 points·by chaitanya·4 anni fa·0 comments

JavaScript's Date is just a timestamp

lisper.in
4 points·by chaitanya·4 anni fa·0 comments

[untitled]

1 points·by chaitanya·5 anni fa·0 comments

comments

chaitanya
·4 anni fa·discuss
You can’t, because JavaScript date objects are just timestamps.

Here’s what I wrote on this (along with a small library to handle this problem): https://lisper.in/javascript-date
chaitanya
·4 anni fa·discuss
You can have the best of both worlds -- "commit early, commit often", and "nice clean commit histories" -- with git, and it is easier than most people think.

- So you start work on a new branch, and reach a checkpoint. Create a new commit with "git commit".

- Continue working, and when you reach the next checkpoint, create another commit. But this time, use "git commit --amend". Contrary to what the flag says, this doesn't modify the previous commit, instead it modifies your commit history and replaces the last commit with a new one[1]. So instead of having two new commits in your branch's history, you only have one.

- Repeat the process until you have something worth pushing to the remote.

- Once you've pushed to remote, remember to not make any further modifications to your git history[2] i.e. going forward, create a new commit and only then run "git commit --amend".

Now, there's an obvious question here: if "git commit --amend" keeps replacing the last commit with a new one, what happens when you mess things up and want to revert to NOT the last checkpoint, but some checkpoint before that?

The trick here that git has up its sleeve is called "git reflog". You see, while "git commit --amend" replaces the last commit in your branch's history with a new one, the older commit is not actually gone, its still there. And you can see all of them with "git reflog". Basically "git reflog" returns every commit at which the local HEAD (i.e. the commit checked out in your working directory) has been. So none of the commits that you replaced with --amend are actually lost, and you can find them all in the reflog.

Restoring to an older checkpoint becomes as easy as running "git reset --hard <previous-commit-id>", or if you want to play safe, "git checkout -b <new-branch-name> <previous-commit-id>".

Hope this helps!

Notes:

1. By design, a commit, or in fact most objects in git cannot be modified. They are immutable.

2. Basically you can play with git history as long as it is private to you and not shared with others. But the moment you push it to a remote you share with others it's no longer private and you must not modify that history anymore. Read Linus's note on keeping a clean git history: https://www.mail-archive.com/[email protected]...