* Re: [PATCH 11/11] Improve merge performance by avoiding in-index merges.
From: Junio C Hamano @ 2006-12-28 8:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061228073534.GK17867@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> For a really trivial merge which can be handled entirely by
> `read-tree -m -u`, skipping the read-tree and just going directly
> into merge-recursive saves on average 50 ms on my PowerPC G4 system.
> May sound odd, but it does appear to be true.
This sounds awfully attractive yet disruptive. Should be cooked
in 'next' for at least two weeks, maybe even longer to verify
that performance figure holds for everybody.
Also I think you need to make sure running merge-recursive
upfront offers the same safety as the code you are removing then
running it, as I vaguely recall its checking for local changes
were slightly looser.
^ permalink raw reply
* Re: [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.
From: Junio C Hamano @ 2006-12-28 8:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061228073517.GG17867@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> 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.
I personally think this is not an improvement, but rather a new
source of confusion. If the user wants a local merge, there is
'git-merge'. And the distinction between the commands makes it
clear that local merge can merge any commits exactly because
they are available locally, while remote fetch+merge needs to
choose from what the remote side offers so not arbitrary commits
like foo@{3.days.ago} cannot be pulled.
Also I thought there was a configuration variable that talks
about "remote = ." (didn't I merge that patch -- I do not
remember offhand) and I wonder how that interacts with this
change.
How much performance gain are we talking about here?
^ permalink raw reply
* Re: [PATCH 9/11] Allow merging bare trees in merge-recursive.
From: Junio C Hamano @ 2006-12-28 8:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061228073523.GI17867@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> To support wider use cases, such as from within `git am -3`, the
> merge-recursive utility needs to accept not just commit-ish but
> also tree-ish as arguments on its command line.
Yes, this was one of the things I did not like about
merge-recursive (I think the original Python one may have
accepted three trees but I am not sure --- it's so looong ago).
^ permalink raw reply
* Re: Why git-merge-resolve in git-am?
From: Shawn Pearce @ 2006-12-28 7:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virfw3gb2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Good reasons, but all are strictly historical. So there's actually
> > no technical reason we can't use merge-recursive here in git-am.
>
> A very early version of recursive was unusable (it did not pay
> attention to the merge base the caller gave it and tried to
> always compute it by itself), but that was fixed sometime later.
>
> I do not recall offhand C version still has that fix (I think it
> does but you should double check); as long ias it honors the
> merge base the caller computed, it should be Ok to replace
> resolve with recursive. Go wild.
I checked. It does use the merge base supplied by the caller,
but only if the caller supplies only one merge base. Otherwise it
computes its own.
This isn't a problem for git-am as we only supply one merge base.
What was a problem was git-am supplies trees, not commits, and the
code internally uses commits. I fixed that in patch 9/11 'Allow
merging bare trees' in my recent series.
--
Shawn.
^ permalink raw reply
* [PATCH 11/11] Improve merge performance by avoiding in-index merges.
From: Shawn O. Pearce @ 2006-12-28 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org>
In the early days of Git we performed a 3-way read-tree based merge
before attempting any specific merge strategy, as our core merge
strategies of merge-one-file and merge-recursive were slower script
based programs which took far longer to execute. This was a good
performance optimization in the past, as most merges were able to
be handled strictly by `read-tree -m -u`.
However now that merge-recursive is a C based program which performs
a full 3-way read-tree before it starts running we need to pay the
cost of the 3-way read-tree twice if we have to do any sort of file
level merging. This slows down some classes of simple merges which
`read-tree -m -u` could not handle but which merge-recursive does
automatically.
For a really trivial merge which can be handled entirely by
`read-tree -m -u`, skipping the read-tree and just going directly
into merge-recursive saves on average 50 ms on my PowerPC G4 system.
May sound odd, but it does appear to be true.
In a really simple merge which needs to use merge-recursive to handle
a file that was modified on both branches, skipping the read-tree
in git-merge saves on average almost 100 ms (on the same PowerPC G4)
as we avoid doing some work twice.
We only avoid `read-tree -m -u` if the only strategy to use is
merge-recursive, as not all merge strategies perform as well as
merge-recursive does.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-merge.sh | 39 ++++++++++++++++++++++-----------------
1 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index a8f673e..74d4fb0 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -341,23 +341,28 @@ f,*)
?,1,*,)
# We are not doing octopus, not fast forward, and have only
# one common. See if it is really trivial.
- git var GIT_COMMITTER_IDENT >/dev/null || exit
-
- echo "Trying really trivial in-index merge..."
- git-update-index --refresh 2>/dev/null
- if git-read-tree --trivial -m -u -v $common $head "$1" &&
- result_tree=$(git-write-tree)
- then
- echo "Wonderful."
- result_commit=$(
- echo "$merge_msg" |
- git-commit-tree $result_tree -p HEAD -p "$1"
- ) || exit
- finish "$result_commit" "In-index merge"
- dropsave
- exit 0
- fi
- echo "Nope."
+ case "$use_strategies" in
+ recursive|'recursive '|recur|'recur ')
+ : run merge later
+ ;;
+ *)
+ git var GIT_COMMITTER_IDENT >/dev/null || exit
+ echo "Trying really trivial in-index merge..."
+ git-update-index --refresh 2>/dev/null
+ if git-read-tree --trivial -m -u -v $common $head "$1" &&
+ result_tree=$(git-write-tree)
+ then
+ echo "Wonderful."
+ result_commit=$(
+ echo "$merge_msg" |
+ git-commit-tree $result_tree -p HEAD -p "$1"
+ ) || exit
+ finish "$result_commit" "In-index merge"
+ dropsave
+ exit 0
+ fi
+ echo "Nope."
+ esac
;;
*)
# An octopus. If we can reach all the remote we are up to date.
--
1.4.4.3.gd2e4
^ permalink raw reply related
* [PATCH 10/11] Use merge-recursive in git-am -3.
From: Shawn O. Pearce @ 2006-12-28 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org>
By switching from merge-resolve to merge-recursive in the 3-way
fallback behavior of git-am we gain a few benefits:
* renames are automatically handled, like in rebase -m;
* conflict hunks can reference the patch name;
* its faster on Cygwin (less forks).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-am.sh | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index c3bbd78..7c0bb60 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -88,10 +88,12 @@ It does not apply to blobs recorded in its index."
# This is not so wrong. Depending on which base we picked,
# orig_tree may be wildly different from ours, but his_tree
# has the same set of wildly different changes in parts the
- # patch did not touch, so resolve ends up canceling them,
+ # patch did not touch, so recursive ends up canceling them,
# saying that we reverted all those changes.
- git-merge-resolve $orig_tree -- HEAD $his_tree || {
+ eval GITHEAD_$his_tree='"$SUBJECT"'
+ export GITHEAD_$his_tree
+ git-merge-recursive $orig_tree -- HEAD $his_tree || {
if test -d "$GIT_DIR/rr-cache"
then
git-rerere
@@ -99,6 +101,7 @@ It does not apply to blobs recorded in its index."
echo Failed to merge in the changes.
exit 1
}
+ unset GITHEAD_$his_tree
}
prec=4
--
1.4.4.3.gd2e4
^ permalink raw reply related
* [PATCH 9/11] Allow merging bare trees in merge-recursive.
From: Shawn O. Pearce @ 2006-12-28 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org>
To support wider use cases, such as from within `git am -3`, the
merge-recursive utility needs to accept not just commit-ish but
also tree-ish as arguments on its command line.
If given a tree-ish then merge-recursive will create a virtual commit
wrapping it, with the subject of the commit set to the best name we
can derive for that tree, which is either the command line string
(probably the SHA1), or whatever string appears in GITHEAD_*.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
merge-recursive.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 1c84ed7..bac16f5 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1268,6 +1268,9 @@ static struct commit *get_ref(const char *ref)
if (get_sha1(ref, sha1))
die("Could not resolve ref '%s'", ref);
object = deref_tag(parse_object(sha1), ref, strlen(ref));
+ if (object->type == OBJ_TREE)
+ return make_virtual_commit((struct tree*)object,
+ better_branch_name(ref));
if (object->type != OBJ_COMMIT)
return NULL;
if (parse_commit((struct commit *)object))
--
1.4.4.3.gd2e4
^ permalink raw reply related
* [PATCH 8/11] Move better_branch_name above get_ref in merge-recursive.
From: Shawn O. Pearce @ 2006-12-28 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org>
To permit the get_ref function to use the static better_branch_name
function to generate a string on demand I'm moving it up earlier.
The actual logic was not affected in this change.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
merge-recursive.c | 24 ++++++++++++------------
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index ca4f19e..1c84ed7 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1248,6 +1248,18 @@ static int merge(struct commit *h1,
return clean;
}
+static const char *better_branch_name(const char *branch)
+{
+ static char githead_env[8 + 40 + 1];
+ char *name;
+
+ if (strlen(branch) != 40)
+ return branch;
+ sprintf(githead_env, "GITHEAD_%s", branch);
+ name = getenv(githead_env);
+ return name ? name : branch;
+}
+
static struct commit *get_ref(const char *ref)
{
unsigned char sha1[20];
@@ -1263,18 +1275,6 @@ static struct commit *get_ref(const char *ref)
return (struct commit *)object;
}
-static const char *better_branch_name(const char *branch)
-{
- static char githead_env[8 + 40 + 1];
- char *name;
-
- if (strlen(branch) != 40)
- return branch;
- sprintf(githead_env, "GITHEAD_%s", branch);
- name = getenv(githead_env);
- return name ? name : branch;
-}
-
int main(int argc, char *argv[])
{
static const char *bases[2];
--
1.4.4.3.gd2e4
^ permalink raw reply related
* [PATCH 7/11] Avoid git-fetch in `git-pull .` when possible.
From: Shawn O. Pearce @ 2006-12-28 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
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
^ permalink raw reply related
* [PATCH 6/11] Allow git-merge to select the default strategy.
From: Shawn O. Pearce @ 2006-12-28 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org>
Now that git-merge knows how to use the pull.{twohead,octopus}
configuration options to select the default merge strategy there
is no reason for git-pull to do the same immediately prior to
invoking git-merge.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-pull.sh | 18 ------------------
1 files changed, 0 insertions(+), 18 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 2725946..28d0819 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -90,18 +90,6 @@ case "$merge_head" in
echo >&2 "Cannot merge multiple branches into empty head"
exit 1
fi
- var=`git-repo-config --get pull.octopus`
- if test -n "$var"
- then
- strategy_default_args="-s $var"
- fi
- ;;
-*)
- var=`git-repo-config --get pull.twohead`
- if test -n "$var"
- then
- strategy_default_args="-s $var"
- fi
;;
esac
@@ -112,12 +100,6 @@ then
exit
fi
-case "$strategy_args" in
-'')
- strategy_args=$strategy_default_args
- ;;
-esac
-
merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
exec git-merge $no_summary $no_commit $squash $strategy_args \
"$merge_name" HEAD $merge_head
--
1.4.4.3.gd2e4
^ permalink raw reply related
* [PATCH 5/11] Honor pull.{twohead,octopus} in git-merge.
From: Shawn O. Pearce @ 2006-12-28 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org>
If git-merge is invoked without a strategy argument it is probably
being run as a porcelain-ish command directly and is not being run
from within git-pull. However we still should honor whatever merge
strategy the user may have selected in their configuration, just as
`git-pull .` would have.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-merge.sh | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index c7e033c..a8f673e 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -272,9 +272,21 @@ case "$use_strategies" in
'')
case "$#" in
1)
- use_strategies="$default_twohead_strategies" ;;
+ var="`git-repo-config --get pull.twohead`"
+ if test -n "$var"
+ then
+ use_strategies="$var"
+ else
+ use_strategies="$default_twohead_strategies"
+ fi ;;
*)
- use_strategies="$default_octopus_strategies" ;;
+ var="`git-repo-config --get pull.octopus`"
+ if test -n "$var"
+ then
+ use_strategies="$var"
+ else
+ use_strategies="$default_octopus_strategies"
+ fi ;;
esac
;;
esac
--
1.4.4.3.gd2e4
^ permalink raw reply related
* [PATCH 4/11] Ensure `git-pull` fails if `git-merge` fails.
From: Shawn O. Pearce @ 2006-12-28 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org>
If git-merge exits with a non-zero exit status so should git-pull.
This way the caller of git-pull knows the task did not complete
successfully simply by checking the process exit status.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-pull.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index fd4ffb8..2725946 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -119,5 +119,5 @@ case "$strategy_args" in
esac
merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
-git-merge $no_summary $no_commit $squash $strategy_args \
+exec git-merge $no_summary $no_commit $squash $strategy_args \
"$merge_name" HEAD $merge_head
--
1.4.4.3.gd2e4
^ permalink raw reply related
* [PATCH 3/11] Use branch names in 'git-rebase -m' conflict hunks.
From: Shawn O. Pearce @ 2006-12-28 7:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org>
If a three-way merge in git-rebase generates a conflict then we
should take advantage of git-merge-recursive's ability to include
the branch name of each side of the conflict hunk by setting the
GITHEAD_* environment variables.
In the case of rebase there aren't really two clear branches; we
have the branch we are rebasing onto, and we have the branch we are
currently rebasing. Since most conflicts will be arising between
the user's current branch and the branch they are rebasing onto
we assume the stuff that isn't in the current commit is the "onto"
branch and the stuff in the current commit is the "current" branch.
This assumption may however come up wrong if the user resolves one
conflict in such a way that it conflicts again on a future commit
also being rebased. In this case the user's prior resolution will
appear to be in the "onto" part of the hunk.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-rebase.sh | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 5c7c4a6..828c59c 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -81,10 +81,18 @@ continue_merge () {
call_merge () {
cmt="$(cat $dotest/cmt.$1)"
echo "$cmt" > "$dotest/current"
- git-merge-$strategy "$cmt^" -- HEAD "$cmt"
+ hd=$(git-rev-parse --verify HEAD)
+ cmt_name=$(git-symbolic-ref HEAD)
+ msgnum=$(cat $dotest/msgnum)
+ end=$(cat $dotest/end)
+ eval GITHEAD_$cmt='"${cmt_name##refs/heads/}~$(($end - $msgnum))"'
+ eval GITHEAD_$hd='"$(cat $dotest/onto_name)"'
+ export GITHEAD_$cmt GITHEAD_$hd
+ git-merge-$strategy "$cmt^" -- "$hd" "$cmt"
rv=$?
case "$rv" in
0)
+ unset GITHEAD_$cmt GITHEAD_$hd
return
;;
1)
@@ -314,6 +322,7 @@ fi
mkdir -p "$dotest"
echo "$onto" > "$dotest/onto"
+echo "$onto_name" > "$dotest/onto_name"
prev_head=`git-rev-parse HEAD^0`
echo "$prev_head" > "$dotest/prev_head"
--
1.4.4.3.gd2e4
^ permalink raw reply related
* [PATCH 2/11] Honor GIT_REFLOG_ACTION in git-rebase.
From: Shawn O. Pearce @ 2006-12-28 7:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <9847899e4ba836980dbfed6d0ea1c82f31f21456.1167290864.git.spearce@spearce.org>
To help correctly log actions caused by porcelain which invoke
git-reset directly we should honor the setting of GIT_REFLOG_ACTION
which we inherited from our caller.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-reset.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-reset.sh b/git-reset.sh
index 2379db0..a969370 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -5,6 +5,7 @@
USAGE='[--mixed | --soft | --hard] [<commit-ish>] [ [--] <paths>...]'
SUBDIRECTORY_OK=Yes
. git-sh-setup
+set_reflog_action "reset $*"
update= reset_type=--mixed
unset rev
@@ -81,7 +82,7 @@ then
else
rm -f "$GIT_DIR/ORIG_HEAD"
fi
-git-update-ref -m "reset $reset_type $*" HEAD "$rev"
+git-update-ref -m "$GIT_REFLOG_ACTION" HEAD "$rev"
update_ref_status=$?
case "$reset_type" in
--
1.4.4.3.gd2e4
^ permalink raw reply related
* [PATCH 0/11] Misc. pull/merge/am improvements
From: Shawn Pearce @ 2006-12-28 7:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This series of patches is a group of minor interface and performance
improvements for am/pull/rebase.
1 Use GIT_REFLOG_ACTION environment variable instead.
2 Honor GIT_REFLOG_ACTION in git-rebase.
These two replace my prior 2 patch series in the same area.
3 Use branch names in 'git-rebase -m' conflict hunks.
This is a UI improvement to show better conflicts out of rebase.
4 Ensure `git-pull` fails if `git-merge` fails.
Trivial fix to make git-pull more friendly to other scripts.
5 Honor pull.{twohead,octopus} in git-merge.
6 Allow git-merge to select the default strategy.
This moves the default merge strategy selection into git-merge,
making it part of that tool rather than git-pull. This makes
it possible to get the same behavior from `git merge foo` as
you already get from `git pull . foo`.
7 Avoid git-fetch in `git-pull .` when possible.
This is a performance improvement for pull, and offers some
other nice benefits (see patch).
8 Move better_branch_name above get_ref in merge-recursive.
9 Allow merging bare trees in merge-recursive.
10 Use merge-recursive in git-am -3.
These three switch to merge-recursive in git-am, see patch 10's
message for the benefits.
11 Improve merge performance by avoiding in-index merges.
This is a general performance improvement for all two-headed
merges which might use merge-recursive.
I'd like to see these appear in v1.5.0, but we're getting close to
the release so I can understand if they get delayed.
--
Shawn.
^ permalink raw reply
* [PATCH 1/11] Use GIT_REFLOG_ACTION environment variable instead.
From: Shawn O. Pearce @ 2006-12-28 7:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio rightly pointed out that the --reflog-action parameter
was starting to get out of control, as most porcelain code
needed to hand it to other porcelain and plumbing alike to
ensure the reflog contained the top-level user action and
not the lower-level actions it invoked.
At Junio's suggestion we are introducing the new set_reflog_action
function to all shell scripts, allowing them to declare early on
what their default reflog name should be, but this setting only
takes effect if the caller has not already set the GIT_REFLOG_ACTION
environment variable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/git-merge.txt | 6 ------
git-am.sh | 7 ++-----
git-fetch.sh | 21 ++++++++-------------
git-merge.sh | 13 +++++--------
git-pull.sh | 6 +++---
git-rebase.sh | 10 ++++------
git-sh-setup.sh | 8 ++++++++
7 files changed, 30 insertions(+), 41 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index e2954aa..0f79665 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -10,7 +10,6 @@ SYNOPSIS
--------
[verse]
'git-merge' [-n] [--no-commit] [--squash] [-s <strategy>]...
- [--reflog-action=<action>]
-m=<msg> <remote> <remote>...
DESCRIPTION
@@ -37,11 +36,6 @@ include::merge-options.txt[]
least one <remote>. Specifying more than one <remote>
obviously means you are trying an Octopus.
---reflog-action=<action>::
- This is used internally when `git-pull` calls this command
- to record that the merge was created by `pull` command
- in the `ref-log` entry that results from the merge.
-
include::merge-strategies.txt[]
diff --git a/git-am.sh b/git-am.sh
index 0126a77..c3bbd78 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -6,6 +6,7 @@ USAGE='[--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way]
[--interactive] [--whitespace=<option>] <mbox>...
or, when resuming [--skip | --resolved]'
. git-sh-setup
+set_reflog_action am
git var GIT_COMMITTER_IDENT >/dev/null || exit
@@ -101,7 +102,6 @@ It does not apply to blobs recorded in its index."
}
prec=4
-rloga=am
dotest=.dotest sign= utf8= keep= skip= interactive= resolved= binary= ws= resolvemsg=
while case "$#" in 0) break;; esac
@@ -141,9 +141,6 @@ do
--resolvemsg=*)
resolvemsg=$(echo "$1" | sed -e "s/^--resolvemsg=//"); shift ;;
- --reflog-action=*)
- rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'`; shift ;;
-
--)
shift; break ;;
-*)
@@ -452,7 +449,7 @@ do
parent=$(git-rev-parse --verify HEAD) &&
commit=$(git-commit-tree $tree -p $parent <"$dotest/final-commit") &&
echo Committed: $commit &&
- git-update-ref -m "$rloga: $SUBJECT" HEAD $commit $parent ||
+ git-update-ref -m "$GIT_REFLOG_ACTION: $SUBJECT" HEAD $commit $parent ||
stop_here $this
if test -x "$GIT_DIR"/hooks/post-applypatch
diff --git a/git-fetch.sh b/git-fetch.sh
index 5f31605..8bd11f8 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -4,6 +4,8 @@
USAGE='<fetch-options> <repository> <refspec>...'
SUBDIRECTORY_OK=Yes
. git-sh-setup
+set_reflog_action "fetch $*"
+
TOP=$(git-rev-parse --show-cdup)
if test ! -z "$TOP"
then
@@ -17,7 +19,6 @@ LF='
'
IFS="$LF"
-rloga=fetch
no_tags=
tags=
append=
@@ -60,9 +61,6 @@ do
-k|--k|--ke|--kee|--keep)
keep='-k -k'
;;
- --reflog-action=*)
- rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'`
- ;;
--depth=*)
shallow_depth="--depth=`expr "z$1" : 'z-[^=]*=\(.*\)'`"
;;
@@ -94,9 +92,6 @@ refs=
rref=
rsync_slurped_objects=
-rloga="$rloga $remote_nick"
-test "$remote_nick" = "$remote" || rloga="$rloga $remote"
-
if test "" = "$append"
then
: >"$GIT_DIR/FETCH_HEAD"
@@ -180,12 +175,12 @@ update_local_ref () {
else
echo >&2 "* $1: updating with $3"
echo >&2 " $label_: $newshort_"
- git-update-ref -m "$rloga: updating tag" "$1" "$2"
+ git-update-ref -m "$GIT_REFLOG_ACTION: updating tag" "$1" "$2"
fi
else
echo >&2 "* $1: storing $3"
echo >&2 " $label_: $newshort_"
- git-update-ref -m "$rloga: storing tag" "$1" "$2"
+ git-update-ref -m "$GIT_REFLOG_ACTION: storing tag" "$1" "$2"
fi
;;
@@ -208,7 +203,7 @@ update_local_ref () {
*,$local)
echo >&2 "* $1: fast forward to $3"
echo >&2 " old..new: $oldshort_..$newshort_"
- git-update-ref -m "$rloga: fast-forward" "$1" "$2" "$local"
+ git-update-ref -m "$GIT_REFLOG_ACTION: fast-forward" "$1" "$2" "$local"
;;
*)
false
@@ -218,7 +213,7 @@ update_local_ref () {
*,t,*)
echo >&2 "* $1: forcing update to non-fast forward $3"
echo >&2 " old...new: $oldshort_...$newshort_"
- git-update-ref -m "$rloga: forced-update" "$1" "$2" "$local"
+ git-update-ref -m "$GIT_REFLOG_ACTION: forced-update" "$1" "$2" "$local"
;;
*)
echo >&2 "* $1: not updating to non-fast forward $3"
@@ -230,7 +225,7 @@ update_local_ref () {
else
echo >&2 "* $1: storing $3"
echo >&2 " $label_: $newshort_"
- git-update-ref -m "$rloga: storing head" "$1" "$2"
+ git-update-ref -m "$GIT_REFLOG_ACTION: storing head" "$1" "$2"
fi
;;
esac
@@ -479,7 +474,7 @@ case "$orig_head" in
if test "$curr_head" != "$orig_head"
then
git-update-ref \
- -m "$rloga: Undoing incorrectly fetched HEAD." \
+ -m "$GIT_REFLOG_ACTION: Undoing incorrectly fetched HEAD." \
HEAD "$orig_head"
die "Cannot fetch into the current branch."
fi
diff --git a/git-merge.sh b/git-merge.sh
index 022d01e..c7e033c 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -3,9 +3,10 @@
# Copyright (c) 2005 Junio C Hamano
#
-USAGE='[-n] [--no-commit] [--squash] [-s <strategy>] [--reflog-action=<action>] [-m=<merge-message>] <commit>+'
+USAGE='[-n] [--no-commit] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
. git-sh-setup
+set_reflog_action "merge $*"
LF='
'
@@ -57,10 +58,10 @@ squash_message () {
finish () {
if test '' = "$2"
then
- rlogm="$rloga"
+ rlogm="$GIT_REFLOG_ACTION"
else
echo "$2"
- rlogm="$rloga: $2"
+ rlogm="$GIT_REFLOG_ACTION: $2"
fi
case "$squash" in
t)
@@ -154,7 +155,7 @@ merge_name () {
case "$#" in 0) usage ;; esac
-rloga= have_message=
+have_message=
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -184,9 +185,6 @@ do
die "available strategies are: $all_strategies" ;;
esac
;;
- --reflog-action=*)
- rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'`
- ;;
-m=*|--m=*|--me=*|--mes=*|--mess=*|--messa=*|--messag=*|--message=*)
merge_msg=`expr "z$1" : 'z-[^=]*=\(.*\)'`
have_message=t
@@ -258,7 +256,6 @@ head=$(git-rev-parse --verify "$head_arg"^0) || usage
# All the rest are remote heads
test "$#" = 0 && usage ;# we need at least one remote head.
-test "$rloga" = '' && rloga="merge: $@"
remoteheads=
for remote
diff --git a/git-pull.sh b/git-pull.sh
index 1703091..fd4ffb8 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -7,6 +7,7 @@
USAGE='[-n | --no-summary] [--no-commit] [-s strategy]... [<fetch-options>] <repo> <head>...'
LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'
. git-sh-setup
+set_reflog_action "pull $*"
strategy_args= no_summary= no_commit= squash=
while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
@@ -45,7 +46,7 @@ do
done
orig_head=$(git-rev-parse --verify HEAD 2>/dev/null)
-git-fetch --update-head-ok --reflog-action=pull "$@" || exit 1
+git-fetch --update-head-ok "$@" || exit 1
curr_head=$(git-rev-parse --verify HEAD 2>/dev/null)
if test "$curr_head" != "$orig_head"
@@ -118,6 +119,5 @@ case "$strategy_args" in
esac
merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
-git-merge "--reflog-action=pull $*" \
- $no_summary $no_commit $squash $strategy_args \
+git-merge $no_summary $no_commit $squash $strategy_args \
"$merge_name" HEAD $merge_head
diff --git a/git-rebase.sh b/git-rebase.sh
index ece3142..5c7c4a6 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -28,6 +28,7 @@ Example: git-rebase master~1 topic
D---E---F---G master D---E---F---G master
'
. git-sh-setup
+set_reflog_action rebase
RESOLVEMSG="
When you have resolved this problem run \"git rebase --continue\".
@@ -132,8 +133,7 @@ do
finish_rb_merge
exit
fi
- git am --resolved --3way --resolvemsg="$RESOLVEMSG" \
- --reflog-action=rebase
+ git am --resolved --3way --resolvemsg="$RESOLVEMSG"
exit
;;
--skip)
@@ -156,8 +156,7 @@ do
finish_rb_merge
exit
fi
- git am -3 --skip --resolvemsg="$RESOLVEMSG" \
- --reflog-action=rebase
+ git am -3 --skip --resolvemsg="$RESOLVEMSG"
exit
;;
--abort)
@@ -306,8 +305,7 @@ fi
if test -z "$do_merge"
then
git-format-patch -k --stdout --full-index --ignore-if-in-upstream "$upstream"..ORIG_HEAD |
- git am --binary -3 -k --resolvemsg="$RESOLVEMSG" \
- --reflog-action=rebase
+ git am --binary -3 -k --resolvemsg="$RESOLVEMSG"
exit $?
fi
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 42f9b1c..87b939c 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -20,6 +20,14 @@ usage() {
die "Usage: $0 $USAGE"
}
+set_reflog_action() {
+ if [ -z "${GIT_REFLOG_ACTION:+set}" ]
+ then
+ GIT_REFLOG_ACTION="$*"
+ export GIT_REFLOG_ACTION
+ fi
+}
+
if [ -z "$LONG_USAGE" ]
then
LONG_USAGE="Usage: $0 $USAGE"
--
1.4.4.3.gd2e4
^ permalink raw reply related
* Re: [PATCH 1/2] Teach git-reset to let others override its reflog entry.
From: Shawn Pearce @ 2006-12-28 6:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslf0zgwp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > The new --reflog-action for git-reset behaves like the same option
> > to git-merge; it can be used by the caller to override the message
> > entry in the reflog and is intended to be used only when git-reset
> > is acting as plumbing, not porcelain.
>
> Honestly, I hate these --reflog-action options everywhere.
Me too. Yet I submit patches to add them. ;-)
> Then calls to "git-update-ref -m" could use the value of
> "$GIT_REFLOG_ACTION", without explicit --reflog-action=
> parameters and $rloga variables.
I agree. Your suggestion is way more elegant.
I have some more git-am/git-merge/git-pull/git-rebase patches
brewing; I'm finishing the commit message for the last in the
sequence. I'll update it to include your suggestion and try to
start cleaning up this --reflog-action mess, then ship the series
out to the list, including this mini 2 patch series you are
rejecting for good reason.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] Teach git-reset to let others override its reflog entry.
From: Junio C Hamano @ 2006-12-28 6:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061228014336.GA16790@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> The new --reflog-action for git-reset behaves like the same option
> to git-merge; it can be used by the caller to override the message
> entry in the reflog and is intended to be used only when git-reset
> is acting as plumbing, not porcelain.
Honestly, I hate these --reflog-action options everywhere.
I wonder if something like this would be easier to manage in the
longer run:
* In git-sh-setup.sh, have this shell function.
set_reflog_action () {
if test -z "${GIT_REFLOG_ACTION+set}"
then
GIT_REFLOG_ACTION="$*"
export GIT_REFLOG_ACTION
fi
}
* Begin git-reset.sh with something like this:
#!/bin/sh
. git-sh-setup
set_reflog_action "reset $*"
* Update Porcelain-ish commands that use git-reset in the same
way. For example, git-rebase could say:
#!/bin/sh
. git-sh-setup
set_reflog_action "rebase $*"
Then calls to "git-update-ref -m" could use the value of
"$GIT_REFLOG_ACTION", without explicit --reflog-action=
parameters and $rloga variables.
Hmm?
^ permalink raw reply
* Re: An early draft of v1.5.0 release notes (2nd ed)
From: Junio C Hamano @ 2006-12-28 5:54 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061228024719.GG16612@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> Shawn Pearce <spearce@spearce.org> writes:
>>
>> > The section is really for those who are upgrading from ancient
>> > versions, but the title of the section implies (at least to me)
>> > that these changes aren't something important.
>>
>> True. How about "Something important you should already know
>> but just in case" ;-)?
>
> Sure, that's more fun then my proposed text and does summarize the
> section better. Plus it reminds Git users that maybe they should
> track our releases a little bit more often than only on "major"
> version number increments. :-)
That was a tongue-in-cheek comment.
I consider git is still young and I have the right to gripe at
the list if something that has been cooking in 'next' without
anybody complaining causes a real breakage immediately after it
gets pushed out to 'master'. But for the rest of the world, git
has already matured enough that there is much less need to be on
the bleeding edge for the lack of something crucial in the last
released version.
And let's face it. Nobody has enough time to keep track of the
changes to all tools he uses, it is not unusual to skip a
handful of minor versions, and it is a norm to get surprised
after an upgrade of any tool because there was a major change in
a couple of releases back that he skipped. I do not have the
right to complain if the end users do not follow every minor
release or every issue of "What's in git.git" messages. Not
anymore.
So I'd like the introductory section to have more positive
spin. I tried rewording it and pushed it out to 'todo' branch.
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Junio C Hamano @ 2006-12-28 5:34 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061228030317.GA2154@localdomain>
Eric Wong <normalperson@yhbt.net> writes:
> Addendum:
>
> git-svn related changes:
Thanks.
^ permalink raw reply
* t9200-git-cvsexportcommit.sh failed on CYGWIN
From: SungHyun Nam @ 2006-12-28 3:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT
Hello,
Below is the test messages.
BTW, I hope I can define 'NO_CVS_TESTS' to skip this test.
Thanks,
namsh
$ ./t9200-git-cvsexportcommit.sh
Initialized empty Git repository in .git/
Created initial commit 15322570c631afb497138bc0c3d155f793535d35
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 empty
* ok 1: New file
* ok 2: Remove two files, add two and update two
* ok 3: Fail to change binary more than one generation old
* ok 4: Remove only binary files
* ok 5: Remove only a text file
* ok 6: New file with spaces in file name
* ok 7: Update file with spaces in file name
* FAIL 8: File with non-ascii file name
mkdir -p
Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö &&
echo Foo
>Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/gårdetsågårdet.txt
&&
git add
Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/gårdetsågårdet.txt
&&
cp ../test9200a.png
Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/gårdetsågårdet.png
&&
git add
Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/gårdetsågårdet.png
&&
git commit -a -m "Går det så går det" && \
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git-cvsexportcommit -v -c $id &&
test "$(echo $(sort
Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/CVS/Entries|cut
-d/ -f2,3,5))" = "gårdetsågårdet.png/1.1/-kb gårdetsågårdet.txt/1.1/"
)
* ok 9: Mismatching patch should fail
* ok 10: Retain execute bit
* failed 1 among 10 test(s)
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Eric Wong @ 2006-12-28 3:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvejx948y.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> ancient versions such as v1.1.6 or v1.2.0, and there are a
> handful "one-way-street upgrades" and quite a few user visible
> changes that already have happened before v1.4.4. Namely:
Addendum:
git-svn related changes:
- git-svn now requires the Perl SVN:: libraries, the
command-line backend was too slow and limited.
- the 'commit' command has been renamed to 'set-tree', and
'dcommit' is the recommended replacement for day-to-day
work.
--
Eric Wong
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Junio C Hamano @ 2006-12-28 2:58 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
In-Reply-To: <200612271206.kBRC6ke2004207@laptop13.inf.utfsm.cl>
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> This is still rough, but I think we have a pretty good idea what
>> will and what won't be in v1.5.0 by now, and end-of-year is a
>> good slow time to summarize what we have done.
>
> Could somebody please summarize how to "upgrade" a repository to the new
> layout? This has got my head spinning... and I'm /not/ cloning the
> various repos I've got here just to take advantage of the changes.
The old layout was to map remote branch $B to local tracking
branch .git/refs/heads/$B, unless $B == 'master' in which case
it was mapped to .git/refs/heads/origin (and I think we
discarded 'origin' at remote).
Each remote branch $B is tracked with .git/refs/remote/origin/$B
in the new layout.
And you will get something like this in your .git/config:
[remote "origin"]
url = git://git.kernel.org/pub/scm/.../torvalds/linux-2.6.git/
fetch = refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
The first section defines what the token 'origin' means when you
say "git pull origin" or "git fetch origin". remote.origin.url
defines the URL to fetch/pull from, and remote.origin.fetch
supplies the refspecs you omitted from the command line (fetch
everything from refs/heads/ hierarchy of remote and store them
in my refs/remotes/origin/ hierarchy).
The second section defines what happens when you say "git pull"
or "git fetch" while on your "master" branch. It tells that you
meant to say "git pull origin" or "git fetch origin" when you
omitted the URL argument from the command line. And because you
are also omitting the refspecs, remote.origin.fetch kicks in and
slurps all the branches from the remote side and stores them in
your refs/remotes/origin/ hierarchy. When the command was "git
pull", it also says the merge that follows the fetch is to merge
the 'master' branch at the remote side (which happens to be
copied to your remotes/origin/master only because you have
remote.origin.fetch) into your current branch (which is
"master", because this section is about what happens while you
are on your "master" branch).
So for an existing repository that does not use the separate
remotes layout, you can easily convert that by hand if you
wanted to by:
- Move tracking branches from refs/heads/* to
refs/remotes/origin/*,
- create the config section like the above in .git/config, and
- remove .git/remotes/origin when you are done.
^ permalink raw reply
* Re: An early draft of v1.5.0 release notes (2nd ed)
From: Shawn Pearce @ 2006-12-28 2:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejqk3fom.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > The section is really for those who are upgrading from ancient
> > versions, but the title of the section implies (at least to me)
> > that these changes aren't something important.
>
> True. How about "Something important you should already know
> but just in case" ;-)?
Sure, that's more fun then my proposed text and does summarize the
section better. Plus it reminds Git users that maybe they should
track our releases a little bit more often than only on "major"
version number increments. :-)
--
Shawn.
^ permalink raw reply
* Re: An early draft of v1.5.0 release notes (2nd ed)
From: Junio C Hamano @ 2006-12-28 2:41 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061228022855.GF16612@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> The section is really for those who are upgrading from ancient
> versions, but the title of the section implies (at least to me)
> that these changes aren't something important.
True. How about "Something important you should already know
but just in case" ;-)?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox