From: "Shawn O. Pearce" <spearce@spearce.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.
Date: Thu, 28 Dec 2006 02:35:17 -0500 [thread overview]
Message-ID: <20061228073517.GG17867@spearce.org> (raw)
In-Reply-To: <9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org>
Users who merge frequently from remote repositories tend to prefer
`git-pull .` over `git-merge` for local merges, as the pull interface
is then consistent with how the user performs merges from remote
repositories.
Unfortunately `git-pull .` has a (small) amount of overhead on top of
`git-merge` as it needs to first invoke git-fetch to prepare the
FETCH_HEAD file. However we can easily detect this special case
of a local merge and jump directly into git-merge, bypassing that
overhead.
This change also allows users of `git-pull .` to take advantage of
the change made in commit e0ec1819, where git-merge uses the local
branch name in conflict hunks if it is invoked as a porcelain,
rather than as a plumbing.
Users may also now use `git-pull . foo~3` to merge the early part
of branch foo. This was not previously possible as git-fetch does
not know how to fetch foo~3 from a repository.
Unfortunately we cannot use this git-fetch bypass if the user is
also updating some sort of tracking branch in the local repository
as part of the pull from the local repository. This however is a
rather crazy usage of `git-pull .`, but we used to support it, so
we issue a silly warning message and use the older-style git-fetch
path to continue supporting it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-pull.sh | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 28d0819..8c94fef 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -45,6 +45,33 @@ do
shift
done
+if test "X$1" = X.
+then
+ # We are merging from this repository. We can avoid fetch
+ # and go right into merge if the user isn't doing something
+ # odd like asking us to also update tracking branches in
+ # this repository as part of the pull. Yeah, they probably
+ # shouldn't do that - but we allowed it in the past...
+ #
+ direct_merge=1
+ for remote
+ do
+ case "$remote" in
+ *:*) direct_merge=0; break;;
+ esac
+ done
+ if test $direct_merge = 1
+ then
+ shift
+ exec git-merge \
+ $no_summary $no_commit $squash $strategy_args \
+ "$@"
+ else
+ echo >&2 "Clever... Updating tracking branch while pulling from yourself."
+ echo >&2
+ fi
+fi
+
orig_head=$(git-rev-parse --verify HEAD 2>/dev/null)
git-fetch --update-head-ok "$@" || exit 1
--
1.4.4.3.gd2e4
next prev parent reply other threads:[~2006-12-28 7:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org>
2006-12-28 7:34 ` [PATCH 2/11] Honor GIT_REFLOG_ACTION in git-rebase Shawn O. Pearce
2006-12-28 7:34 ` [PATCH 3/11] Use branch names in 'git-rebase -m' conflict hunks Shawn O. Pearce
2006-12-28 7:35 ` [PATCH 4/11] Ensure `git-pull` fails if `git-merge` fails Shawn O. Pearce
2006-12-28 7:35 ` [PATCH 5/11] Honor pull.{twohead,octopus} in git-merge Shawn O. Pearce
2006-12-28 7:35 ` [PATCH 6/11] Allow git-merge to select the default strategy Shawn O. Pearce
2006-12-28 7:35 ` Shawn O. Pearce [this message]
2006-12-28 8:08 ` [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible Junio C Hamano
2006-12-28 8:17 ` Shawn Pearce
2006-12-28 9:35 ` Junio C Hamano
2006-12-28 7:35 ` [PATCH 8/11] Move better_branch_name above get_ref in merge-recursive Shawn O. Pearce
2006-12-28 7:35 ` [PATCH 9/11] Allow merging bare trees " Shawn O. Pearce
2006-12-28 8:08 ` Junio C Hamano
2006-12-28 7:35 ` [PATCH 10/11] Use merge-recursive in git-am -3 Shawn O. Pearce
2006-12-28 7:35 ` [PATCH 11/11] Improve merge performance by avoiding in-index merges Shawn O. Pearce
2006-12-28 8:08 ` Junio C Hamano
2006-12-28 8:24 ` Shawn Pearce
2006-12-29 17:44 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061228073517.GG17867@spearce.org \
--to=spearce@spearce.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.