Re: Bootstrapping into git, commit gripes at me

[Marc Singer <elf@buici.com>]

On Fri, Jul 08, 2005 at 05:17:08PM -0700, Junio C Hamano wrote:
> >>>>> "MS" == Marc Singer <elf@buici.com> writes:
> 
> MS> In working through a usage example on my way to producing bonafide
> MS> patches, I've found that commit is complaining.  Here's what I've done.
> 
> MS>   o Fetched and built cogito-0.12
> MS>   o Fetched (rsync) Linus' tree
> MS>   o Created a working directory, linux-2.6
> MS>   o linked .git in the working directory to the .git directory fetched
> MS>     from the net.
> 
> This is slightly different from the BCP.  A recommended way is:
> 
>  $ mkdir linux-2.6
>  $ cd linux-2.6
>  $ git-init-db
>  $ rsync linux-2.6.git/ from kernel.org into .git/

Does this preclude symlinking .git?  I'd like to keep one .git which
is mirrored from the net and allow for more than one working
directory.

> Although your commit problem does not have to do with this.
> 
> MS>   o # git checkout -f v2.6.11
> MS>   o # cat ../old-patch-file | patch -p1
> 
> GITified Linux kernel repository starts at v2.6.12-rc2, so
> from anything older you cannot create a commit off of it
> (easily).

Trouble is that 2.6.12 breaks some things and I need to continue to
build patches from 2.6.11 for the time being.  Once I get familiar,
I'll patch the tree to build properly for my targets with later
revisions.

> MS> Then, according to Jeff's instructions, I have to perform
> MS> get-update-cache with the name of each file I changed.  Is that really
> MS> the way?
> 
> MS>   o # git-update-cache LIST_OF_CHANGED_FILES
> 
> That is correct.  Also remember to say:
> 
>     git-update-cache --add LIST_OF_ADDED_FILES
>     git-update-cache --remove LIST_OF_REMOVED_FILES

His text is a little overly-brief on this, but I got the gist.

> Notice the use of git-apply --index instead of patch -p1 in the
> above example?  If you use git-apply --index, you do not have to
> do the above steps yourself.

Notice it...where?  I gather that git-apply is a better way to apply
patches?

> MS>    fatal: 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is not a valid 'commit' object
> 
> That is a tag to the v2.6.11 tree, which is not a valid commit,
> so you cannot make a commit off of it.

So what does this mean?  Can I only produce commits from the master?
Is this a peculiarity of the v2.6.11 tag?

> Linus, I think git-checkout-script should not store a tag to non
> commit in HEAD.  If that did not happen, and if the repo was
> created without ref/heads/master (the usual case), then he
> _could_ have done something like this:
> 
>  $ git checkout -f v2.6.11 ;# fixed one
>  warning: v2.6.11 is not a commit -- not updating your HEAD
>  $ git commit ;# to have his own baseline at v2.6.11
>  $ git-apply --index --stat --summary --apply <../old-patch-file
>  $ : do the usual tests
>  $ git commit ;# create a commit based on the baseline v2.6.11

That sounds like what I'm looking for.  Can I do this by hand somehow?

As an ARM developer, I need to be able to cleanly track kernel
development revisions and produce patches that are easy to merge.  The
cycle is something like this:

  o Update kernel tree.
  o Fix the build.
  o Produce a patch to send upstream.
  o Apply work-in-progress patches
  o Fix the build.
  o Publish new patches against updated kernel tree

The trickiest part has been bringing the works-in-progress forward
without spending lots of time babysitting the SCM tools.