On Mon, Feb 27, 2012 at 01:06:02PM -0800, Junio C Hamano wrote: > >>> I'm happy to do either (rebase or filter-branch). Just let me know. > >> > >> I would understand Avery's "should we filter-branch/rebase, or is it OK > >> as-is?", but I do not understand what you mean by "either rebase or > >> filter-branch is fine". > > > > Sorry, got mixed up there. I'm not that familiar with filter-branch. > > Now I understand you do both. :) > > > > So have we decided to keep the history? > > I think the discussion so far was: > > - Peff suggested to keep the history with a true merge; > > - I said the history before the final commit in Avery's tree did not look > so useful for future archaeology; and then > > - Avery corrected me that there are contributions by other people and the > credits will be lost if we discarded the history; > > and everybody (including me) now favors to have the history. > > So the answer to your question is yes, but I do not think we heard opinion > from anybody regarding the question by Avery yet. I personally do not see > how it would help us if the old history is rewritten at this point. Yeah, I don't see much point in rewriting. If parts of the history suck, then so be it. It's probably not that big to store. And while it's sometimes easier to fix bad commit messages when they are recent and in your memory (rather than trying to remember later what you meant to say), I think it is already too late for that. Any archaeology you do now to make good commit messages could probably just as easily be done if and when somebody actually needs the commit message later (emphasis on the "if" -- it's likely that nobody will care about most of the commit messages later at all). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html