It allows to separate when you fetch from when you merge. So, a "git pull"
can be:

$ git fetch
$ git pull --local

and the pull call can be made later. This is usefull when you have multiple
branches and you want to merge the same "upstream" branch, or when you are
offline but you have already fetched the remote branch.

Note that this is different from:

$ git fetch
$ git pull . origin

(1) you do not have to tell explicitly the branch to merge
(2) the commit message is exactly as with "git pull"

Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
 Documentation/fetch-options.txt |    3 +++
 git-fetch.sh                    |   25 +++++++++++++++++++------
 git-parse-remote.sh             |   22 ++++++++++++++++++++++
 3 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 13f34d3..3a6cb3d 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -39,3 +39,6 @@
 	check.  Note that fetching into the current branch will not
 	update the index and working directory, so use it with care.
 
+\--local::
+	Do not fetch from the remote repository. Use the already fetched
+	branches to program the merge for `git-pull`.
diff --git a/git-fetch.sh b/git-fetch.sh
index 79222fb..5ff800a 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -21,6 +21,7 @@ update_head_ok=
 exec=
 upload_pack=
 keep=--thin
+local_fetch=
 while case "$#" in 0) break ;; esac
 do
 	case "$1" in
@@ -56,6 +57,9 @@ do
 	--reflog-action=*)
 		rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'`
 		;;
+	--local)
+		local_fetch=t
+		;;
 	-*)
 		usage
 		;;
@@ -80,6 +84,10 @@ refs=
 rref=
 rsync_slurped_objects=
 
+[ "$local_fetch" = t ] && [ "$remote_nick" = "$remote" ] && \
+    [ "$remote" != "." ] && \
+    die "Flag --local only compatible with remote shorthands"
+
 rloga="$rloga $remote_nick"
 test "$remote_nick" = "$remote" || rloga="$rloga $remote"
 
@@ -285,8 +293,8 @@ fetch_main () {
  ...
[ message continues ]

Santi B
[ message continues ]

2006/10/17, Junio C Hamano <junkio@cox.net>:



I'll try. Off-topic: Do you want also docs for the ^@ notation and an

I see them differently. "branch.remote=." is when there is no upstream

You never know if you can get away without re-fetching (or I don't
parse this sentence :). The way I see it, you always us "git pull"
except when you want to merge the exactly the already fetch branch
because (1) you want to merge the same upstream as with other branch

This is the next item in my TODO :)

I get it. Another idea is to have a .git/ORIGIN that points to the
tracking branch so you could say:

         git log ..ORIGIN
         git log ORIGIN..
         git log ORIGIN...
         git show-branch ORIGIN next

One advantage is that it only needs changes to "git checkout" (and
possibly others but not to plumbing ones).
Another is that the ^ notation forces the low level tools to follow

I don't know if it is a clever idea but...

We could use the git-name-rev method:

$git log a...b
commit sha1 (a)
....

commit sha1 (a^)
....

commit sha1 (b^)
....

commit sha1 (b)
....

and without this when on both branches.

Santi
-

[ message continues ]

Please, add this:

diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 617d022..a792323 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -260,7 +260,7 @@ get_ref_for_remote_branch (){
 	remotes)
 		ref=$(sed -ne '/^Pull: */{
 				s///p
-			}' "$GIT_DIR/remotes/$1" | grep "$2:")
+			}' "$GIT_DIR/remotes/$1" | grep "^$2:")
 		expr "z$ref" : 'z[^:]*:\(.*\)'
 		;;
 	*)
-

[ message continues ]