Re: Cloning errors - SOLVED

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

>> It isn't particularly difficult to fix this for the master branch,
>> but since this would be a history rewrite, the resulting tree would
>> be a fork, effectively. There aren't a ton of people committing to
>> this repo, so fixing it wouldn't be too disruptive. Strong feelings
>> either way?
>
> Really? It's fixable? I thought you guys all told me it was basically
> impossible to edit a commit log entry deep in the tree.

/I/ never told you anything about it :)

Commits are immutable. A fix would be to edit the offending commits to
create new commits with a more reasonable date. Then everything in the
future from those rewritten commits would be replayed to create a new
master branch that doesn't have the tainted history.

>From git's point of view this new master branch would be a fork that has
branched off at the time of the date fix: in 2006.


> What's the recipe for doing so?

"git filter-branch"

This is relatively straightforward. I can make a fixed master branch, if
you'd like to look at it.


> FWIW there is at least one other date error in the history. But really
> there are many places I'd go back to correct typos if it were
> possible. I think git would be much improved by keeping the commit
> messages in such a way that they could be edited later without
> disruption.

You can go back and change whatever you like, but each time you do that,
you're making a new fork. In my view it could be justified to fix a
failure (like the one that started this thread), but not for anything
else. Even in this case, it's not obviously justified: you need an old
git and/or i686 AND the failure only shows up if you "git fsck"