* [PATCH v2 26/31] rebase: remember strategy and strategy options
From: Martin von Zweigbergk @ 2011-02-06 18:43 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Christian Couder, Thomas Rast, Martin von Zweigbergk
In-Reply-To: <1297017841-20678-1-git-send-email-martin.von.zweigbergk@gmail.com>
When a rebase is resumed, interactive rebase remembers any merge
strategy passed when the rebase was initated. Make non-interactive
rebase remember any merge strategy as well. Also make non-interactive
rebase remember any merge strategy options.
To be able to resume a rebase that was initiated with an older version
of git (older than this commit), make sure not to expect the saved
option files to exist.
Test case idea taken from Junio's 71fc224 (t3402: test "rebase
-s<strategy> -X<opt>", 2010-11-11).
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
git-rebase--interactive.sh | 2 --
git-rebase.sh | 6 ++++++
t/t3418-rebase-continue.sh | 29 +++++++++++++++++++++++++++++
3 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f076a6e..5773b75 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -584,7 +584,6 @@ skip_unnecessary_picks () {
get_saved_options () {
test -d "$rewritten" && preserve_merges=t
- test -f "$state_dir"/strategy && strategy="$(cat "$state_dir"/strategy)"
test -f "$state_dir"/rebase-root && rebase_root=t
}
@@ -713,7 +712,6 @@ case "$rebase_root" in
*)
: >"$state_dir"/rebase-root ;;
esac
-test -z "$strategy" || echo "$strategy" > "$state_dir"/strategy
if test t = "$preserve_merges"
then
if test -z "$rebase_root"
diff --git a/git-rebase.sh b/git-rebase.sh
index 8a36e7a..f4ad7c1 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -81,6 +81,9 @@ read_basic_state () {
fi &&
GIT_QUIET=$(cat "$state_dir"/quiet) &&
test -f "$state_dir"/verbose && verbose=t
+ test -f "$state_dir"/strategy && strategy="$(cat "$state_dir"/strategy)"
+ test -f "$state_dir"/strategy_opts &&
+ strategy_opts="$(cat "$state_dir"/strategy_opts)"
}
write_basic_state () {
@@ -89,6 +92,9 @@ write_basic_state () {
echo "$orig_head" > "$state_dir"/orig-head &&
echo "$GIT_QUIET" > "$state_dir"/quiet &&
test t = "$verbose" && : > "$state_dir"/verbose
+ test -n "$strategy" && echo "$strategy" > "$state_dir"/strategy
+ test -n "$strategy_opts" && echo "$strategy_opts" > \
+ "$state_dir"/strategy_opts
}
output () {
diff --git a/t/t3418-rebase-continue.sh b/t/t3418-rebase-continue.sh
index 1d90191..5469546 100755
--- a/t/t3418-rebase-continue.sh
+++ b/t/t3418-rebase-continue.sh
@@ -45,4 +45,33 @@ test_expect_success 'rebase --continue can not be used with other options' '
test_must_fail git rebase --continue -v
'
+test_expect_success 'rebase --continue remembers merge strategy and options' '
+ rm -fr .git/rebase-* &&
+ git reset --hard commit-new-file-F2-on-topic-branch &&
+ test_commit "commit-new-file-F3-on-topic-branch" F3 32 &&
+ test_when_finished "rm -fr test-bin funny.was.run" &&
+ mkdir test-bin &&
+ cat >test-bin/git-merge-funny <<-EOF
+ #!$SHELL_PATH
+ case "\$1" in --opt) ;; *) exit 2 ;; esac
+ shift &&
+ >funny.was.run &&
+ exec git merge-recursive "\$@"
+ EOF
+ chmod +x test-bin/git-merge-funny &&
+ (
+ PATH=./test-bin:$PATH
+ test_must_fail git rebase -s funny -Xopt master topic
+ ) &&
+ test -f funny.was.run &&
+ rm funny.was.run &&
+ echo "Resolved" >F2 &&
+ git add F2 &&
+ (
+ PATH=./test-bin:$PATH
+ git rebase --continue
+ ) &&
+ test -f funny.was.run
+'
+
test_done
--
1.7.4.rc2.33.g8a14f
^ permalink raw reply related
* [PATCH v2 28/31] rebase -m: don't print exit code 2 when merge fails
From: Martin von Zweigbergk @ 2011-02-06 18:43 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Christian Couder, Thomas Rast, Martin von Zweigbergk
In-Reply-To: <1297017841-20678-1-git-send-email-martin.von.zweigbergk@gmail.com>
When the merge strategy fails, a message suggesting the user to try
another strategy is displayed. Remove the "$rv" (which is always equal
to "2" in this case) from that message.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
git-rebase--merge.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--merge.sh b/git-rebase--merge.sh
index eb0f7bc..26afc75 100644
--- a/git-rebase--merge.sh
+++ b/git-rebase--merge.sh
@@ -78,7 +78,7 @@ call_merge () {
die "$resolvemsg"
;;
2)
- echo "Strategy: $rv $strategy failed, try another" 1>&2
+ echo "Strategy: $strategy failed, try another" 1>&2
die "$resolvemsg"
;;
*)
--
1.7.4.rc2.33.g8a14f
^ permalink raw reply related
* [PATCH v2 29/31] git-rebase--am: remove unnecessary --3way option
From: Martin von Zweigbergk @ 2011-02-06 18:43 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Christian Couder, Thomas Rast, Martin von Zweigbergk
In-Reply-To: <1297017841-20678-1-git-send-email-martin.von.zweigbergk@gmail.com>
Since 22db240 (git-am: propagate --3way options as well, 2008-12-04),
the --3way has been propageted across failure, so it is since
pointless to pass it to git-am when resuming.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
git-rebase--am.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-rebase--am.sh b/git-rebase--am.sh
index c9604a6..c815a24 100644
--- a/git-rebase--am.sh
+++ b/git-rebase--am.sh
@@ -7,12 +7,12 @@
case "$action" in
continue)
- git am --resolved --3way --resolvemsg="$resolvemsg" &&
+ git am --resolved --resolvemsg="$resolvemsg" &&
move_to_original_branch
exit
;;
skip)
- git am --skip -3 --resolvemsg="$resolvemsg" &&
+ git am --skip --resolvemsg="$resolvemsg" &&
move_to_original_branch
exit
;;
--
1.7.4.rc2.33.g8a14f
^ permalink raw reply related
* [PATCH v2 25/31] rebase: remember verbose option
From: Martin von Zweigbergk @ 2011-02-06 18:43 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Christian Couder, Thomas Rast, Martin von Zweigbergk
In-Reply-To: <1297017841-20678-1-git-send-email-martin.von.zweigbergk@gmail.com>
Currently, only interactive rebase remembers the value of the '-v'
flag from the initial invocation. Make non-interactive rebase also
remember it.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
git-rebase--interactive.sh | 2 --
git-rebase.sh | 6 ++++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 437cc52..f076a6e 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -585,7 +585,6 @@ skip_unnecessary_picks () {
get_saved_options () {
test -d "$rewritten" && preserve_merges=t
test -f "$state_dir"/strategy && strategy="$(cat "$state_dir"/strategy)"
- test -f "$state_dir"/verbose && verbose=t
test -f "$state_dir"/rebase-root && rebase_root=t
}
@@ -715,7 +714,6 @@ case "$rebase_root" in
: >"$state_dir"/rebase-root ;;
esac
test -z "$strategy" || echo "$strategy" > "$state_dir"/strategy
-test t = "$verbose" && : > "$state_dir"/verbose
if test t = "$preserve_merges"
then
if test -z "$rebase_root"
diff --git a/git-rebase.sh b/git-rebase.sh
index 5a399aa..8a36e7a 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -79,14 +79,16 @@ read_basic_state () {
else
orig_head=$(cat "$state_dir"/head)
fi &&
- GIT_QUIET=$(cat "$state_dir"/quiet)
+ GIT_QUIET=$(cat "$state_dir"/quiet) &&
+ test -f "$state_dir"/verbose && verbose=t
}
write_basic_state () {
echo "$head_name" > "$state_dir"/head-name &&
echo "$onto" > "$state_dir"/onto &&
echo "$orig_head" > "$state_dir"/orig-head &&
- echo "$GIT_QUIET" > "$state_dir"/quiet
+ echo "$GIT_QUIET" > "$state_dir"/quiet &&
+ test t = "$verbose" && : > "$state_dir"/verbose
}
output () {
--
1.7.4.rc2.33.g8a14f
^ permalink raw reply related
* [PATCH v2 27/31] rebase -m: remember allow_rerere_autoupdate option
From: Martin von Zweigbergk @ 2011-02-06 18:43 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Christian Couder, Thomas Rast, Martin von Zweigbergk
In-Reply-To: <1297017841-20678-1-git-send-email-martin.von.zweigbergk@gmail.com>
If '--[no-]allow_rerere_autoupdate' is passed when 'git rebase -m' is
called and a merge conflict occurs, the flag will be forgotten for the
rest of the rebase process. Make rebase remember it by saving the
value.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
allow_rerere_autoupdate is only used by git-rebase--merge. Still ok to
write and read it here?
Should allow_rerere_autoupdate also be added to git_am_opt?
git-rebase.sh | 4 ++++
t/t3418-rebase-continue.sh | 21 +++++++++++++++++++++
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index f4ad7c1..be9ec2a 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -84,6 +84,8 @@ read_basic_state () {
test -f "$state_dir"/strategy && strategy="$(cat "$state_dir"/strategy)"
test -f "$state_dir"/strategy_opts &&
strategy_opts="$(cat "$state_dir"/strategy_opts)"
+ test -f "$state_dir"/allow_rerere_autoupdate &&
+ allow_rerere_autoupdate="$(cat "$state_dir"/allow_rerere_autoupdate)"
}
write_basic_state () {
@@ -95,6 +97,8 @@ write_basic_state () {
test -n "$strategy" && echo "$strategy" > "$state_dir"/strategy
test -n "$strategy_opts" && echo "$strategy_opts" > \
"$state_dir"/strategy_opts
+ test -n "$allow_rerere_autoupdate" && echo "$allow_rerere_autoupdate" > \
+ "$state_dir"/allow_rerere_autoupdate
}
output () {
diff --git a/t/t3418-rebase-continue.sh b/t/t3418-rebase-continue.sh
index 5469546..1e855cd 100755
--- a/t/t3418-rebase-continue.sh
+++ b/t/t3418-rebase-continue.sh
@@ -74,4 +74,25 @@ test_expect_success 'rebase --continue remembers merge strategy and options' '
test -f funny.was.run
'
+test_expect_success 'rebase --continue remembers --rerere-autoupdate' '
+ rm -fr .git/rebase-* &&
+ git reset --hard commit-new-file-F3-on-topic-branch &&
+ git checkout master
+ test_commit "commit-new-file-F3" F3 3 &&
+ git config rerere.enabled true &&
+ test_must_fail git rebase -m master topic &&
+ echo "Resolved" >F2 &&
+ git add F2 &&
+ test_must_fail git rebase --continue &&
+ echo "Resolved" >F3 &&
+ git add F3 &&
+ git rebase --continue &&
+ git reset --hard topic@{1} &&
+ test_must_fail git rebase -m --rerere-autoupdate master &&
+ test "$(cat F2)" = "Resolved" &&
+ test_must_fail git rebase --continue &&
+ test "$(cat F3)" = "Resolved" &&
+ git rebase --continue
+'
+
test_done
--
1.7.4.rc2.33.g8a14f
^ permalink raw reply related
* [PATCH v2 31/31] rebase -i: remove unnecessary state rebase-root
From: Martin von Zweigbergk @ 2011-02-06 18:44 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Christian Couder, Thomas Rast, Martin von Zweigbergk
In-Reply-To: <1297017841-20678-1-git-send-email-martin.von.zweigbergk@gmail.com>
Before calling 'git cherry-pick', interactive rebase currently checks
if we are rebasing from root (if --root was passed). If we are, the
'--ff' flag to 'git cherry-pick' is omitted. However, according to the
documentation for 'git cherry-pick --ff', "If the current HEAD is the
same as the parent of the cherry-picked commit, then a fast forward to
this commit will be performed.". This should never be the case when
rebasing from root, so it should not matter whether --ff is passed, so
simplify the code by removing the condition.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
git-rebase--interactive.sh | 19 -------------------
1 files changed, 0 insertions(+), 19 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index cf19bf5..6566d31 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -168,11 +168,6 @@ pick_one () {
output git rev-parse --verify $sha1 || die "Invalid commit name: $sha1"
test -d "$rewritten" &&
pick_one_preserving_merges "$@" && return
- if test -n "$rebase_root"
- then
- output git cherry-pick "$@"
- return
- fi
output git cherry-pick $ff "$@"
}
@@ -582,10 +577,6 @@ skip_unnecessary_picks () {
die "Could not skip unnecessary pick commands"
}
-get_saved_options () {
- test -f "$state_dir"/rebase-root && rebase_root=t
-}
-
# Rearrange the todo list that has both "pick sha1 msg" and
# "pick sha1 fixup!/squash! msg" appears in it so that the latter
# comes immediately after the former, and change "pick" to
@@ -649,8 +640,6 @@ rearrange_squash () {
case "$action" in
continue)
- get_saved_options
-
# do we have anything to commit?
if git diff-index --cached --quiet --ignore-submodules HEAD --
then
@@ -681,8 +670,6 @@ first and then run 'git rebase --continue' again."
do_rest
;;
skip)
- get_saved_options
-
git rerere clear
do_rest
@@ -705,12 +692,6 @@ mkdir "$state_dir" || die "Could not create temporary $state_dir"
: > "$state_dir"/interactive || die "Could not mark as interactive"
write_basic_state
-case "$rebase_root" in
-'')
- rm -f "$state_dir"/rebase-root ;;
-*)
- : >"$state_dir"/rebase-root ;;
-esac
if test t = "$preserve_merges"
then
if test -z "$rebase_root"
--
1.7.4.rc2.33.g8a14f
^ permalink raw reply related
* [PATCH v2 30/31] rebase -i: don't read unused variable preserve_merges
From: Martin von Zweigbergk @ 2011-02-06 18:43 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Christian Couder, Thomas Rast, Martin von Zweigbergk
In-Reply-To: <1297017841-20678-1-git-send-email-martin.von.zweigbergk@gmail.com>
Since 8e4a91b (rebase -i: remember the settings of -v, -s and -p when
interrupted, 2007-07-08), the variable preserve_merges (then called
PRESERVE_MERGES) was detected from the state saved in
$GIT_DIR/rebase-merge in order to be used when the rebase resumed, but
its value was never actually used. The variable's value was only used
when the rebase was initated.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
Changes since v1:
* Added back call to get_saved_options that I had removed by mistake
while reordering commits.
git-rebase--interactive.sh | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 5773b75..cf19bf5 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -583,7 +583,6 @@ skip_unnecessary_picks () {
}
get_saved_options () {
- test -d "$rewritten" && preserve_merges=t
test -f "$state_dir"/rebase-root && rebase_root=t
}
--
1.7.4.rc2.33.g8a14f
^ permalink raw reply related
* [PATCH v2 24/31] rebase: extract code for writing basic state
From: Martin von Zweigbergk @ 2011-02-06 18:43 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Christian Couder, Thomas Rast, Martin von Zweigbergk
In-Reply-To: <1297017841-20678-1-git-send-email-martin.von.zweigbergk@gmail.com>
Extract the code for writing the state to rebase-apply/ or
rebase-merge/ when a rebase is initiated. This will make it easier to
later make both interactive and non-interactive rebase remember the
options used.
Note that non-interactive rebase stores the sha1 of the original head
in a file called orig-head, while interactive rebase stores it in a
file called head. Change this by writing to orig-head in both
cases. When reading, try to read from orig-head. If that fails, read
from head instead. This protects users who upgraded git while they had
an ongoing interactive rebase, while still making it possible to
remove the code that reads from head at some point in the future.
Helped-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
Changes since v1:
* As suggested by Thomas, always write to orig-head file. When
reading, try orig-head first and fall back to reading from head.
git-rebase--am.sh | 6 +-----
git-rebase--interactive.sh | 5 +----
git-rebase--merge.sh | 5 +----
git-rebase.sh | 16 +++++++++++++---
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/git-rebase--am.sh b/git-rebase--am.sh
index 263987c..c9604a6 100644
--- a/git-rebase--am.sh
+++ b/git-rebase--am.sh
@@ -26,9 +26,5 @@ git format-patch -k --stdout --full-index --ignore-if-in-upstream \
git am $git_am_opt --rebasing --resolvemsg="$resolvemsg" &&
move_to_original_branch
ret=$?
-test 0 != $ret -a -d "$state_dir" &&
- echo $head_name > "$state_dir/head-name" &&
- echo $onto > "$state_dir/onto" &&
- echo $orig_head > "$state_dir/orig-head" &&
- echo "$GIT_QUIET" > "$state_dir/quiet"
+test 0 != $ret -a -d "$state_dir" && write_basic_state
exit $ret
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 4af0bc6..437cc52 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -707,16 +707,13 @@ orig_head=$(git rev-parse --verify HEAD) || die "No HEAD?"
mkdir "$state_dir" || die "Could not create temporary $state_dir"
: > "$state_dir"/interactive || die "Could not mark as interactive"
-echo "$head_name" > "$state_dir"/head-name
-
-echo $orig_head > "$state_dir"/head
+write_basic_state
case "$rebase_root" in
'')
rm -f "$state_dir"/rebase-root ;;
*)
: >"$state_dir"/rebase-root ;;
esac
-echo $onto > "$state_dir"/onto
test -z "$strategy" || echo "$strategy" > "$state_dir"/strategy
test t = "$verbose" && : > "$state_dir"/verbose
if test t = "$preserve_merges"
diff --git a/git-rebase--merge.sh b/git-rebase--merge.sh
index c04ce8a..eb0f7bc 100644
--- a/git-rebase--merge.sh
+++ b/git-rebase--merge.sh
@@ -127,10 +127,7 @@ esac
mkdir -p "$state_dir"
echo "$onto_name" > "$state_dir/onto_name"
-echo "$head_name" > "$state_dir/head-name"
-echo "$onto" > "$state_dir/onto"
-echo "$orig_head" > "$state_dir/orig-head"
-echo "$GIT_QUIET" > "$state_dir/quiet"
+write_basic_state
msgnum=0
for cmt in `git rev-list --reverse --no-merges "$revisions"`
diff --git a/git-rebase.sh b/git-rebase.sh
index 21bb027..5a399aa 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -70,15 +70,25 @@ test "$(git config --bool rebase.autosquash)" = "true" && autosquash=t
read_basic_state () {
head_name=$(cat "$state_dir"/head-name) &&
onto=$(cat "$state_dir"/onto) &&
- if test "$type" = interactive
+ # We always write to orig-head, but interactive rebase used to write to
+ # head. Fall back to reading from head to cover for the case that the
+ # user upgraded git with an ongoing interactive rebase.
+ if test -f "$state_dir"/orig-head
then
- orig_head=$(cat "$state_dir"/head)
- else
orig_head=$(cat "$state_dir"/orig-head)
+ else
+ orig_head=$(cat "$state_dir"/head)
fi &&
GIT_QUIET=$(cat "$state_dir"/quiet)
}
+write_basic_state () {
+ echo "$head_name" > "$state_dir"/head-name &&
+ echo "$onto" > "$state_dir"/onto &&
+ echo "$orig_head" > "$state_dir"/orig-head &&
+ echo "$GIT_QUIET" > "$state_dir"/quiet
+}
+
output () {
case "$verbose" in
'')
--
1.7.4.rc2.33.g8a14f
^ permalink raw reply related
* [PATCH v2 19/31] rebase: extract am code to new source file
From: Martin von Zweigbergk @ 2011-02-06 18:43 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Christian Couder, Thomas Rast, Martin von Zweigbergk
In-Reply-To: <1297017841-20678-1-git-send-email-martin.von.zweigbergk@gmail.com>
Extract the code for am-based rebase to git-rebase--am.sh.
Suggested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
.gitignore | 1 +
Makefile | 1 +
git-rebase--am.sh | 34 ++++++++++++++++++++++++++++++++++
git-rebase.sh | 31 ++-----------------------------
4 files changed, 38 insertions(+), 29 deletions(-)
create mode 100644 git-rebase--am.sh
diff --git a/.gitignore b/.gitignore
index a8b98b4..7aaf5c7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -102,6 +102,7 @@
/git-quiltimport
/git-read-tree
/git-rebase
+/git-rebase--am
/git-rebase--interactive
/git-rebase--merge
/git-receive-pack
diff --git a/Makefile b/Makefile
index f47550f..3cc60cb 100644
--- a/Makefile
+++ b/Makefile
@@ -369,6 +369,7 @@ SCRIPT_SH += git-merge-resolve.sh
SCRIPT_SH += git-mergetool.sh
SCRIPT_SH += git-pull.sh
SCRIPT_SH += git-quiltimport.sh
+SCRIPT_SH += git-rebase--am.sh
SCRIPT_SH += git-rebase--interactive.sh
SCRIPT_SH += git-rebase--merge.sh
SCRIPT_SH += git-rebase.sh
diff --git a/git-rebase--am.sh b/git-rebase--am.sh
new file mode 100644
index 0000000..263987c
--- /dev/null
+++ b/git-rebase--am.sh
@@ -0,0 +1,34 @@
+#!/bin/sh
+#
+# Copyright (c) 2010 Junio C Hamano.
+#
+
+. git-sh-setup
+
+case "$action" in
+continue)
+ git am --resolved --3way --resolvemsg="$resolvemsg" &&
+ move_to_original_branch
+ exit
+ ;;
+skip)
+ git am --skip -3 --resolvemsg="$resolvemsg" &&
+ move_to_original_branch
+ exit
+ ;;
+esac
+
+test -n "$rebase_root" && root_flag=--root
+
+git format-patch -k --stdout --full-index --ignore-if-in-upstream \
+ --src-prefix=a/ --dst-prefix=b/ \
+ --no-renames $root_flag "$revisions" |
+git am $git_am_opt --rebasing --resolvemsg="$resolvemsg" &&
+move_to_original_branch
+ret=$?
+test 0 != $ret -a -d "$state_dir" &&
+ echo $head_name > "$state_dir/head-name" &&
+ echo $onto > "$state_dir/onto" &&
+ echo $orig_head > "$state_dir/orig-head" &&
+ echo "$GIT_QUIET" > "$state_dir/quiet"
+exit $ret
diff --git a/git-rebase.sh b/git-rebase.sh
index 44e169f..c60221b 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -91,7 +91,7 @@ run_specific_rebase () {
GIT_EDITOR=:
export GIT_EDITOR
fi
- test "$type" != am && . git-rebase--$type
+ . git-rebase--$type
}
run_pre_rebase_hook () {
@@ -261,17 +261,11 @@ continue)
}
read_basic_state
run_specific_rebase
- git am --resolved --3way --resolvemsg="$resolvemsg" &&
- move_to_original_branch
- exit
;;
skip)
git reset --hard HEAD || exit $?
read_basic_state
run_specific_rebase
- git am -3 --skip --resolvemsg="$resolvemsg" &&
- move_to_original_branch
- exit
;;
abort)
git rerere clear
@@ -324,14 +318,12 @@ then
shift
upstream=`git rev-parse --verify "${upstream_name}^0"` ||
die "invalid upstream $upstream_name"
- unset root_flag
upstream_arg="$upstream_name"
else
test -z "$onto" && die "You must specify --onto when using --root"
unset upstream_name
unset upstream
- root_flag="--root"
- upstream_arg="$root_flag"
+ upstream_arg=--root
fi
# Make sure the branch to rebase onto is valid.
@@ -457,23 +449,4 @@ else
revisions="$upstream..$orig_head"
fi
-if test -z "$do_merge"
-then
- git format-patch -k --stdout --full-index --ignore-if-in-upstream \
- --src-prefix=a/ --dst-prefix=b/ \
- --no-renames $root_flag "$revisions" |
- git am $git_am_opt --rebasing --resolvemsg="$resolvemsg" &&
- move_to_original_branch
- ret=$?
- test 0 != $ret -a -d "$apply_dir" &&
- echo $head_name > "$apply_dir/head-name" &&
- echo $onto > "$apply_dir/onto" &&
- echo $orig_head > "$apply_dir/orig-head" &&
- echo "$GIT_QUIET" > "$apply_dir/quiet"
- exit $ret
-fi
-
-# start doing a rebase with git-merge
-# this is rename-aware if the recursive (default) strategy is used
-
run_specific_rebase
--
1.7.4.rc2.33.g8a14f
^ permalink raw reply related
* [PATCH v2 16/31] rebase -i: support --stat
From: Martin von Zweigbergk @ 2011-02-06 18:43 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Christian Couder, Thomas Rast, Martin von Zweigbergk
In-Reply-To: <1297017841-20678-1-git-send-email-martin.von.zweigbergk@gmail.com>
Move up the code that displays the diffstat if '--stat' is passed, so
that it will be executed before calling git-rebase--interactive.sh.
A side effect is that the diffstat is now displayed before "First,
rewinding head to replay your work on top of it...".
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
git-rebase.sh | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 87d7fde..c8a7e4e 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -539,13 +539,6 @@ fi
# If a hook exists, give it a chance to interrupt
run_pre_rebase_hook "$upstream_arg" "$@"
-test "$type" = interactive && run_interactive_rebase
-
-# Detach HEAD and reset the tree
-say "First, rewinding head to replay your work on top of it..."
-git checkout -q "$onto^0" || die "could not detach HEAD"
-git update-ref ORIG_HEAD $branch
-
if test -n "$diffstat"
then
if test -n "$verbose"
@@ -556,6 +549,13 @@ then
GIT_PAGER='' git diff --stat --summary "$mb" "$onto"
fi
+test "$type" = interactive && run_interactive_rebase
+
+# Detach HEAD and reset the tree
+say "First, rewinding head to replay your work on top of it..."
+git checkout -q "$onto^0" || die "could not detach HEAD"
+git update-ref ORIG_HEAD $branch
+
# If the $onto is a proper descendant of the tip of the branch, then
# we just fast-forwarded.
if test "$mb" = "$branch"
--
1.7.4.rc2.33.g8a14f
^ permalink raw reply related
* [PATCH v2 10/31] rebase: factor out command line option processing
From: Martin von Zweigbergk @ 2011-02-06 18:43 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Christian Couder, Thomas Rast, Martin von Zweigbergk
In-Reply-To: <1297017841-20678-1-git-send-email-martin.von.zweigbergk@gmail.com>
Factor out the command line processing in git-rebase--interactive.sh
to git-rebase.sh. Store the options in variables in git-rebase.sh and
then source git-rebase--interactive.sh.
Suggested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
Changes since v1:
* As suggested by Johannes Sixt, source git-rebase--interactive.sh
instead of executing it.
Since this removes the command line processing from
git-rebase--interactive.sh, it completely changes its command line
interface. Since it is not listed as even a plumbing command, I hope
this is fine.
git-rebase--interactive.sh | 224 ++++++++++++--------------------------------
git-rebase.sh | 58 ++++++++----
2 files changed, 100 insertions(+), 182 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 8b0d7b0..9c43c60 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -10,31 +10,7 @@
# The original idea comes from Eric W. Biederman, in
# http://article.gmane.org/gmane.comp.version-control.git/22407
-OPTIONS_KEEPDASHDASH=
-OPTIONS_SPEC="\
-git-rebase [-i] [options] [--] <upstream> [<branch>]
-git-rebase [-i] (--continue | --abort | --skip)
---
- Available options are
-v,verbose display a diffstat of what changed upstream
-onto= rebase onto given branch instead of upstream
-p,preserve-merges try to recreate merges instead of ignoring them
-s,strategy= use the given merge strategy
-no-ff cherry-pick all commits, even if unchanged
-m,merge always used (no-op)
-i,interactive always used (no-op)
- Actions:
-continue continue rebasing process
-abort abort rebasing process and restore original branch
-skip skip current patch and continue rebasing process
-no-verify override pre-rebase hook from stopping the operation
-verify allow pre-rebase hook to run
-root rebase all reachable commmits up to the root(s)
-autosquash move commits that begin with squash!/fixup! under -i
-"
-
. git-sh-setup
-require_work_tree
dotest="$GIT_DIR/rebase-merge"
@@ -105,16 +81,6 @@ amend="$dotest"/amend
rewritten_list="$dotest"/rewritten-list
rewritten_pending="$dotest"/rewritten-pending
-preserve_merges=
-strategy=
-onto=
-verbose=
-ok_to_skip_pre_rebase=
-rebase_root=
-autosquash=
-test "$(git config --bool rebase.autosquash)" = "true" && autosquash=t
-force_rebase=
-
GIT_CHERRY_PICK_HELP="\
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' and run 'git rebase --continue'"
@@ -648,15 +614,6 @@ skip_unnecessary_picks () {
die "Could not skip unnecessary pick commands"
}
-# check if no other options are set
-is_standalone () {
- test $# -eq 2 -a "$2" = '--' &&
- test -z "$onto" &&
- test -z "$preserve_merges" &&
- test -z "$strategy" &&
- test -z "$verbose"
-}
-
get_saved_options () {
test -d "$rewritten" && preserve_merges=t
test -f "$dotest"/strategy && strategy="$(cat "$dotest"/strategy)"
@@ -744,134 +701,77 @@ parse_onto () {
git rev-parse --verify "$1^0"
}
-while test $# != 0
-do
- case "$1" in
- --no-verify)
- ok_to_skip_pre_rebase=yes
- ;;
- --verify)
- ok_to_skip_pre_rebase=
- ;;
- --continue)
- is_standalone "$@" || usage
- get_saved_options
- comment_for_reflog continue
-
- test -d "$dotest" || die "No interactive rebase running"
-
- # Sanity check
- git rev-parse --verify HEAD >/dev/null ||
- die "Cannot read HEAD"
- git update-index --ignore-submodules --refresh &&
- git diff-files --quiet --ignore-submodules ||
- die "Working tree is dirty"
-
- # do we have anything to commit?
- if git diff-index --cached --quiet --ignore-submodules HEAD --
+case "$action" in
+continue)
+ get_saved_options
+ comment_for_reflog continue
+
+ test -d "$dotest" || die "No interactive rebase running"
+
+ # Sanity check
+ git rev-parse --verify HEAD >/dev/null ||
+ die "Cannot read HEAD"
+ git update-index --ignore-submodules --refresh &&
+ git diff-files --quiet --ignore-submodules ||
+ die "Working tree is dirty"
+
+ # do we have anything to commit?
+ if git diff-index --cached --quiet --ignore-submodules HEAD --
+ then
+ : Nothing to commit -- skip this
+ else
+ . "$author_script" ||
+ die "Cannot find the author identity"
+ current_head=
+ if test -f "$amend"
then
- : Nothing to commit -- skip this
- else
- . "$author_script" ||
- die "Cannot find the author identity"
- current_head=
- if test -f "$amend"
- then
- current_head=$(git rev-parse --verify HEAD)
- test "$current_head" = $(cat "$amend") ||
- die "\
+ current_head=$(git rev-parse --verify HEAD)
+ test "$current_head" = $(cat "$amend") ||
+ die "\
You have uncommitted changes in your working tree. Please, commit them
first and then run 'git rebase --continue' again."
- git reset --soft HEAD^ ||
- die "Cannot rewind the HEAD"
- fi
- do_with_author git commit --no-verify -F "$msg" -e || {
- test -n "$current_head" && git reset --soft $current_head
- die "Could not commit staged changes."
- }
+ git reset --soft HEAD^ ||
+ die "Cannot rewind the HEAD"
fi
+ do_with_author git commit --no-verify -F "$msg" -e || {
+ test -n "$current_head" && git reset --soft $current_head
+ die "Could not commit staged changes."
+ }
+ fi
- record_in_rewritten "$(cat "$dotest"/stopped-sha)"
+ record_in_rewritten "$(cat "$dotest"/stopped-sha)"
- require_clean_work_tree "rebase"
- do_rest
- ;;
- --abort)
- is_standalone "$@" || usage
- get_saved_options
- comment_for_reflog abort
-
- git rerere clear
- test -d "$dotest" || die "No interactive rebase running"
-
- headname=$(cat "$dotest"/head-name)
- head=$(cat "$dotest"/head)
- case $headname in
- refs/*)
- git symbolic-ref HEAD $headname
- ;;
- esac &&
- output git reset --hard $head &&
- rm -rf "$dotest"
- exit
- ;;
- --skip)
- is_standalone "$@" || usage
- get_saved_options
- comment_for_reflog skip
+ require_clean_work_tree "rebase"
+ do_rest
+ ;;
+abort)
+ get_saved_options
+ comment_for_reflog abort
- git rerere clear
- test -d "$dotest" || die "No interactive rebase running"
+ git rerere clear
+ test -d "$dotest" || die "No interactive rebase running"
- output git reset --hard && do_rest
- ;;
- -s)
- case "$#,$1" in
- *,*=*)
- strategy=$(expr "z$1" : 'z-[^=]*=\(.*\)') ;;
- 1,*)
- usage ;;
- *)
- strategy="$2"
- shift ;;
- esac
- ;;
- -m)
- # we use merge anyway
- ;;
- -v)
- verbose=t
- ;;
- -p)
- preserve_merges=t
- ;;
- -i)
- # yeah, we know
- ;;
- --no-ff)
- force_rebase=t
- ;;
- --root)
- rebase_root=t
- ;;
- --autosquash)
- autosquash=t
- ;;
- --no-autosquash)
- autosquash=
- ;;
- --onto)
- test 2 -le "$#" || usage
- onto="$2"
- shift
- ;;
- --)
- shift
- break
+ headname=$(cat "$dotest"/head-name)
+ head=$(cat "$dotest"/head)
+ case $headname in
+ refs/*)
+ git symbolic-ref HEAD $headname
;;
- esac
- shift
-done
+ esac &&
+ output git reset --hard $head &&
+ rm -rf "$dotest"
+ exit
+ ;;
+skip)
+ get_saved_options
+ comment_for_reflog skip
+
+ git rerere clear
+ test -d "$dotest" || die "No interactive rebase running"
+
+ output git reset --hard && do_rest
+ ;;
+esac
if test -n "$onto"
then
diff --git a/git-rebase.sh b/git-rebase.sh
index 3eac5a4..aa1bcaf 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -64,6 +64,9 @@ type=
state_dir=
# One of {'', continue, skip, abort}, as parsed from command line
action=
+preserve_merges=
+autosquash=
+test "$(git config --bool rebase.autosquash)" = "true" && autosquash=t
read_state () {
if test "$type" = merge
@@ -176,27 +179,12 @@ finish_rb_merge () {
say All done.
}
-is_interactive () {
- while test $# != 0
- do
- case "$1" in
- -i|--interactive)
- interactive_rebase=explicit
- break
- ;;
- -p|--preserve-merges)
- interactive_rebase=implied
- ;;
- esac
- shift
- done
-
+run_interactive_rebase () {
if [ "$interactive_rebase" = implied ]; then
GIT_EDITOR=:
export GIT_EDITOR
fi
-
- test -n "$interactive_rebase" || test -f "$merge_dir"/interactive
+ . git-rebase--interactive "$@"
}
run_pre_rebase_hook () {
@@ -211,8 +199,6 @@ run_pre_rebase_hook () {
test -f "$apply_dir"/applying &&
die 'It looks like git-am is in progress. Cannot rebase.'
-is_interactive "$@" && exec git-rebase--interactive "$@"
-
if test -d "$apply_dir"
then
type=am
@@ -249,6 +235,19 @@ do
onto="$2"
shift
;;
+ -i|--interactive)
+ interactive_rebase=explicit
+ ;;
+ -p|--preserve-merges)
+ preserve_merges=t
+ test -z "$interactive_rebase" && interactive_rebase=implied
+ ;;
+ --autosquash)
+ autosquash=t
+ ;;
+ --no-autosquash)
+ autosquash=
+ ;;
-M|-m|--m|--me|--mer|--merg|--merge)
do_merge=t
;;
@@ -339,7 +338,11 @@ do
done
test $# -gt 2 && usage
-test -n "$action" && test -z "$in_progress" && die "No rebase in progress?"
+if test -n "$action"
+then
+ test -z "$in_progress" && die "No rebase in progress?"
+ test "$type" = interactive && run_interactive_rebase
+fi
case "$action" in
continue)
@@ -415,6 +418,21 @@ fi
test $# -eq 0 && test -z "$rebase_root" && usage
+if test -n "$interactive_rebase"
+then
+ type=interactive
+ state_dir="$merge_dir"
+elif test -n "$do_merge"
+then
+ type=merge
+ state_dir="$merge_dir"
+else
+ type=am
+ state_dir="$apply_dir"
+fi
+
+test "$type" = interactive && run_interactive_rebase "$@"
+
require_clean_work_tree "rebase" "Please commit or stash them."
if test -z "$rebase_root"
--
1.7.4.rc2.33.g8a14f
^ permalink raw reply related
* Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository
From: Heiko Voigt @ 2011-02-06 18:51 UTC (permalink / raw)
To: Julian Ibarz; +Cc: Junio C Hamano, Jens Lehmann, git
In-Reply-To: <AANLkTim2G0kF+omPZ1_fk0P6oGDaKDWd79XNR5GXUkWG@mail.gmail.com>
Hi Julian,
interesting work so far.
One thing regarding the mailing list: Please do not top post and try to cut non
relevant text (the one you are not replying to) from your replies.
On Wed, Feb 02, 2011 at 11:31:40PM -0500, Julian Ibarz wrote:
> After a couple of hours, I have finally succeeded to go through the
> entire history of a repository and I can detect the submodules in a
> tree of a commit. For those interested here is the source code:
>
> http://gitorious.org/julian_ibarz_git/julian_ibarz_git/blobs/submodule_checkout/builtin/submodulecheckout.c
>
> Next time I will build the list of commits of a submodule in the
> entire history.
Sounds great. That will be one tool you need. Here is a small script
snippet which already does that as an example for the msysgit repository
(git://repo.or.cz/msysgit.git):
export sub=git
git log --pretty="%h" -- $sub | \
while read i; do git ls-tree $i -- $sub; done | \
cut -f3 -d" " | cut -f1
It outputs all the hashes that have been registered for the git
submodule. Maybe thats a good starting point to find example code in C.
You can use it for other submodules also just change the name in the variable
sub.
> Then I will need to find the distance of each commit
> in the list compared to the current commit of a submodule and keep
> the closest one (which has to be a parent so an algebric distance
> would be good to have).
Have a look at the codepath that is used for
git branch --contains <sha1>
It essentially does the thing you want (find all refs that contain a
commit). An approach could be to extend this mechanism not to iterate
through all refs but e.g. take a list of sha1's for iteration.
> So now my two questions that could save me some time are:
> - is there a function that gives the distance between two commits? I'm
> sure there is something like this coded somewhere but I didn't find it
> yet
> - is the struct decorate a hash map and if yes could someone explain
> me how to use it or point me to a location where it is used?
Please see the tips above.
> Except from that I think I have all the information I need.
There are a few points I would like to mention:
* Citing my drawing:
> >> superproject A:
> >>
> >> O---O---X''---O
> >> \
> >> submodule B: \
> >> \
> >> O---X---O---X'---O---O
There can be multiple X' which contain X. These are all valid
candidates. The same applies to X'' where there can be multiple
candidates that record a specific X'. IMO, all of them need to be
considered. If in the end they all reduce to one commit in submodule C
you can check that out. If not printing a list of all candidates is
probably the best option.
* If we want your code to go upstream it probably needs to be
integrated as a subcommand into the current submodule script. I can
offer to help you on the bash scripting side. I think once the tools
to find the appropriate commits are ready that will not be a big
issue.
* I think for protoyping the tools you can later use in the submodule
script its fine to implement your own command. Keep in mind that you
later on you should probably integrate your code into the appropriate
existing commands. Here some suggestions.
To support proper bash scripting two parts come into my mind:
1. A tool to output all of the submodules commits which are
candidates for X'' like the script snippet above.
2. A tool that takes the list from 1. and then reduces that list to
a list of commits that actually register the possible commits X'.
If that is one commit X'' we can directly checkout. If not we
print the list in a nice format and let the user choose.
Looking forward to your work.
Cheers Heiko
^ permalink raw reply
* Re: git-new-workdir for filesystems without links (e.g. FAT32)?
From: Jonathan Nieder @ 2011-02-06 19:14 UTC (permalink / raw)
To: Piotr Krukowiecki; +Cc: git, Pierre Habouzit
In-Reply-To: <loom.20110206T151206-851@post.gmane.org>
Hi Piotr,
Piotr Krukowiecki wrote:
> git-new-workdir requires soft links to work, so obviously it will fail if file
> system does not support them. Is there any other way for having multiple working
> dirs with one repository?
I assume you mean a way to share refs between repositories without
using symlinks? Then alas, that is not implemented, though there
is some interest. See [1] for details.
It should not be impossible, I think --- something for refs analagous
to the ".git file" mechanism might make perfect sense (see
v1.5.6-rc0~93^2~3, Add platform-independent .git "symlink", 2008-02-20
and "git log --grep='git file'" to see development since then). The
main distinction here is that the target of a refs "symlink" should
also be aware of it, to avoid garbage collecting the shared objects.
If on the other hand you just want to share objects (not refs) between
repositories, the GIT_OBJECT_DIRECTORY environment variable might
help.
Good luck,
Jonathan
[1] http://thread.gmane.org/gmane.comp.version-control.git/150559/focus=150693
^ permalink raw reply
* Re: "git add -u" broken in git 1.7.4?
From: Sebastian Pipping @ 2011-02-06 19:35 UTC (permalink / raw)
To: Jeff King; +Cc: Git ML
In-Reply-To: <20110206051333.GA3458@sigill.intra.peff.net>
On 02/06/11 06:13, Jeff King wrote:
> On Sun, Feb 06, 2011 at 01:39:32AM +0100, Sebastian Pipping wrote:
>
>> I just ran into case where
>>
>> git add -u
>>
>> repetedly did not update the index. In contrast, picking stuff using
>>
>> git add -p
>>
>> works just fine.
>>
>> Could it be "git add -u" is broken in git 1.7.4?
>
> It could be. However, I can think of one such case where you might see
> that behavior. "git add -u" operates from the current subdirectory,
> whereas "git add -p" operates from the top of the project tree (yes,
> this inconsistency confusing, but it's not as serious as "git add -u
> doesn't work").
>
> You can demonstrate it with:
>
> mkdir repo && cd repo && git init
> mkdir subdir && echo content >file
> git add . && git commit -m base
> echo more >>file
>
> mkdir subdir && cd subdir
> git add -u
> git status ;# still not staged for commit
>
> git add -p ;# finds it
>
> Might you have been in a subdirectory of the project when you saw this
> behavior?
I was and I can confirm the different behaviour with 1.7.4 over here: it
does work on the root directory of the repo as you supposed.
Is that behavior needed to be as is or could you change it to work from
everywhere? Could it be it has been working from anywhere before?
Best,
Sebastian
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Junio C Hamano @ 2011-02-06 20:04 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Jeff King, Junio C Hamano, Johan Herland, git, Sverre Rabbelier,
Nguyen Thai Ngoc Duy
In-Reply-To: <alpine.LFD.2.00.1102051449420.12104@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
>> The latter seems like a regression for the common case of fetching from
>> two upstreams. E.g., I usually pull from Junio, getting
>> remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I
>> pull from him, getting remotes/spearce/v1.7.0, which he previously
>> fetched from Junio. Under the current code, I can still do "git show
>> v1.7.0"; under the scheme described above I now have to say
>> "origin/v1.7.0" to disambiguate.
>
> Let's suppose that both tags are identical, as in your scenario above
> they would be, then there is no need to call for any ambiguity in that
> case.
I agree that we do not want refs/remotes/tags/*/that-tag-people-agree-on
in that case. We want to store a single copy and find it there, and that
single copy has traditionally been found in refs/tags hierarchy.
I think the real issue is not necessarily that the location is shared with
local tag namespace, but is the lack of a convenient way (or just BCP) to
segregate what are local and what are official when transferring tags out
of your repository. That is what discourages people from using tags for
their personal and ephemeral use, marking some points in their own work
with personal tags that are never intended to be published.
In the "interim maintainer" case without separate tag namespaces, Shawn
would have been using refs/tags space to auto-follow vX.Y.Z tags that
everybody agrees on and also mark his own progress with local tags, and he
needs to be careful not to push out the local tags he does not want to
share to his publishing repository, lest he contaminate refs/tags in
repositories of other people [*1*]
But the above is less of an issue, for people who use a separate publish
repository with private working repository. All they need to do is to be
careful when they run "git push". By default we don't push new tags
(thanks to "matching refs") nor push autopropagates tags when pushing
updated branch heads out, so it suffices only to double check the tag
being pushed is the right one when they run "git push $there vX.Y.Z", and
to make sure they never run "git push --tags".
The problem happens when people directly start fetching or cloning from a
private working-space repository, e.g. my primary integration repository
has several tags that shouldn't go to k.org mixed with the vX.Y.Z tags,
and that is perfectly fine as the organization gives me a uniform way to
call things with names without looking at many places (i.e. refs/tags vs
refs/remotes/*/tags/), yet it does not risk contaminating other people's
tag namespaces because I don't allow anybody to clone nor fetch from it
directly. That breaks down once people can fetch/clone from it.
Thinking aloud and not thinking things through, perhaps what's needed is a
namespace private/local to the repository, i.e. instead of
refs/remotes/*/tags, refs/private-tags hierarchy that I can use to store
local names, and are never seen by fetch/clone?
You can swap naming around and say my (refs/tags, refs/private-tags) can
be expressed with (refs/remotes/origin/tags, refs/tags), and I fully agree
with that argument. The former is for tags everybody agrees on, the
latter for tags that are private. The aversion I showed in my message
against refs/remotes/*/tags is coming directly from this observation.
Namely, you can explain refs/remotes/origin/tags with the above line of
reasoning, but how would you explain refs/remotes/$other_names/tags
hierarchy? What do they mean, how they are useful, etc.
[Footnote]
*1* This issue actually is already present without "interim maintainer".
I have several tags in my primary integration repository that I don't
intend to publish to my repository at k.org; the gitster/git.git
repository I have at GitHub is intended to disclose what I personally
have, including the broken-out set of topic branches, and these tags are
published there.
^ permalink raw reply
* Re: [PATCH] git-send-email.perl: Add --suppress-to
From: Junio C Hamano @ 2011-02-06 20:28 UTC (permalink / raw)
To: Joe Perches; +Cc: git
In-Reply-To: <1296949208.4133.66.camel@Joe-Laptop>
Joe Perches <joe@perches.com> writes:
> +- 'author' will avoid including the patch author
> +- 'self' will avoid including the sender
> +- 'tocmd' will avoid running the --to-cmd
> +- 'bodyto' will avoid including anyone mentioned in To lines in the
> + patch body (commit message) except for self (use 'self' for that)
> +- 'all' will suppress all auto to values.
Is there a definition of what an "auto to value" is somewhere? "auto cc values"
was sort of understandable as there is no word "cc" (other than 1/1000 litre ;-)
and what it meant was guessable from context, but it took me a few seconds
to realize you meant "To:" with this.
> +--
> ++
> +Default is the value of 'sendemail.suppressto' configuration value; if
> +that is unspecified, default to 'self' if --suppress-from is
> +specified.
> +
> --suppress-cc=<category>::
> Specify an additional category of recipients to suppress the
> auto-cc of:
Hmmm, from a cursory look I don't see how bodyto is handled and where.
> @@ -1201,6 +1227,9 @@ foreach my $t (@files) {
> }
> elsif (/^To:\s+(.*)$/) {
> foreach my $addr (parse_address_line($1)) {
> +
> + next if $suppress_to{'author'};
Is "To: somebody" in the output guaranteed to name the author and nobody else?
> + next if $suppress_to{'self'} and $author eq $sender;
> printf("(mbox) Adding to: %s from line '%s'\n",
> $addr, $_) unless $quiet;
> push @to, sanitize_address($addr);
> @@ -1269,7 +1298,7 @@ foreach my $t (@files) {
> close $fh;
>
> push @to, recipients_cmd("to-cmd", "to", $to_cmd, $t)
> - if defined $to_cmd;
> + if defined $to_cmd && !$suppress_to{'tocmd'};
> push @cc, recipients_cmd("cc-cmd", "cc", $cc_cmd, $t)
> if defined $cc_cmd && !$suppress_cc{'cccmd'};
I think it is about time to make this a bit more readable by explicitly
using if statement, not statement modifiers.
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Matthieu Moy @ 2011-02-06 20:28 UTC (permalink / raw)
To: Johan Herland
Cc: Dmitry Potapov, git, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <201102060104.37146.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> I don't see how the separate namespaces cause problems here. Also, I don't
> know what you're proposing instead, or indeed what other organization of
> tags would lead to less confusion.
I'm not against the idea, but one drawback of the separate namespace
is that it introduces complexity for the user. In the common case,
where the user may fetch the same tag from various sources, there
will still be several refs (probably listed by "git tag" ?), and this
may confuse the user.
Another question is what happens when you push. With branches,
fetching XXX fetches in origin/XXX, but pushing YYY does push to YYY.
This asymetry between push and pull works well because most of the
time, if we have a origin/XXX branch, we also have XXX (with
origin/XXX as upstream).
For tags, it's clearly different. If I have origin/v1.7.4, I don't see
much reason to have _also_ v1.7.4 as a local tag. And if I have only
origin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from
it will get origin/origin/v1.7.4, and so on.
So, my feeling is that the "separate namespace" should not be
automatic.
For example, today, git.git repo contains tags like v1.7.4 and others
like gitgui-0.13.0, which is clearly a handmade namespace, where a
real namespace would be better. That would make a lot of sence to me
if Junio had something like
[remote "git-gui"]
url = ...
fetch = +refs/heads/*:refs/remotes/git-gui/*
fetch = +refs/tags/*:refs/tags/remotes/git-gui/*
or whatever other syntax, so that git-gui's tags be automatically
fetched into the right namespace (with no warning in case of
duplicate).
But OTOH, I don't want to have several namespaces in my git repo even
if I configure several remotes to fetch from. In this case, duplicate
tags are just redundancy if they point to the same object, and a real
conflict I want to know about immediately otherwise.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: ignoring file modes completely
From: Rafael Kitover @ 2011-02-06 20:29 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTikCKZetZXRCZSLiM73engBcyxNfCtBN5yWdEgRs@mail.gmail.com>
On 2/6/2011 1:10 PM, Dmitry Potapov wrote:
> On Sun, Feb 06, 2011 at 11:14:30AM -0500, Rafael Kitover wrote:
>> $ git diff HEAD
>> diff --git a/README b/README
>> old mode 100644
>> new mode 100755
>> $ git config --global core.filemode
>> false
>
> This is because core.filemode is set in the local configuration:
> $ git config core.filemode
> true
>
> Git automatically detects if chmod(2) is supported on the current file
> system and sets core.filemode to the corresponding value. Because cygwin
> emulates chmod(), git sets core.filemode to true.
That was it! Thank you very much. I can now use msysGit and Cygwin git
together, very cool.
^ permalink raw reply
* Re: [1.8.0] Tracking empty directories
From: Junio C Hamano @ 2011-02-06 20:41 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: thomas, Jakub Narebski, git
In-Reply-To: <AANLkTikX5Y=TrXayXj-MCaR5p0=Tokc_5ihGqHFL9CQx@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Sat, Feb 5, 2011 at 19:31, Thomas Koch <thomas@koch.ro> wrote:
>> - Implement the possibility to checkout/read/handle empty directories as soon
>> as possible, even in the next 1.7.x release.
>
> I think regardless of whatever else we do, this makes sense. I think
> it's been suggested by Junio in a neighboring thread as well.
Huh?
^ permalink raw reply
* Re: [PATCH] git pull: Remove option handling done by fetch
From: Junio C Hamano @ 2011-02-06 20:45 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <4D4D33E7.4000303@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Yes, but isn't that exactly what the pull man-page says? Quote:
> "Options meant for git pull itself and the underlying git merge
> must be given before the options meant for git fetch."
Yes, it says that, and I think that was a weasely way to say "the command
line parser in git-pull is broken". The lines you are removing was from
the patch that fixed that breakage, aren't they?
^ permalink raw reply
* Re: [1.8.0] Tracking empty directories
From: Sverre Rabbelier @ 2011-02-06 20:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: thomas, Jakub Narebski, git
In-Reply-To: <7vmxm8x5dx.fsf@alter.siamese.dyndns.org>
Heya,
On Sun, Feb 6, 2011 at 21:41, Junio C Hamano <gitster@pobox.com> wrote:
> Huh?
To teach the plumbing to handle empty directories first, and then in a
later release add porcelain?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: "git add -u" broken in git 1.7.4?
From: Matthieu Moy @ 2011-02-06 20:48 UTC (permalink / raw)
To: Sebastian Pipping; +Cc: Jeff King, Git ML
In-Reply-To: <4D4EF7E4.7050303@hartwork.org>
Sebastian Pipping <webmaster@hartwork.org> writes:
> I was and I can confirm the different behaviour with 1.7.4 over here: it
> does work on the root directory of the repo as you supposed.
What do you mean by "it does not work"?
"git add -u" adds files under the current directory, and it always
did.
> Is that behavior needed to be as is or could you change it to work from
> everywhere?
I consider it as a design bug that "add -u" is not tree-wide, but it's
not easy to change the existing behavior without breaking expectations
of people used to the current behavior.
> Could it be it has been working from anywhere before?
Can you post an example where Git 1.7.4 and a previous version behave
differently? Up to now, I see difference between your expectations and
what Git does, but not between new and old versions.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH v2] git-commit --patch
From: Conrad Irwin @ 2011-02-06 21:06 UTC (permalink / raw)
To: git; +Cc: conrad.irwin
In-Reply-To: <1296710732-12493-1-git-send-email-conrad.irwin@gmail.com>
Is there a recommended way of stirring up attention for patchsets like
this, or did I just miss the replies?
Conrad
On 2 February 2011 21:25, Conrad Irwin <conrad.irwin@gmail.com> wrote:
> This patch-set adds support for git-commit --patch, and tidies up some of the
> rough edges of git commit --interactive.
>
> The motivation is to support my current workflow, which goes something like:
>
> 1. Hack out the basic structure of the feature that I'm working on, until I have
> something that looks like it will work.
> 2. Split this into several commits with a more logical flow (i.e. some that add
> support for the techniques I want to use for the actual feature, then the
> feature itself).
> 3. Start fleshing out the implementation, and bug-fixing, with lots of
> git-commit --fixup so that the changes end up in the right commit.
> 4. At the end of the day, a big rebase -i to make the history readable.
>
> This is just about doable with git-add -p, or git-commit --interactive, but
> it's very inefficient. I take the presence of git commit --fixup to imply that
> other people are doing similar, if less extreme things, so assume that they
> would like a git-commit -p too.
>
> Conrad
>
>
^ permalink raw reply
* Re: [PATCH] git pull: Remove option handling done by fetch
From: Jens Lehmann @ 2011-02-06 21:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List, Jonathan Nieder
In-Reply-To: <7vipwwx56r.fsf@alter.siamese.dyndns.org>
Am 06.02.2011 21:45, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Yes, but isn't that exactly what the pull man-page says? Quote:
>> "Options meant for git pull itself and the underlying git merge
>> must be given before the options meant for git fetch."
>
> Yes, it says that, and I think that was a weasely way to say "the command
> line parser in git-pull is broken". The lines you are removing was from
> the patch that fixed that breakage, aren't they?
Nope, they were from the patch where I taught "git fetch" the
"--recurse-submodules" option and was not aware at that time that
"git pull" should just pass on almost all fetch options (the only
exceptions to that rule being -q, -v, -n and --progress). The thing
I had in mind was to later pass the same "--recurse-submodules"
option to the merge command too (when I finished implementing that
option). But when I understood later that pull handles the fetch
options in an interesting way I noticed that it would depend on the
order of options given if the "--recurse-submodules" would then be
passed to both fetch and merge or just to fetch, which will lead to
an interesting and unintuitive behavior I was not eager to expose.
So yes, I hit the strangeness of the "git pull" option parsing, but
decided to not mess it up further by adding another option to the
ones it does handle differently but play by the rules which are
used now (The other possibility would have been to document it
as a new option to "git pull", but that would have lead to the
problem I described earlier when merge will learn that option too).
So I have no strong feelings about this patch but believe it is the
right thing to do as long as "git pull" handles its options the way
it does. But looking at the confusion that option handling caused
I think it might be a worthwhile idea to overhaul it.
(CCed Jonathan, as he is the author of the lines I quoted)
^ permalink raw reply
* Re: [PATCH 2/2] git-p4: Add copy detection support
From: Pete Wyckoff @ 2011-02-06 22:05 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git
In-Reply-To: <AANLkTi=Awi6d77QcbbZ2rDTv6LpP+qjsReJ5=4NyhUBz@mail.gmail.com>
vitor.hda@gmail.com wrote on Sun, 06 Feb 2011 17:25 +0000:
> Hi Pete,
>
> On Sun, Feb 6, 2011 at 12:25 AM, Pete Wyckoff <pw@padd.com> wrote:
> > You can use integrate -t to force the filetype even if the file
> > already existed, and skip the whole execbit change.
>
> (Copying help text:
> The -t flag makes the source file's filetype propagate to the target
> file. Normally, the target file retains its previous filetype.
> Newly branched files always use the source file's filetype. The
> filetype can still be changed before 'p4 submit' with 'p4 reopen'.
> )
>
> Since in git we're only considering newly branched files, I think in
> this case "-t" will not add anything. In fact, what is being done here
> is detecting exec bit changes from source to target files - we're not
> trying to force P4 to use the source's exec bit. Do you agree?
That sounds fine to me. The code seemed to indicate that
sometimes the destination file exists.
> + elif modifier == "C":
> + src, dest = diff['src'], diff['dst']
> + p4_system("integrate -Dt \"%s\" \"%s\"" % (src, dest))
> + if diff['src_sha1'] != diff['dst_sha1']:
> + p4_system("edit \"%s\"" % (dest))
> + if isModeExecChanged(diff['src_mode'], diff['dst_mode']):
> + filesToChangeExecBit[dest] = diff['dst_mode']
> + os.unlink(dest)
> + editedFiles.add(dest)
If you're happy the dest never exists, you may be able to get rid
of the edit step and the mode-change check entirely. As long as
you've tested this, you're the expert here. The change makes
sense overall.
-- Pete
^ 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