Confused about git filter-branch results

Confused about git filter-branch results

[Mike Kelly]

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@PirateHaven.org-----------------------The_glass_is_too_big--------

Re: Confused about git filter-branch results

[Thomas Rast]

Mike Kelly wrote:
> filter-branch

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

> 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.

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

> 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.

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".

> 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.

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.

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

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? :-)

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Confused about git filter-branch results

[Mike Kelly]

On Tue, Jan 25, 2011 at 05:32:40PM +0100, Thomas Rast wrote:
> Before you read the explanations below, I recommend that you open
> 'gitk --all' and use it to see whether I'm right.
> 
This was really useful for finding my problem.

> Most likely you filtered all commits on your branch, but not master,
> so master now points to an entirely disjoint set of commits.
> 
Almost exactly correct.  The tree branched off at a really early point in
development.

> 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
> 
Done.  This cleaned up the mess.

> Confused yet? :-)
> 
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
(:

-- 
--------Mike@PirateHaven.org-----------------------The_glass_is_too_big--------