Git v2.3 Release Notes(raw.githubusercontent.com)
raw.githubusercontent.com
Git v2.3 Release Notes
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.3.0.txt
1 comments
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?
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.
I didn't know there was such a thing as a 'remote working directory', so clearly I am confused!
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)
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)
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
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.