4

Our team has recently migrated to git.

We have production web application server with some small changes to code

  • ultra hot hotfixes specific to this installaton
  • some debugging statements for those bugs that can't reproduced in our testing enviroment

I think, we can't commit those in server repo.

When we had svn update either merged changed file or not merged. Now

 git stash; git pull; git stash pop

does the trick for me

How can I automatically detect those cases when git stash pop will cause conflicts

making production working copy broken?

I want send mail to resolve these cases manually

before they occur like be advised, pull cancelled (conflicts)

jonny
  • 1,326
  • 9
  • 44
  • 62
  • 2
    Could those small changes on the production server be tracked in a new branch? I'm wary of any important code that isn't stored in a repository, and this setup feels brittle. – sarnold Mar 23 '11 at 08:36
  • no, these are `debugging statements` and in this case we need another application installation instead of branch – jonny Mar 23 '11 at 08:48

2 Answers2

5

I would not want to bear the risk of having a merge conflict occur on a production server. This sounds all wrong to me.

From your post, I can infer that you have issues in production that you can't reproduce in testing/staging. To help detect those, you added additional instrumentation to your application. This is a common approach, although you should really try to get failures reproduced in Q&A (usually it's worth the initial hit in terms of long-term benefits).

The next thing I'd infer is that you're directly manipulating code on a production server. You should NEVER EVER do this. You're already using git which gives you a great flexibility of how you can manage things, there are smarter solutions to your problem. Here's what I'd to:

  1. Get those changes from the server (create a patch or something)
  2. Put those changes on to a local branch in your dev repo.
  3. Whenever you change something rebase that local branch on top of your masters HEAD. Resolve conflicts locally.
  4. Since you've mocked with history, you need to force a push into the production repository, see How do I push amended commit to the remote Git repository? for details.

It can also be debated whether you wouldn't want to "productize" the additional logging you added, making it part of your non-functional requirements.

Community
  • 1
  • 1
Johannes Rudolph
  • 35,298
  • 14
  • 114
  • 172
2

I would rather:

  • have a clean separation between the git repository and the web files:
  • not working directly in the working tree directory (with stash issue in order to have a clean working tree for pull operations)

It would be best to push to a bare repo with a post-update hook, and work on a separate Git repo where you can do those pull you need.

The being said, I would rather try to solve any conflict in a temporary branch (from git stash man page)

 git branch <branchname> [<stash>]

Creates and checks out a new branch named <branchname> starting from the commit at which the <stash> was originally created, applies the changes recorded in <stash> to the new working tree and index.
If that succeeds, and <stash> is a reference of the form stash@{<revision>}, it then drops the <stash>. When no <stash> is given, applies the latest one.

This is useful if the branch on which you ran git stash save has changed enough that git stash apply fails due to conflicts. Since the stash is applied on top of the commit that was HEAD at the time git stash was run, it restores the originally stashed state with no conflicts.

Once the conflicts are solved, that branch can be merged back to master.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • We have our central repo in gitosis. I realize that clean working tree on production is question of discipline – jonny Mar 23 '11 at 08:54
  • @jonny: just added a possible way to deal with the stash pop step in a branch. – VonC Mar 23 '11 at 09:05