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.

Roseline

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.

Massacre

"Git apply will only"... "will only what" ? ;) – Smalls

Thanks SiitheMoose, after trying out your example and getting no errors, I began to wonder what's wrong with my source files. That prompted me to re-edit my line endings and doing a "git am" works with no errors. I'm marking this answer correct since your suggestion works for my staging environment. – Roseline

Great test and description. +1 – Smalls

Answer 2

Did you try a

git am -3 

? From the git-am doc,

-3
--3way

When the patch does not apply cleanly, fall back on 3-way merge

---

Note: From Git Google Summer of Code 2009, there is a project to "Teach git-apply the 3-way merge fallback git-am knows":

When git-apply patches file(s) the files may not patch cleanly. In such a case git-apply currently rejects the patch.
If it is called from git-am then a 3-way merge is attempted by:

• taking the "index ..." data from the patch and
• constructing a temporary tree,
• applying the patch to that, then
• merging the temporary tree to the current branch.

For various reasons it would be nice to do the entire temporary tree dance directly inside of git-apply, as it can benefit say the git-sequence's "apply" command, speed up git-am processing by forking less, etc

Smalls

I tried git am -3 but the results were still the same but nonetheless, thanks for taking the time and effort. – Roseline