Re: So git pull is shorthand for what exactly?
От | Aidan Van Dyk |
---|---|
Тема | Re: So git pull is shorthand for what exactly? |
Дата | |
Msg-id | AANLkTini6WAUACFVXusJrfkpOMX96sExDE7D4vrSkzxe@mail.gmail.com обсуждение исходный текст |
Ответ на | So git pull is shorthand for what exactly? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: So git pull is shorthand for what exactly?
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: