git fast-export/fast-import *facepalm*

Hi,

I've had a bit of a brain melt and have done something silly with git
fast-import and was hoping someone would be able to get me out of the
mess I've created.

Basically I've got a linux repository which for various reasons isn't
based of any of the kernel.org ones but reflects our kernel
development on top of vanilla kernel tarballs. When we update we take
the tarball and extract and commit it to a vendor branch then merge
that with our main. A little strange but it works for us (despite
having to go hunting on kernel.org when we want the external history).

My brain melt came when I wanted to get the set of changes between 2
versions from a public branch and import them into our repository.
Having just learned about git fast-export I decided that it was the
right tool for the job so I did the following

(cd linux-2.6.32.y; git fast-export v2.6.32.12..v2.6.32.14) | git fast-import

What I've ended up with is a repository with a detached set of changes i.e

o -o   l - l - l - l - l - l     o - master
     \                          /
      o - o - o - o - o - o

o = our commits
l = linux commits

Because the code is common textually I think what I really should have done is

(cd linux-2.6.32.y; git format-patch v2.6.32.12..v2.6.32.14) | git am

Which I'll give a try in a minute. In the meantime is there anyway for
me to safely remove the upstream linux commits without loosing our
commits in the process?

Thanks,
Chris

Chris Packham [off-list ref] wrote:

What I've ended up with is a repository with a detached set of changes i.e

o -o   l - l - l - l - l - l     o - master
     \                          /
      o - o - o - o - o - o

o = our commits
l = linux commits

Because the code is common textually I think what I really should have done is

(cd linux-2.6.32.y; git format-patch v2.6.32.12..v2.6.32.14) | git am

Which I'll give a try in a minute. In the meantime is there anyway for
me to safely remove the upstream linux commits without loosing our
commits in the process?

If I read your diagram right, the l-l-l chain isn't connected at
all to your graph, so it should just get removed with `git gc`.

But if it is connected due to a merge with your master, lookup the
merge and find its parent which is your local stuff and `git reset
--hard` to that commit.

-- 
Shawn.

On Thu, May 27, 2010 at 4:46 PM, Chris Packham [off-list ref] wrote:

My brain melt came when I wanted to get the set of changes between 2
versions from a public branch and import them into our repository.
Having just learned about git fast-export I decided that it was the
right tool for the job so I did the following

(cd linux-2.6.32.y; git fast-export v2.6.32.12..v2.6.32.14) | git fast-import

Personally what I would do is use git rebase instead:

# WARNING: untested.  back up your repo first!
cd my-repo
git fetch ../linux-2.6.32.y v2.6.32.14
git branch b FETCH_HEAD
git fetch ../linux-2.6.32.y v2.6.32.12
git branch a FETCH_HEAD
git checkout b
git rebase --onto master a
# now your branch b should be master + the patches from a..b

Which I'll give a try in a minute. In the meantime is there anyway for
me to safely remove the upstream linux commits without loosing our
commits in the process?

Looks like Shawn answered this question.  In any case, the answer is git-reset.

Have fun,

Avery

On Thu, May 27, 2010 at 2:03 PM, Shawn O. Pearce [off-list ref] wrote:

Chris Packham [off-list ref] wrote:

quoted

What I've ended up with is a repository with a detached set of changes i.e

o -o   l - l - l - l - l - l     o - master
     \                          /
      o - o - o - o - o - o

o = our commits
l = linux commits

Because the code is common textually I think what I really should have done is

(cd linux-2.6.32.y; git format-patch v2.6.32.12..v2.6.32.14) | git am

Which I'll give a try in a minute. In the meantime is there anyway for
me to safely remove the upstream linux commits without loosing our
commits in the process?

If I read your diagram right, the l-l-l chain isn't connected at
all to your graph, so it should just get removed with `git gc`.

Well it _looks_ detached in gitk I can't see any merge commits. I've
tried git gc but no joy. Maybe I need to tell it to be a bit more
thorough.

But if it is connected due to a merge with your master, lookup the
merge and find its parent which is your local stuff and `git reset
--hard` to that commit.

--
Shawn.

On Thu, May 27, 2010 at 5:57 PM, Chris Packham [off-list ref] wrote:

Well it _looks_ detached in gitk I can't see any merge commits. I've
tried git gc but no joy. Maybe I need to tell it to be a bit more
thorough.

Why is it showing up in gitk at all?  Does it have its own branch
name?  gitk will normally only show commits that are attached to
something, unless you list a particular commit id explicitly on its
command line.

Once the commits are "detached" correctly, saving the disk space is
kind of unnecessary.  (Most likely the old commits are being held in
the reflog at least, which usually expires in 30 days or so for
safety.)  Moreover, most of the space is probabably space occupied by
the actual files in the revisions, which will be needed when you port
the patches "correctly" anyhow, so there's no point in going through
extra effort to recover the space just so you can use it again.

Have fun,

Avery