Re: Newbie grief

In message <4F9F128C.5020304@palm.com>, 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