[PostgreSQL-Hackers] So git pull is shorthand for what exactly?

If you have a "local copy of the remote" setup already that's been
updated already, you can to the merge directly:
git merge <branch>
where a branch would normally be something like:
origin/master
or
origin/REL9_0STABLE

That will make a merge commit. Another option, if you're trying to
keep linear development would be:
git rebase origin/master
That will apply all the changes in your current branch since the
"merge-base" of origin/master, onto the tip of "origin/master" (and
set your current branch to the result).

And, "git rebase -i" is something you'll probably want to become very
familiar with if you're really trying to keep a strictly linear
development history.

I'll admit to never bothering to try the "single repo/multiple
seperate workdirs" approach, so I can't speak specifically to that.

a.

Yeah, I don't want a merge. I have these config entries (as per our
wiki recommendations):

[branch "master"]
rebase = true
[branch]
autosetuprebase = always

and what I really want is to update all my workdirs the same way git
pull would do, but not have to repeat the "git fetch" part. This isn't
only a matter of saving network time, it's that I don't necessarily want
the branch heads moving underneath me for branches I already updated.

BTW, I've noticed that "git push" will reject an attempt to push an
update in one branch if my other branches are not up to date, even
if I am not trying to push anything for those branches. That's
pretty annoying too; is there a way around that?

regards, tom lane

I can't speak to the multiple work-dirs aproach, and I don't know how
all your symlinks need to be setup for that.

But, if you've got a current "origin" remote available in your
repository, just do the repase directly, don't do the pull:
git rebase [-i] origin/$branch

All the "pull" does is:
git fetch $origin $branch && git <merge | rebase> FETCH_HEAD

And it get $origin and $branch from your git config, and chooses
merge/rebase based on the branch config too.

If you know you alwyas want to rebase, and your "origin" is always
up-to-date, don't use pull, just use rebase.

I'll admit to being one of the git old-timers that has never used pull
in a reall operation (because I always have an up-to-date remote
already fetched). So I exclusively use merge/rebase directly.
Well, that would be because your "refspec" for pushing is trying to
"push" those branches, and the server is rejecting a non-ff merge.
You can change your refspec to not try and push all the matching
branches (default) to only push the branch you want to push.

A few aliases you might like to try:
[alias]
myrebase = !echo git rebase -i $(git config branch.$(git
name-rev --name-only HEAD).remote)/$(git name-rev --name-only HEAD)
mypush = !echo git push -n -v $(git config branch.$(git
name-rev --name-only HEAD).remote) $(git name-rev --name-only HEAD)

I admit I haven't tried it, but won't that get fixed if you push just
the current branch? E.g. "git push origin master"?

I'll try that next time; I haven't gotten further than using git push's
default behavior.

regards, tom lane

"git push origin HEAD" pushes the current branch, whatever it might be.
That might be a useful alias for you to set up.

cheers

andrew

Oh, and you can change the default by setting push.default to 'current'
instead of 'matching', which is the default default ;-) "man git-config"
for details.

cheers

andrew

Oh, and you can change the default by setting push.default to 'current'
instead of 'matching', which is the default default ;-) "man git-config"
for details.

cheers

andrew

Yeah, that's annoying. You can do "git push origin <branch>", and it
will only try to push that branch, ignoring the others.

If you want that as a default behaviour:
"For example, to default to pushing only the current branch to origin use git
config remote.origin.push HEAD. Any valid <refspec> (like the ones in the
examples below) can be configured as the default for git push origin."


Andres

It's just occurred to me that this might be a slightly dangerous
setting. If HEAD happens to be your private topic branch because you
forgot to switch back to the main branch, it will cheerfully push your
no longer private branch. If you have separate git dirs for each live
branch, it might be better to set the default push refspec to that
branch explicitly. Of course, if you're using the multiple workdir
pattern, that won't work because then they all share a common .git/config.

But maybe I'm just being a bit paranoid.

cheers

andrew

Well, in any case the default behavior of pushing all branches seems
like a good plan for my purposes. If they're not all in sync, I'm happy
with having that pointed out to me. But if I think about it and decide
I want to push just one without first resyncing all the rest, I want a
way to do that. Looks like git push origin <branch> is the ticket for
that. If I made it default to that, I'd be worried about forgetting to
push some branches when I was trying to do a multi-branch update.

regards, tom lane

Are you sure? For me, the pushes on the up-to-date branches succeed
and only the out-of-date ones fail.