Thread: So git pull is shorthand for what exactly?

So git pull is shorthand for what exactly?

From
Tom Lane
Date:
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?

Poking around, it looks like each workdir has its own copy of
.git/FETCH_HEAD, which may be the problem --- I was trying to update a
workdir that wasn't the one I'd done git fetch in.  Do I have to put
together a script that copies FETCH_HEAD from place to place?
        regards, tom lane


Re: So git pull is shorthand for what exactly?

From
Aidan Van Dyk
Date:
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.


Re: So git pull is shorthand for what exactly?

From
Tom Lane
Date:
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


Re: So git pull is shorthand for what exactly?

From
Aidan Van Dyk
Date:
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)


Re: So git pull is shorthand for what exactly?

From
Magnus Hagander
Date:
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/


Re: So git pull is shorthand for what exactly?

From
Heikki Linnakangas
Date:
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


Re: So git pull is shorthand for what exactly?

From
Tom Lane
Date:
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


Re: So git pull is shorthand for what exactly?

From
Andrew Dunstan
Date:

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


Re: So git pull is shorthand for what exactly?

From
Andrew Dunstan
Date:

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



Re: So git pull is shorthand for what exactly?

From
Andres Freund
Date:
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


Re: So git pull is shorthand for what exactly?

From
Robert Haas
Date:
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


Re: So git pull is shorthand for what exactly?

From
Andrew Dunstan
Date:

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


Re: So git pull is shorthand for what exactly?

From
Andrew Dunstan
Date:
  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



Re: So git pull is shorthand for what exactly?

From
Tom Lane
Date:
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