Re: Bootstrapping into git, commit gripes at me

From: Marc Singer <elf@buici.com>
Date: Jul 9, 2005, 00:40 UTC
Message-ID: <20050709004047.GA27080@buici.com>

On Fri, Jul 08, 2005 at 05:17:08PM -0700, Junio C Hamano wrote:

Show 17 quoted lines

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

Show 8 quoted lines

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

Show 10 quoted lines

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

Show 11 quoted lines

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