I have this. It's called cp(1).
Granted, you can shoot yourself in the foot with cp(1), but not nearly as much as git(1) lets you.
Git Undo
171–175 of 175 posts
Re: Git Undo
#172I freely admit to being an Hg fan, but that this stuff is accepted as common practice kinda blows my mind. What's so wrong with keeping an accurate picture of history that people do all kinds of manipulation to their history to keep from the VCS system from accurately reflecting history of development?
It's the same reason that history books aren't a bunch of primary sources stapled together.
What more better than painstakingly accurate history is useful history. I don't care that Joe was distracted one day and had to make a fix-up commit. I care that he authored a certain change.
Re: Git Undo
#173Earlier quoted context omitted.
Opinions differ on this matter because of different concepts of what 'history' is appropriate to maintain. At one extreme, you could keep track of all your keystrokes in the editor so that you could have a full history of your work including backspaces to correct typos. On the other extreme is the mythical programmer who crafts perfect commits in exactly the correct order on the first attempt. Most mortal programmers…
My two main arguments for "cleaned up history" are 1) Reviews are much more enjoyable when the commits reflect the final understanding of the problem rather than false starts etc. 2) Looking back through history is much more enjoyable when the commits reflect the final understanding of the problem rather than false starts etc.
couldn't there be an immutable approach to this, a folded view of history. Mark commits of value, hide the iteration ones. The log reflects the folded history first; if needed you can unwrap for full details.
Re: Git Undo
#174Earlier quoted context omitted.
You can't change the commit message of a commit without changing the commit, which in most cases is a bad idea, if you don't know pretty much exactly what your doing. Replacing one heuristic with another won't make this a stable operation. A lot of people had already the idea to encode relevant information inside of documentation and it was always a bad idea in the long run.
I get that, I just wondered whether it's technically possible (with supported git operations, not hacking down at FS / byte level).
well, there is git-notes(1), but I'm not sure how it can be used as a journal for reflog operations.
Re: Git Undo
#175I freely admit to being an Hg fan, but that this stuff is accepted as common practice kinda blows my mind. What's so wrong with keeping an accurate picture of history that people do all kinds of manipulation to their history to keep from the VCS system from accurately reflecting history of development?
I'm also coming from Hg, and this picture [1] sums up the problem. The history tree in our company is way more messy - basically over 1/3 of all commits are just merges.
[1] https://twitter.com/michaelhenke/status/585142133167751169