best/simplest way to keep multiple (non-bare) Git

问题:

I have several non-bare Git repositories. There is one central Git repository (or at least handled as being the central repo; this might change) but this is also non-bare (because I want to have a checkout on the same machine). My history is mostly linear and I'm the only person who will ever do changes on this repository, so it is unlikely that conflicts will happen. (It is my documents directory.)

Pushing directly into another non-bare repository doesn't work if I use the master branch everywhere. There is receive.denyCurrentBranch which would allow this but it doesn't really help me because (1) it doesn't update the local checkout and (2) I'm afraid of what happens in case there is a conflict.

There are a few related/similar questions here:

• simplest way to sync a repository with a checked out branch: Suggests setting up an Bash alias (basically ssh git pull).
• making pushes to non-bare repositories safe: Using a post-update hook (with a strong advise to avoid it). Or rather push it to some specific unique remote ref and let the destination later handle the merging.

I want a solution which is 100% safe. So I think using a post-update hook is no option for me.

I think my use case is not actual that uncommon so I wonder if there are some common solutions for this. Are there?

I think, what I want is:

• Push local master to some remote special ref (like merge-request-xy) (i.e. like git push origin master:merge-request ?).
• On the remote, if we can fast-forward and the working copy is clean, fast-forward, update the working copy and delete the ref (basically git merge merge-request && git branch -D merge-request ?).

Would that be safe or a good way to do it?

回答1:

The solution you have suggested is safe as long as you (1) push to a different branch than master, like merge-request and (2) do the checks about merging. For the second part, fast-forwarding if everything is in the clear on the remote, you can use a post-update hook like this one:

#!/bin/sh

# check args to see if merge-request was pushed,
# and do nothing if it wasn't
if ! $(echo $@ | grep -q 'merge-request');
then
 echo "merge-request not updated"
 exit 0
fi

# cancel if master is not checked out
THIS_BRANCH=$(git branch --no-color | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1/')
if [ "$THIS_BRANCH" != "master" ];
then
  echo "master not checked out, not merging"
  exit 1
fi

# cancel if working dir is dirty
if [ $(git status --porcelain | wc -l) != 0 ];
then
  echo "working dir is dirty, not merging"
  exit 1
fi

# try to merge, but only do so if the merge is fast-forward
# try to delete, but only do so if the merge succeeded
git merge --ff-only merge-request && git branch -d merge-request

Make sure to chmod +x your post-update script. When you push, output of this hook will be shown in the console prefaced by "remote:"

In order to push from master into origin/merge-request on the remote, you can either set the push var in your remote config in .git/config (which lets you call git push origin:

[remote "origin"]
    push = +refs/heads/*:refs/merge-request/*

or you can set a repo-specific alias:

[alias]
    push = push origin master:merge-request

回答2:

The dangerous part of pushing to a non-bare repository with a post-update hook is if the remote working copy is unclean and/or you can't do a fast-forward. If you're going to put those pre-conditions on your solution, you might as well go with the better-tested post-update hook with a checkout option.

If you can't guarantee those preconditions, you're going to have to resolve any conflicts from the other end anyway. In that case, you again might as well go with the post-update hook option, but make sure to do the checkout without a --force so if there is a conflict you don't lose local changes.

I still don't see why so many people seem averse to having a bare and non-bare repo on the same machine. I have a bare repo at home that I push to from both home and work. When I start working at either location, I pull into my non-bare repository. It takes 2 seconds, and I'm always in the best physical location to resolve any potential conflicts.