On Fri, Jul 08, 2005 at 05:17:08PM -0700, Junio C Hamano wrote: > >>>>> "MS" == Marc Singer <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
