On Thu, 17 Mar 2011 10:03:36 -0400, Reid Kleckner <[email protected]> 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 _______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
