So git pull is shorthand for what exactly?

On Fri, Oct 1, 2010 at 11:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

man git-pull sayeth

    In its default mode, git pull is shorthand for git fetch followed by
    git merge FETCH_HEAD.

However, I just tried that and it failed rather spectacularly.  How do
you *really* update your local repo without an extra git fetch step?

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.

Aidan Van Dyk <aidan@highrise.ca> writes:

On Fri, Oct 1, 2010 at 11:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

man git-pull sayeth

� � In its default mode, git pull is shorthand for git fetch followed by
� � git merge FETCH_HEAD.

However, I just tried that and it failed rather spectacularly. �How do
you *really* update your local repo without an extra git fetch step?

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

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

On Fri, Oct 1, 2010 at 11:53 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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.

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:
[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)

On Fri, Oct 1, 2010 at 17:53, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Aidan Van Dyk <aidan@highrise.ca> writes:

On Fri, Oct 1, 2010 at 11:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

man git-pull sayeth

    In its default mode, git pull is shorthand for git fetch followed by
    git merge FETCH_HEAD.

However, I just tried that and it failed rather spectacularly.  How do
you *really* update your local repo without an extra git fetch step?

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

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?

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"?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On 01.10.2010 18:53, Tom Lane wrote:

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?

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

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Magnus Hagander <magnus@hagander.net> writes:

On Fri, Oct 1, 2010 at 17:53, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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?

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

On 10/01/2010 12:49 PM, Tom Lane wrote:

Magnus Hagander<magnus@hagander.net> writes:

On Fri, Oct 1, 2010 at 17:53, Tom Lane<tgl@sss.pgh.pa.us> wrote:

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?

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.

"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

On 10/01/2010 01:08 PM, I wrote:

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

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

On 10/01/2010 01:08 PM, I wrote:

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

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

On Friday 01 October 2010 18:48:25 Heikki Linnakangas wrote:

On 01.10.2010 18:53, Tom Lane wrote:

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?

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

On Fri, Oct 1, 2010 at 11:53 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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?

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

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On 10/01/2010 01:23 PM, Andres Freund wrote:

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."

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

Andrew Dunstan <andrew@dunslane.net> writes:

On 10/01/2010 01:23 PM, Andres Freund wrote:

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."

It's just occurred to me that this might be a slightly dangerous
setting.

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