RE: new file leaked onto release branch

From: Brown, Len <len.brown@intel.com>
Date: Dec 14, 2005, 09:41 UTC
Message-ID: <F7DC2337C7631D4386A2DF6E8FB22B300567ED87@hdsmsx401.amr.corp.intel.com>

Show 11 quoted lines

>> I package up a tar-file for the remote machines with
>> git-tar-tree $BRANCH $REPO | gzip -1 > $TARFILE
>> But I still need to generate a patch containing all the local
>> changes that I haven't checked into git yet.
>
>Let me understand what you have correctly:
>
>    You have the latest commit, changes needed to be tested in
>    working tree, and index is somewhere in-between, because of
>    "git-update-index --add" you did for patch generation; but
>    ideally you would want to keep HEAD and index in sync.

Right, I updated the index so that git diff would work.

I guess I don't really have my head around the index concept. Yes, it seems perhaps that HEAD and index disagreeing about what is in the repo is what caused the problem at hand.

Show 5 quoted lines

>And you need a way to do the above tar-tree + patch equivanent
>to move what you have in your working tree to other machines for
>pre-commit testing.  Some random thoughts on ways to do it.
>
>(1) NFS with "make O=dir/to/store/output/files/"?

I think I prefer the build boxes to be more independent.

They build about a dozen kernels from scratch each, so I can't really keep my working repo frozen for the duration of the builds.

Also, sometimes I have them building different branches and different versions, depending on what is going on.

Also, sometimes I apply a local test patch to the
build box that isn't (yet) shared with the other boxes.

Show 14 quoted lines

>(2) Do you have git on other build boxes?  Perhaps
>
>    mainbox$ edit on "acpica" branch
>    mainbox$ git checkout -b build-test ;# branch from it
>    mainbox$ git add some files
>    mainbox$ git commit -a -m "Build test $(date)" ;# take all
>
>    mainbox$ ssh i386box
>    i386box$ git pull mainbox:/home/lnx/.git build-test
>    Fast forward.
>    i386box$ make ;# happy
>
>    mainbox$ git checkout acpica ; git pull . build-test ;# 
>fast forward

sure, I have git everwhere. But check-in is not a lightweight process for me -- I like to get the contributor & comments right on the check-in as if I'm creating permanent history. I hate checking in a patch just to have to check in a build fix for it 20 minutes later.

this is why I use quilt. I just pop the patches, fix the broken one, and push them back. after build and boot tests, that is when I do the git commit.

Show 10 quoted lines

>(3) Tarball approach, but taking the local modifications along
>    as well:
>
>    mainbox$ git update-index all-changed-paths-not-just-add
>    mainbox$ git-tar-tree $(git-write-tree) $REPO | gzip >$TARFILE
>    mainbox$ git reset ;# unregisters all mods since HEAD from index
>    mainbox$ scp $TARFILE i386box:/home/lnx/
>
>I suspect the last one is the least disruptive to your existing
>workflow.

yes, this is along the lines of what I do now. do these steps capture the changed uncommited source files in my repo?

actually, since the mis-hap with the update-index, what I do now is a make clean mrproper, move the .git directory out of the source tree tar what is left, and then restore the .git directory... this has the nice side effect of taking along the quilt patches directory, and sometimes I've found it useful to do individual build/test between patches in the quilt stack, though I'd probably lose track of what I'm doing if I did that all the time.

thanks, -Len