Why does git am leave modified files lying around? How can I adapt my workflow to do better?

Question

This will be a long one but I hope you could bear with me.

I am trying to use git to put my team's source code under version control. After trying to find different approaches that would work for me, I finally decided to use git format-patch feature. FWIW, the product is an ASP.NET web application running in Windows and I am currently using msysgit.

Background:
I have a staging server (mirrors production server) which contains all the aspx files. I then created a git repo using init-db inside my root folder and did a git add . to track all the files.

In order for me to have a local copy on my laptop, I actually zipped up the ".git" folder from the staging server and FTP'ed it to my local machine. Renamed it to "staging.git" and did a git clone staging.git webappfolder to do my development against.

After doing 2 commits for feature1 and feature2, it's time to apply the changes back to the staging server. I did a git format-patch -2 which outputs to files 0001blah.patch and 0002blah.patch.

These 2 patch files are then sent to the staging server and I did a git am 0001blah.patch on the staging server itself. Doing a git log shows the commit went through. But when I do a git status, it shows Changed but not updated: modified: file1.aspx.

What does that mean exactly? I also tried doing a git apply 0001blah.patch but all I got was an error" patch failed: file1.aspx: patch does not apply.

Is there a problem with my workflow? Any insight regarding the proper way or help would be extremely helpful. Again, the patching model would be the most viable for us right now as we won't be setting up an SSH server anytime soon.

Answer 1

I just tried this:

rm -rf clone?

# clone 1 is the working copy
mkdir clone1
(
    cd clone1
    git init
    echo foo >> file1
    git add file1
    git commit -m "Initial state"
)

# clone 2 is the staging repo
git clone clone1 clone2

# create patches
(
    cd clone1
    git tag staging # tag to track what's in staging

    echo feature1 >> file1
    git add file1
    git commit -m "Feature 1"

    echo feature2 >> file1
    git add file1
    git commit -m "Feature 2"

    rm *.patch
    git format-patch staging
)

# apply patches
(
    cd clone2
    git am ../clone1/*.patch
    # Cygwin/msysgit line ending weirdness when patching. Aborting and
    # reapplying clears it up.
    git am --abort 
    git am ../clone1/*.patch
    git log
    git status
)

Has the minor issue with the patches not applying clearly without doing the am twice, but I end up with a clean working dir in clone 2 with the right contents of file1. So there doesn't seem to be anything wrong with your workflow per se.

Git apply will only update the working tree, not perform a commit.

That said, I wouldn't use a git repository for staging. My workflow would probably make a release branch / fork of the development repository (or not), and just deploy full clean copies of that.

For incremental updates to the staging environment, just use git tag staging in the release branch, "git diff staging..HEAD > update.patch" to email, and the standard unix "patch -p1" to apply it should work. That is unless you really need have the change history physically on the staging server.