# RE: new file leaked onto release branch

1 messages from 2005-12-14 to 2005-12-14. Participants: Brown, Len.
Thread: https://gitlist.dev/t/2831

## Brown, Len, 2005-12-14 09:41

Subject: RE: new file leaked onto release branch
Message-ID: <F7DC2337C7631D4386A2DF6E8FB22B300567ED87@hdsmsx401.amr.corp.intel.com>
URL: https://gitlist.dev/e/F7DC2337C7631D4386A2DF6E8FB22B300567ED87%40hdsmsx401.amr.corp.intel.com

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

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

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

```