You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

93 lines
1.7 KiB

Add Meta/Reintegrate In a workflow that uses topic branches heavily, you would need to keep updating test integration branch(es) all the time. If they are managed like my 'next' by merging the tips of topics that have grown since the last integration, it is not so difficult. You only need to review output from "git branch --no-merged next" to see if there are topics that can and needs to be merged to 'next'. But sometimes it is easier to rebuild a test integration branch from scratch all the time, especially if you do not publish it for others to build on. I've been using this script for some time to rebuild jch and pu branches in my workflow. jch's tip is supposed to always match 'next', but it is rebuilt from scratch on top of 'master' by merging the same topics that are in 'next'. You can use the same script in your work. To use it, you give a commit range base..tip to the script, and you will see a shell script that uses a series of 'git-merge'. "base" is the more stable branch that you rebuild your test integration branch on top (in my case, 'master'), and "tip" is where the tip of the test integration branch is from the last round (in my case, 'jch' or 'pu'). Then you can run the resulting script, fix conflicted merge and use 'git-commit', and then repeat until all the branches are re-integrated on top of the base branch. $ Meta/Reintegrate master..jch >/var/tmp/redo-jch.sh $ cat /var/tmp/redo-jch.sh #!/bin/sh while read branch eh do case "$eh" in "") git merge "$branch" || break ;; ?*) echo >&2 "Eh? $branch $eh"; break ;; esac done <<EOF jc/blame js/notes ks/maint-mailinfo-folded~3 tr/previous-branch EOF $ git checkout jch $ git reset --hard master $ /var/tmp/redo-jch.sh ... if there is conflict, resolve, "git commit" here ... $ /var/tmp/redo-jch.sh ... repeat until everything is applied. Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
#!/bin/sh
merge_msg="Merge branch '\(.*\)'"
x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
x40="$x40$x40$x40$x40$x40$x40$x40$x40"
LF='
'
echo '#!/bin/sh
accept_rerere=t
while case "$#,$1" in 0,*) break;; *,-*) ;; *) break ;; esac
do
case "$1" in
-n) accept_rerere= ;;
*) echo "$0 [-n]"; exit 1 ;;
esac
shift
done
accept_rerere () {
if test -z "$accept_rerere"
then
return 1
fi
if git diff |
grep -e "^.+" -e "^+." |
grep -e "^..<<<<<<<" -e "^..=======" -e "^..>>>>>>>" >/dev/null
then
return 1
else
EDITOR=: git commit -a --no-verify
return 0
fi
}
Add Meta/Reintegrate In a workflow that uses topic branches heavily, you would need to keep updating test integration branch(es) all the time. If they are managed like my 'next' by merging the tips of topics that have grown since the last integration, it is not so difficult. You only need to review output from "git branch --no-merged next" to see if there are topics that can and needs to be merged to 'next'. But sometimes it is easier to rebuild a test integration branch from scratch all the time, especially if you do not publish it for others to build on. I've been using this script for some time to rebuild jch and pu branches in my workflow. jch's tip is supposed to always match 'next', but it is rebuilt from scratch on top of 'master' by merging the same topics that are in 'next'. You can use the same script in your work. To use it, you give a commit range base..tip to the script, and you will see a shell script that uses a series of 'git-merge'. "base" is the more stable branch that you rebuild your test integration branch on top (in my case, 'master'), and "tip" is where the tip of the test integration branch is from the last round (in my case, 'jch' or 'pu'). Then you can run the resulting script, fix conflicted merge and use 'git-commit', and then repeat until all the branches are re-integrated on top of the base branch. $ Meta/Reintegrate master..jch >/var/tmp/redo-jch.sh $ cat /var/tmp/redo-jch.sh #!/bin/sh while read branch eh do case "$eh" in "") git merge "$branch" || break ;; ?*) echo >&2 "Eh? $branch $eh"; break ;; esac done <<EOF jc/blame js/notes ks/maint-mailinfo-folded~3 tr/previous-branch EOF $ git checkout jch $ git reset --hard master $ /var/tmp/redo-jch.sh ... if there is conflict, resolve, "git commit" here ... $ /var/tmp/redo-jch.sh ... repeat until everything is applied. Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
while read branch eh
do
case "$eh" in
"")
echo >&2 "* $branch"
git merge "$branch" || accept_rerere || exit
if git show-ref -q --verify "refs/merge-fix/$branch"
then
git cherry-pick --no-commit "refs/merge-fix/$branch" &&
EDITOR=: git commit --amend -a
fi
;;
pick" "*)
echo >&2 "* $eh"
git cherry-pick "$branch" || exit ;;
*) echo >&2 "Eh? $branch $eh"; exit ;;
Add Meta/Reintegrate In a workflow that uses topic branches heavily, you would need to keep updating test integration branch(es) all the time. If they are managed like my 'next' by merging the tips of topics that have grown since the last integration, it is not so difficult. You only need to review output from "git branch --no-merged next" to see if there are topics that can and needs to be merged to 'next'. But sometimes it is easier to rebuild a test integration branch from scratch all the time, especially if you do not publish it for others to build on. I've been using this script for some time to rebuild jch and pu branches in my workflow. jch's tip is supposed to always match 'next', but it is rebuilt from scratch on top of 'master' by merging the same topics that are in 'next'. You can use the same script in your work. To use it, you give a commit range base..tip to the script, and you will see a shell script that uses a series of 'git-merge'. "base" is the more stable branch that you rebuild your test integration branch on top (in my case, 'master'), and "tip" is where the tip of the test integration branch is from the last round (in my case, 'jch' or 'pu'). Then you can run the resulting script, fix conflicted merge and use 'git-commit', and then repeat until all the branches are re-integrated on top of the base branch. $ Meta/Reintegrate master..jch >/var/tmp/redo-jch.sh $ cat /var/tmp/redo-jch.sh #!/bin/sh while read branch eh do case "$eh" in "") git merge "$branch" || break ;; ?*) echo >&2 "Eh? $branch $eh"; break ;; esac done <<EOF jc/blame js/notes ks/maint-mailinfo-folded~3 tr/previous-branch EOF $ git checkout jch $ git reset --hard master $ /var/tmp/redo-jch.sh ... if there is conflict, resolve, "git commit" here ... $ /var/tmp/redo-jch.sh ... repeat until everything is applied. Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
esac
done <<EOF'
show_merge () {
branch=$(expr "$msg" : "$merge_msg") &&
tip=$(git rev-parse --verify "refs/heads/$branch" 2>/dev/null) &&
merged=$(git name-rev --refs="refs/heads/$branch" "$other" 2>/dev/null) &&
merged=$(expr "$merged" : "$x40 \(.*\)") &&
test "$merged" != undefined || {
other=$(git log -1 --pretty='format:%s' $other) &&
merged="$branch :rebased? $other"
}
}
show_pick () {
merged="$(git rev-parse --verify "$commit") pick $msg"
}
Add Meta/Reintegrate In a workflow that uses topic branches heavily, you would need to keep updating test integration branch(es) all the time. If they are managed like my 'next' by merging the tips of topics that have grown since the last integration, it is not so difficult. You only need to review output from "git branch --no-merged next" to see if there are topics that can and needs to be merged to 'next'. But sometimes it is easier to rebuild a test integration branch from scratch all the time, especially if you do not publish it for others to build on. I've been using this script for some time to rebuild jch and pu branches in my workflow. jch's tip is supposed to always match 'next', but it is rebuilt from scratch on top of 'master' by merging the same topics that are in 'next'. You can use the same script in your work. To use it, you give a commit range base..tip to the script, and you will see a shell script that uses a series of 'git-merge'. "base" is the more stable branch that you rebuild your test integration branch on top (in my case, 'master'), and "tip" is where the tip of the test integration branch is from the last round (in my case, 'jch' or 'pu'). Then you can run the resulting script, fix conflicted merge and use 'git-commit', and then repeat until all the branches are re-integrated on top of the base branch. $ Meta/Reintegrate master..jch >/var/tmp/redo-jch.sh $ cat /var/tmp/redo-jch.sh #!/bin/sh while read branch eh do case "$eh" in "") git merge "$branch" || break ;; ?*) echo >&2 "Eh? $branch $eh"; break ;; esac done <<EOF jc/blame js/notes ks/maint-mailinfo-folded~3 tr/previous-branch EOF $ git checkout jch $ git reset --hard master $ /var/tmp/redo-jch.sh ... if there is conflict, resolve, "git commit" here ... $ /var/tmp/redo-jch.sh ... repeat until everything is applied. Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
git log --pretty=oneline --first-parent "$1" |
{
series=
while read commit msg
do
if other=$(git rev-parse -q --verify "$commit^2")
then
show_merge
else
show_pick
fi
Add Meta/Reintegrate In a workflow that uses topic branches heavily, you would need to keep updating test integration branch(es) all the time. If they are managed like my 'next' by merging the tips of topics that have grown since the last integration, it is not so difficult. You only need to review output from "git branch --no-merged next" to see if there are topics that can and needs to be merged to 'next'. But sometimes it is easier to rebuild a test integration branch from scratch all the time, especially if you do not publish it for others to build on. I've been using this script for some time to rebuild jch and pu branches in my workflow. jch's tip is supposed to always match 'next', but it is rebuilt from scratch on top of 'master' by merging the same topics that are in 'next'. You can use the same script in your work. To use it, you give a commit range base..tip to the script, and you will see a shell script that uses a series of 'git-merge'. "base" is the more stable branch that you rebuild your test integration branch on top (in my case, 'master'), and "tip" is where the tip of the test integration branch is from the last round (in my case, 'jch' or 'pu'). Then you can run the resulting script, fix conflicted merge and use 'git-commit', and then repeat until all the branches are re-integrated on top of the base branch. $ Meta/Reintegrate master..jch >/var/tmp/redo-jch.sh $ cat /var/tmp/redo-jch.sh #!/bin/sh while read branch eh do case "$eh" in "") git merge "$branch" || break ;; ?*) echo >&2 "Eh? $branch $eh"; break ;; esac done <<EOF jc/blame js/notes ks/maint-mailinfo-folded~3 tr/previous-branch EOF $ git checkout jch $ git reset --hard master $ /var/tmp/redo-jch.sh ... if there is conflict, resolve, "git commit" here ... $ /var/tmp/redo-jch.sh ... repeat until everything is applied. Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
if test -z "$series"
then
series="$merged"
else
series="$merged$LF$series"
fi
done
echo "$series"
}
echo 'EOF'