Hacker News Reader

Isn't that what feature or topic branches are for? Commit in your own little world, merge when you are ready to share.

But a lot of teams prefer that you do rebases and have a flat commit history, rather than have merge commits (so your commits would reflect the time of rebase onto master, not the time you first committed to your topic branch).

I still think this a very cool back-of-the-envelope estimate though.

> (so your commits would reflect the time of rebase onto master, not the time you first committed to your topic branch)

That's not the case with git. By default it preserves the original commit time.

I think they may be talking about squashing several commits before rebasing, creating new commit(s).

Yes, this is what I meant. It wasn't clear, thanks. Generally squashing all the feature commits in a branch into 1 atomic commit in master.

It just calls it author date (it records one commit date and one author date), and one of those is preserved by rebasing. :)

Yes, that is what feature branches are for. The policy I’m talking about is referring to when people share, not when they commit to a feature branch. Sorry, I did initially described it only as “commit”, so that was my fault, not yours.

Reply on news.ycombinator.com