On Thu, 17 Mar 2011 10:03:36 -0400, Reid Kleckner <reid.kleckner at gmail.com> wrote: > I don't think anyone has laid out why destroying history is considered > bad by some, so I thought I'd plug this post: > http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html > > Essentially, lets say I have a handful of commits hacking on C code. > While I wrote them, someone changed a C API from under me and pushed > their change. However, in the last change, I remove my dependence on > this API. I pull, rebase, rebuild and test. The tests pass in the > latest commit, so I push. But now if someone tries to go back to > those intermediate commits (say, searching for the introduction of a > regression), they will find a broken build. Yeah, the workflow I'm discussing is about applying individual patches from the tracker, so there's no history in the above sense to worry about. When I start working on a feature branch I will be working in a separate clone and will not rebase. But I will probably produce a collapsed patch when I'm ready to apply to mainline, so the concern with rewriting history won't really apply even there. -- R. David Murray www.bitdance.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4