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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.