how to import stuff?

Hi.

I'd like to track the -mm tree in git.

I already have a linux git tree cloned from kernel.org, so I thought I'd try

git checkout -b v2.6.16-rc1 v2.6.16-rc1 git checkout -b v2.6.16-rc1-mm3 patch -Np1 < 2.6.16-rc1-mm3

So far so good - I have a tree with the patches applied

but then how do I add / remove new / deleted files?

git update-index --add --remove --refresh --ignore-missing

seems to generate a list of said files, but I cant seem to figure out how to get it to actually do anything useful with them.

git add . adds all the new files, but there seems to be no equivalent to remove files

and I really dont want to run git updat-index on *every single file* that changed by hand.

Surely Im missing something, but I cant see what for the life of me. The 
  'everyday git' document seems to focus on small changes to one or two 
files.

managing files not yet in or removed from the source isnt something effectively covered in the document (or if it is, I missed it somehow).

Its probably obvious that Im new to this kind of SCM - and I've not got on with SCMs generally... they never seem to be logical to me.

TIA!

-Ian

On Wed, Jan 25, 2006 at 11:40:39PM +0000, Ian Molton wrote:

That happens on commit without the need for any special command.

--b.

"J. Bruce Fields" <bfields@fieldses.org> writes:

... as long as you say "git commit -a", that is.

Ian Molton <spyro@f2s.com> writes:

You are creating a branch called v2.6.16-rc1 while you have a tag with the same name. From this point on, when you say v2.6.16-rc1 when git expects an arbitrary revision name, the commit Linus tagged with that name is used. When git expects you to use it a branch name, it uses the branch head commit of the branch you created here. Once you create a new commit in that branch, these two will refer to different commits depending on the context. Unless you really understand what you are doing, this would confuse you, so do not do this. Use some other branch name. Better yet...

Starting from a vanilla clone from Linus, up to this point you could probably have done:

	$ git checkout -b v2.6.16-rc1-mm3 v2.6.16-rc1

You do not need v2.6.16-rc1 branch if you immediately create another branch, which is the branch you would want to work on.

        $ git apply --index 2.6.16-rc1-mm3

If the patch you are using cleanly applies without fuzz, this would apply them to the working tree, and all the new and/or removed files are registered to the index, without you having to say "git update-index".

I have no idea what this update-index line with only the flags means, so let's forget about that.

After applying the patch with "patch -p1 -E" on top of the vanilla version:

	$ git add .

would add all the new files.  Then

	$ git commit -a -m '2.6.16-rc1-mm3'

would notice removed and modified files as well when making a commit.

HOWEVER.

I honestly do not understand what value you are expecting to get out of git, if you are rolling the whole thing from -mm series into a singe commit. Commit is designed to be easily handled as an atomic change, and being able to pick and choose only parts of it was never part of its design goal, so I do not understand what useful things you are expecting to do, after you create that commit.

IOW, there is a reason -mm series is available as individual broken-out/ files.