From: Dennis Kaarsemaker <dennis@kaarsemaker.net>
To: Marc Haber <mh+git@zugschlus.de>, git@vger.kernel.org
Subject: Re: how to check for uncommitted/unstaged changes on remote side before pushing
Date: Mon, 09 Nov 2015 09:25:00 +0100 [thread overview]
Message-ID: <1447057500.5074.8.camel@kaarsemaker.net> (raw)
In-Reply-To: <20151108212320.GA18762@torres.zugschlus.de>
On zo, 2015-11-08 at 22:23 +0100, Marc Haber wrote:
> Hi,
>
> I am trying to abuse git as a code distribution channel and would
> like
> to be able to trigger redistribution just by git push.
[insert obligatory remark about git not being a deployment tool]
> The idea is to push to a remote to the branch that is currently
> checked out followed by a git reset --hard in the post-receive hook.
> I
> have already figured out that I need to set receive.denyCurrentBranch
> to ignore to be able to push to the currently checked out branch.
You'll need a new enough git, so you can set it to updateInstead (and
maybe use a push-to-checkout hook).
> I am also aware that it is a good idea to git pull before git push
> just in case there were local commits on the remote.
No, hooks should never pull, merge or do anything that could be
interactive.
> git reset --hard will unconditionally throw away local uncommitted
> changes. I would like to detect this situation on the remote and
> abort
> the receive progress. But my pre-receive hook does not work as
> intended. Here is my code:
>
> [snip code]
>
> What is going wrong here?
You mention a post-receive hook first, but have written a pre-receive
hook. Not sure if that's what you intended (or even if that's what's
going wrong).
> If my entire approach is wrong, what is the recommended way to
> prevent a repository with unstaged or uncommitted changes from being
> pushed to?
Push-to-checkout is a very simplistic way of deploying and while it
works in simple cases, I'd not recommend it.
Two safer/saner approaches are:
- Have a separate non-bare repo, and make the post-receive hook in a
bare repo trigger a fetch+reset in the non-bare one
- Use git archive and symlink trickery for even better deploys
Questions like this come up in #git all the time, so I wrote up a few
more detailed recipes here, including working hooks and config for all
three ways of deploying:
http://git.seveas.net/simple-deployments-with-git.html
--
Dennis Kaarsemaker
www.kaarsemaker.net
next prev parent reply other threads:[~2015-11-09 8:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-08 21:23 how to check for uncommitted/unstaged changes on remote side before pushing Marc Haber
2015-11-09 8:25 ` Dennis Kaarsemaker [this message]
2015-11-09 9:31 ` Marc Haber
2015-11-09 9:38 ` Dennis Kaarsemaker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1447057500.5074.8.camel@kaarsemaker.net \
--to=dennis@kaarsemaker.net \
--cc=git@vger.kernel.org \
--cc=mh+git@zugschlus.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).