Junio C Hamano [Sat, 2 May 2009 10:10:13 +0000 (03:10 -0700)]
DoKernelOrg: fix the final report of built tarball
f148646 (Meta/DoKernelOrg: adjust to multi-arch $HOME structure better,
2009-04-26) updated the name of the tarball to include architecture,
without adjusting the same name used for the reporting purposes.
Junio C Hamano [Mon, 27 Apr 2009 02:49:29 +0000 (19:49 -0700)]
Meta/Dothem: support multi-arch $HOME directory better
This can use the layout that has buildfarm under $HOME/g/$arch/buildfarm
and the layout that has it ../buildfarm, relative to the git tree. The
maintainer's home machines (and virtual ones) will use the former, while
the k.org machine will use the latter layout.
Junio C Hamano [Sun, 19 Apr 2009 16:01:41 +0000 (09:01 -0700)]
Meta/Make: allow --locale= and --test= to be given
It often is convenient to run only specific tests while still staying
at the toplevel (some failures only reproduce with particular allocation
patterns, for example). You can say
$ Meta/Make --test='1013 91??'
to run only test 1013 and 91xx series.
Similarly, you can give --locale=en_US.UTF-8 or somesuch; earlier we
always run tests in C locale for reproducibility, and the default
stays the same, but sometimes it is useful to run tests in different
locale.
Junio C Hamano [Thu, 2 Apr 2009 17:18:29 +0000 (10:18 -0700)]
Dothem: fix dotest/nodoc conditional
The test for nodoc was wrong and also missing from jch branch.
When dotest is not set, make was run twice. By running make with
just $dotest, we can build either (implicit) all or test.
Junio C Hamano [Sat, 14 Feb 2009 00:56:28 +0000 (16:56 -0800)]
Reintegrate: sometimes a specific cherry-pick need to be carried forward
This is especially necessary when you reverted a premature merge
to more stable integration branch while you do want to keep the
topic cooking in more experimental integration branch.
Junio C Hamano [Mon, 26 Jan 2009 08:48:46 +0000 (00:48 -0800)]
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.
projects / thirdparty / git.git / log
