Re: Managing websites with git

From: Jeff King <peff@peff.net>
Date: Dec 2, 2008, 01:11 UTC
Message-ID: <20081202011154.GA6390@coredump.intra.peff.net>
In-Reply-To: <87k5ajflp0.fsf@sparse.dyndns.org>

On Mon, Dec 01, 2008 at 07:46:35PM -0500, Jason Riedy wrote:

> And David Bryson writes:
> > One really should not push to a non-bare repo.
> WHAT?!?!?!

To clarify: one should not push to the _current branch_ of a non-bare repo...

> And Jeff King responds:
> > It's in master and should be in 1.6.1, but it is a config option that
> > defaults to "warn" for now, so as not to break existing setups.
> WHAT?!?!?!

...and that is what 1.6.1 will warn about.

Show 5 quoted lines

> I do this all the time.  I clone from my main working directory
> onto some cluster / MPP where the build system is all wonky.
> Once I get everything building, I push back to a branch (often
> new) in my main working directory.  Then I can merge the build
> changes whenever I get a chance.

As long as you are not pushing to the currently checked-out branch, then you will see no change in behavior. If you are pushing to the currently checked-out branch, then what are you doing to reconcile the resulting mismatch between the index and HEAD?

> Pushing from these systems often is much, much easier than
> pulling from the origin.  Sometimes you're working in temporary
> space on a back-end node; you can connect out but you cannot
> connect in.

Of course. The recommended thing to do is:

  # on pusher
  git push $remote HEAD:some-branch-that-is-not-checked-out
  # on $remote
  git merge some-branch-that-is-not-checked-out

where an obvious choice for branch name is "incoming/master" or whatever suits your workflow. You can also do:

  # on pusher
  git push $remote HEAD:branch-that-is-checked-out
  # on $remote
  git reset --hard

but that throws away anything else going on in that branch on $remote.

> It feels like newer gits make more and more decisions about what
> I shouldn't do.

Doing

  git push $remote HEAD:branch-that-is-checked-out

has _never_ worked without further action on $remote. Now we're warning about it.

If you have other specific complaints about new git behavior, I'm sure the list would be happy to hear about it. Almost every behavior change is in response to user complaints, and a lot of effort is put into maintaining backwards compatibility. If we've screwed up somewhere, it would be good to know.

-Peff