"Denis Bueno" <dbueno@xxxxxxxxx> writes:
> I was told in the thread above that I could use grafts and "git
> filter-branch" to create a new repository that simply got rid of the
> offending object. That case was simpler, as it was the initial import
> of a file that had only two commits total that was corrupted.
> However, in this case there are changes between the initial and latest
> version of the file, and commits between the corrupted versions, so, I
> can imagine that it would be hard to get rid of in-between commits.
>
> The thing that makes sense intuitively (read: not as a Git expert, but
> as a user) is to just let me replace the commits associated with the
> problematic objects with new versions of those commits (e.g. make
> change described in the commit message, which is different from the
> actual change that was recorded, due to whitespace/formatting issues).
> Is this what I should do? And to do so, should I be reading chapter
> 5 of the manual?
Without checking Git User's Manual, I think the solution could go as
the following.
Assume that history looks like this
...---.---a---*---b---.---...
where by '*' is marked corruped commit (commit shich tree contains
corrupted blobs).
First, you can check the commit message for '*' using git-cat-file or
git-show, you can get the difference between 'a' and 'b' using
"git diff a b". When you know how repaired commit 'X' should look
like, do something like:
$ git checkout -b <temp-branch> 'a'
$ <edit edit edit>
$ git commit
Then history would look like this
...---.---a---*---b---.---...
\
\-X
Now with grafts make 'b' be a child of 'X', i.e. modify parent of 'b'
for history to look like below:
...---.---a---* b---.---...
\ /
\-X-/
Examine history using git-log, git-show, check tree with git-ls-tree
and examining files, use graphical history browser like gitk.
Then if possible use git-filter-branch to make history recorded in
grafts file permanent...
HTH
--
Jakub Narebski
Poland
ShadeHawk on #git
--
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
