Following on my last entry, where I built a better pre-commit hook to ensure every commit in my Git history passed make check with flying colors, I realized something today about my good friend, rebase .
…If I have a set of ten commits, and realize the 3rd commit has an oversight I’d like to smooth out, I can make a new commit to fix the problem and then merge it with that old commit, resulting in a nice, clean set of commits for pushing.
…A rewritten commit is really a new commit , which means it hasn’t been tested, may never have existed as a working tree, and certainly isn’t the same as the previous commit, however similar its diff output may be.
… Thus the only way I could use rebase in confidence would be to run the same pre-commit again on every changed commit during the rebase operation — which is something Git doesn’t do.
Recently a friend turned me onto an interesting article about a problem I had just recently discovered about Git and its pre-commit hook:
> Committing in git with only some changes added to the staging area still results in an “atomic” revision that may never have existed as a working copy and may not work.
This has probably been written countless times before, but I found myself needing it today and it was quick to write. It lets you read characters from a char array in C++ via the istream interface:
… ptrinbuf(char * _ptr, std::size_t _len) : ptr(_ptr), len(_len) {
… ptristream(char * ptr, std::size_t len = 0)
Recent Comments
- Giuseppe Maggiore on A word on Haskell Monads and C++
- stevenm on Diving into Git
- johnw on Life and times of a TCP packet
- marllis on Life and times of a TCP packet
- Rose on Git from the bottom up
