3 ms·

Git v2.3 Release Notes

• rspeer 12y ago
  * "git push" into a repository with a working tree normally refuses to modify the branch that is checked out. The command learned to optionally do an equivalent of "git reset --hard" only when there is no change to the working tree and the index instead, which would be useful to "deploy" by pushing into a repository. Nice! This sounds like something that I expected Git to do since the first time I used it, which means that I ran straight into the unfriendly error messages that result from pushing to a checked-out repository. Using hooks for simple deployments has always seemed clumsy compared to the thing that I originally imagined Git could do. I'm glad to hear that Git now supports this use case.
  • jrochkind1 12y ago
    Wait, is this saying that `git push` can now change your local working tree, instead of changing the remote you are pushing to? That doesn't sound like what i'd expect, but I think maybe I'm misunderstanding what it does when?
    • resc1440 12y ago
      Git push gained the ability to change the remote working directory - but only if that copy of the repo has been set up to allow it.
      • jrochkind1 12y ago
        I didn't know there was such a thing as a 'remote working directory', so clearly I am confused!
        • mattikus 12y ago
          There are a couple of scenarios I can think of to help it make more sense: 1) You're pushing to a remote server which has a checkout of the working copy as the live version of something, e.g. a webapp. 2) You're pushing to a co-workers repository to allow them to see updates (though probably a less likely scenario)
  • SethKinast 12y ago
    Yep, I've been using a post-receive hook alongside "receive.denyCurrentBranch ignore" read oldrev newrev ref branchname=${ref#refs/heads/} git --git-dir=. --work-tree=$PWD/.. checkout -f ${branchname} git --git-dir=. --work-tree=$PWD/.. reset --hard $newrev