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

Search Discussions

  • Aidan Van Dyk at Oct 1, 2010 at 3:44 pm

    On Fri, Oct 1, 2010 at 11:27 AM, Tom Lane 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.
  • Tom Lane at Oct 1, 2010 at 3:53 pm

    Aidan Van Dyk writes:
    On Fri, Oct 1, 2010 at 11:27 AM, Tom Lane 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
  • Aidan Van Dyk at Oct 1, 2010 at 4:29 pm

    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
    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)
  • Magnus Hagander at Oct 1, 2010 at 4:30 pm

    On Fri, Oct 1, 2010 at 17:53, Tom Lane wrote:
    Aidan Van Dyk <aidan@highrise.ca> writes:
    On Fri, Oct 1, 2010 at 11:27 AM, Tom Lane 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"?
  • Tom Lane at Oct 1, 2010 at 4:50 pm

    Magnus Hagander writes:
    On Fri, Oct 1, 2010 at 17: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?
    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
  • Andrew Dunstan at Oct 1, 2010 at 5:08 pm

    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 Lanewrote:
    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
  • Andrew Dunstan at Oct 1, 2010 at 5:21 pm

    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
  • Andrew Dunstan at Oct 1, 2010 at 6:55 pm

    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
  • Heikki Linnakangas at Oct 1, 2010 at 4:48 pm

    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
  • Andres Freund at Oct 1, 2010 at 5:23 pm

    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
  • Andrew Dunstan at Oct 1, 2010 at 6:28 pm

    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
  • Tom Lane at Oct 1, 2010 at 7:14 pm

    Andrew Dunstan 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
  • Robert Haas at Oct 1, 2010 at 6:10 pm

    On Fri, Oct 1, 2010 at 11:53 AM, 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?
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedOct 1, '10 at 3:27p
activeOct 1, '10 at 7:14p
posts14
users8
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase