Confused about git filter-branch results

Hi Everyone,

I was fooling around with 'git filter-branch --env-filter ...' trying to update the timestamps on my commits (which worked), but now when I run 'git whatchanged -p master..' shows all changes to the entire project, not the differences between my branch and the master branch.

Being a novice git user, I'm not sure how much to trust that I didn't hose git in some really weird way, leaving it in a state where it doesn't quite work the way it did before.

The contents of .git/refs/original/refs/heads/ shows a file with my branch name which contains only one entry (presumably the one I updated the timestamp on) so I feel pretty sure that only the commit I wanted to change actually changed. However, the fact that 'git whatchanged -p' now behaves differently makes me worry.

Nothing went wrong during my update, however, I forgot to give a range label so it searched the entire project. In theory nothing should have changed, but...

Ultimately, my worry is that I polluted the history which I cloned, and pushing that would make people unhappy.

I can still get to my patches, so I can still do a fresh pull and reapply all my changes again, as a last resort, but I'd rather not if I don't have to.

So my questions are:
 1) Is this a problem with an easy fix?
 2) If not, can I back out my change?
 3) Is git push --dry-run the best way to find out what I changed?  Is there
    a better way to see what will be pushed?
 4) Is there a better way to update the timestamps of my commits so that my
    patches will appear as a solid block of commits in the history (as that
    is how they will be committed), not interleaved with other changes in
    the past (giving the false impression that they were applied to the
    master tree when they were not)?

Thanks in advance,

Mike (:

Mike Kelly wrote:

Before you read the explanations below, I recommend that you open 'gitk --all' and use it to see whether I'm right.

Most likely you filtered all commits on your branch, but not master, so master now points to an entirely disjoint set of commits.

It's hopefully impossible to get git into a *inconsistent* state with filter-branch (i.e., a state that the computer would refuse to process), but it is indeed quite easy to get it into a state that humans would call "a mess".

That's not how it works. A branch contains the sha1 of ("is a pointer to") its tip commit. The refs/original/refs/heads/foo simply is the old value of the branch, i.e., the old tip commit.

You can use it much like you could use a branch to see the difference between them, e.g.,

   gitk refs/original/refs/heads/foo...foo

but note that if the disjoint history theory above holds, this will not be immediately obvious from the output.

Pushing that would probably make people take a proverbial LART stick to your office.

Assuming my "disjoint history" theory is correct, you should either discard your rewrite along the lines of

  git branch -f foo refs/original/refs/heads/foo

and rewrite again with a range limiter, or rebase your rewritten commits. To illustrate the rebase, assume you had history like

   o---o---o---o---o---o  (master)
                \
                 *---*---*  (foo)

If you really rewrote all history of foo, that means you now have

   o---o---o---B---o---o  (master)
                \
                 1---2---3  (refs/heads/original/foo)

   o'--o'--o'--B'--1'--2'--3'  (foo)

where the ' indicates a rewritten copy of the original commit. You need to manually determine B and B'. The former will most likely be

  git merge-base master refs/heads/original/foo

The latter will be its equivalent, so you can take Bs message and search for its subject in the history of the (rewritten) foo. Once you know B', you can rebase the commits that were previously on foo back to master with

  git rebase --onto B B' foo

That will create another series of rewritten copies of 1', like so:

   o---o---o---B---o---o  (master)
               |\
               | 1---2---3  (refs/heads/original/foo)
               |
                \
                 1''--2''--3''  (foo)

   o'--o'--o'--B'--1'--2'--3'  (foo@{1})

Confused yet? :-)

On Tue, Jan 25, 2011 at 05:32:40PM +0100, Thomas Rast wrote:

This was really useful for finding my problem.

Almost exactly correct. The tree branched off at a really early point in development.

Done.  This cleaned up the mess.

Not at all, I found your explanation to be clear and straight forward. Thank you.

At first I was grumbling to myself about git filter-branch rewriting every commit, but then I remembered that there were a few messages on stderr complaining that some commits were not in the correct encoding. I guess that the tool decided to rewrite these commits for me (without asking), thus causing a fork. Sorry for not mentioning these error messages before, I forgot about them in the ensuing panic.

I just want to give a shout-out to all the git developers, I've used RCS, CVS, and SVN in the past, and they all had different ways of making life miserable. Git is the first tool which I felt was working with me, not against me. Keep up the good work!

Anyway, I'm back in business and have by branch under control again.

Thanks again,

Mike (: