In message <4F9F128C.5020304@xxxxxxxx>, Rich Pixley writes:
Hey. I'm a newbie struggling to understand git.
I'm trying to do what seems like a simple thing in darcs, monotone,
mecurial, gnu arch, etc, but seems nearly impossible in git. There's a
central repository, a long ways away on the other side of the internet.
So I want a local repository cache. I'm going to be working on a number
of different features and different machines all simultaneously so I
really don't want them all to be pulling from the central repository.
Are you working with anyone else locally? If not, then what you are
probably really trying to do is save time on fetches, so that the
latest changes are more likely to be nearby than far away.
What I would do is set up a bare backup/--mirror repository of the
upstream locally and have it automatically kept up to date with cron
or something like that. Then you can have your pull URL point to this
mirror and the push URL point to the real upstream. This will work as
long as the real upstream and the local mirror are not out of date (if
they are, you will be forbidden to push without either pulling from
the real upstream or wait for the next cron fetch and pull from your
local mirror).
This works, but requires that you separate your fetch and push URLs.
Another option is to use git "alternates" to have your local
repository also look at the automatically updated repository so that
you would only fetch over-the-network-changes since the last automatic
fetch (which, unless you had the cache have an alternate for the
primary repository, would mean that the changes would be transferred
twice).
Alternates can be problematic if you start moving repositories around
or delete them or whatever since the repository with the dangling
alternate will then be bad (until the objects reappear one way or
another), so perhaps you just want a cron job to `git fetch` or `git
remote update -p` in your local repository every so often. Then you
can just `git merge` or `git rebase` to get the latest changes instead
of `git pull [--rebase]`. This is really the simplest solution. No
extra repositories, no configuration changes, just straightforward git
operations. The only trick would be race conditions between you (as a
human) reviewing the latest changes and then typing the command to
merge/rebase them into your local branch and the cron job updating the
remote—seeing what happened afterwords would of course work. I would
probably try this first and only start using the others if this became
problematic for some reason.
None of these cases specifically handles trying to automate pushes,
mostly because it cannot always be automatically resolved (and
depending on local standards on running test suites before any change
is pushed, perhaps should not ever be automatically resolved even for
trivial conflicts) if changes appear on the real upstream between your
last pull and your next push.
Could it be done? Sure. You can push to your local upstream and then
have it push out automatically, but if there are conflicts you will
need to deal with them, and I would suggest doing so with a bare
repository, essentially by having a static preference for the
real-upstream's changes and have the cron job send mail to you telling
you to re-pull and re-push if it failed to push out due to the remote
having changed (telling you the ref/SHA1 that it failed to push).
Of course, this isn't *that* different from just sticking a `git push`
into the background which sends mail/notifies if the push failed for
some reason, and again doing so would be much easier than an
intermediary repository solution.
But with git, I can't push unless the cache repository is bare,
but if the cache repository is bare, then a change to the central
repository will cause the two to become wedged since neither can
push or fetch the other.
Not strictly speaking true. By default git will forbid pushes to
non-bare repositories (see receive.denyCurrentBranch in man
git-config) since without special automation the working directory
will get out of date. See http://bare-vs-nonbare.gitrecipes.de/ for
more information. However, I cannot think that having to perform
integration in this second repository would actually work.
It seems that git is allergic to the dual head branch solution or
something, which is surprising and disappointing.
Git tracks your version of master separately from each other remote's
master. This is exactly dual/multiple heads. What git *does* forbid
(by default) is:
1: Letting you update someone else's checked out (non-bare) repository
underneath them
2: Letting you update someone else's repository if they have more
recent changes than you do.
Both of these defaults are really good ideas, but you can disable them
if you think you know better.
-Seth Robertson
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html