On Fri, Oct 1, 2010 at 11:53 AM, Tom Lane wrote:
Yeah, I don't want a merge. I have these config entries (as per our
rebase = true
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.
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.
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?
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:
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)