Hacker News Reader

Comment by milkworsethan | Hacker News Reader

Imo if you were as pedantic about the history you wouldn't be tampering with it.

There's no issue if you haven't pushed to any remotes (origin) yet. I often wish I could amend a few commits back before pushing.

Then do a commit and then use rebase interactive (-i) and squash them together.

That's what I would do, and that's what "git inject" seems to be after.

Mercurial Evolve handles this edit-history debate well. There are draft commits, public commits, and non-publishing servers where people can collaboratively edit commits. This is all encoded into hg itself rather than relying purely on social convention.

https://www.youtube.com/watch?v=4OlDm3akbqg

"history" can be "shared history" or "private history". The part of history that only lives on your computer is more a "patch-set in the making" than actual history.

If a commit is appended to a tree and nobody has checked it out yet, does it really exist?

Even (semi-) public history can be rewritten. At work, I'm working on a bug with several people. We created a "wild repo" that we share. The branches of test commits get rewritten regularly. You just send an e-mail "Heads up; I rewrote the test-branch". If you know what you're doing in git, it's not hard to pick up rewritten branches.

I introduced the convention of preserving the previous version of the branch as "<branch-name>.1", and the previous-previous as "<branch-name>.2" similar to rotating logs.

You obviously don't want to be doing this on a repo with thousands of downstreams. The point is that "private" can have a somewhat larger scope than "just my single local repo".

Reply on news.ycombinator.com