git workflow question

Hi, 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 codes 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, its 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.

This 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 exremely 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. Once again, thanks in advance.

From stackoverflow

• 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

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

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

  VonC : "Git apply will only"... "will only what" ? ;)

  Ghazaly : 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.

  VonC : Great test and description. +1