When working in a feature branch, I make some changes to a file and then commit these changes. Later on, I make some additional changes to the same file on the same lines, and I want to squash these changes into the first commit touching the file.
To find out more, check out my Coderwall Pro tip: https://coderwall.com/p/hh-4ea
Zone of Mr. Frosti 
I don’t understand why you would want to do that. The point of issuing a commit is to log the changes since the previous commit while noting why the changes were made. If your first commit didn’t do it then you shouldn’t have made the commit in the first place. If you do have to make changes after that commit, then the new commit message should be providing more information as to why the first commit didn’t work.
LikeLike
A commit does log the changes since a previous commit. I agree that you would never want to alter the history of commits once you have shared your commits with other developers.
In a distributed VCS, you can make local commits without pushing them to remotes. This means you can freely commit in your local branch without having to worry about getting it 100% correct on the first pass. If you make a subsequence change you can just squash it into an existing commit instead of having one commit making a change, only to have a subsequent commit rolling back that change. After you are finished with your changes, you can rebase, then push to remote with no resemblance to the way the commits were initially created.
Commits are information. You want to shape that information to be as easy to understand as possible. Rebasing allows you to squash, edit, split, and rearrange commits to better represent the changes that you have made.
Check out http://mercurial.selenic.com/wiki/HisteditExtension for an extension to Mercurial that replicates this functionality.
LikeLike
Yeah, Hg has a “rebase” built-in now. It is because of the feature present in Git. I just don’t understand why you would want to screw up your history like that. I think it is a silly thing to do. The correct method would be to commit the changes you want to publish. Once it goes in the history, it stays there.
LikeLike
Perhaps the best analogy I can think of is writing an essay. Almost no one would start at the first word, and write in a linear fashion until the last word, then save the file. You are constantly rewording, rearranging sentences, adding new ideas, dropping ideas that no longer fit. Throughout the essay you are saving your progress at certain “checkpoints”. Sometimes you undo or redo changes, and sometimes you completely scrap the direction you took and reload from a saved file. Commits are a lot like that in my opinion. Any state I think I may want to come back to, I commit. Any related set of changes I made I commit.
Committing your changes is a local version control strategy. You have a great tool, you may as well use it for your own sake, even if other developers aren’t seeing those in-between commits.
LikeLike
I like this guy’s argument — http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html
Let’s pretend you want to contribute to SuperAwesomeProject. So you clone it down to your local machine as “SuperAwesomeProject”. Now, you want to make changes and send them back, but you don’t want to muck up the primary commit history. What do you do? Create a branch! Do all of your work, committing as much as you like, in your branch. When you are done, simply merge your branch back into the main one and push your local code base back to the main source.
Don’t lie about your work and commit at sane times. Look back at the pull requests for your in_place_edit plugin. Is that history confusing?
LikeLike
Hello Ben,
Firstly, thank you for the great rebase –autosquash examples – just what I was looking for.
Secondly, I 100% understand & fully agree with what you are trying to explain to James. That is EXACTLY how it should be done, but I guess some people just don’t agree.
Your arguments, & perfect metaphor of writing an essay are entirely valid, & solid points in the case for using git’s advanced rebase tool for a powerful development workflow (obviously provided that those commits have not been pushed to remote / shared with the world).
O_O
LikeLike