Обсуждение: So git pull is shorthand for what exactly?
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
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 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
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 <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