Meta: rename 'pu' to 'seen'

todo
Junio C Hamano 2020-06-22 17:20:27 -07:00
parent 60abbb4eae
commit c483b4cf74
11 changed files with 43 additions and 43 deletions

View File

@ -45,7 +45,7 @@ for range in $(
fi
prev_branch=$branch
done
) pu..jch
) seen..jch
do
lg=$(git log --oneline "$range")
if test -n "$lg"
@ -59,7 +59,7 @@ if ! next_equiv=$(git rev-parse --verify 'jch^{/^### match next}' 2>/dev/null) |
! git diff --stat --exit-code next $next_equiv
then
next_tree=$(git rev-parse next^{tree}) &&
next_equiv=$(git rev-list --first-parent master..pu |
next_equiv=$(git rev-list --first-parent master..seen |
xargs -n1 sh -c '
echo $(git rev-parse $1^{tree}) $1
' - | sed -n -e "s/^$next_tree //p"
@ -69,12 +69,12 @@ fi
if test -n "$next_equiv"
then
jch=$(git rev-list --first-parent master..jch | wc -l) &&
pu=$(git rev-list --first-parent master..pu | wc -l) &&
seen=$(git rev-list --first-parent master..seen | wc -l) &&
next=$(git rev-list --first-parent master..$next_equiv | wc -l) &&
if test $jch -le $next
then
echo "master..$jch..jch..$next..next..$pu..pu"
echo "master..$jch..jch..$next..next..$seen..seen"
else
echo "master..$next..next..$jch..jch..$pu..pu"
echo "master..$next..next..$jch..jch..$seen..seen"
fi
fi

2
Doit
View File

@ -1,6 +1,6 @@
#!/bin/sh

test -n "$branches" || branches='next master maint jch pu'
test -n "$branches" || branches='next master maint jch seen'

changed=
for b in $branches

2
Dothem
View File

@ -65,7 +65,7 @@ then
exit 1
fi
fi
test -n "$branches" || branches='next master maint jch pu'
test -n "$branches" || branches='next master maint jch seen'
test -n "$jobs" || jobs=-j2

find_installed () {

2
KO
View File

@ -29,4 +29,4 @@ fi
git show-branch --topo-order $ko/master master
git show-branch --topo-order $ko/maint maint
git show-branch --topo-order $ko/next next
git show-branch --topo-order $ko/pu pu
git show-branch --topo-order $ko/seen seen

View File

@ -152,7 +152,7 @@ viewed online at:
* How various branches are used.

There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".
of git: "master", "maint", "next", and "seen".

The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a
@ -196,23 +196,23 @@ is merged to "master". Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".

The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen. There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch. This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more. The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work. When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".
The "seen" (formerly "pu", proposed updates) branch bundles all the
remaining topic branches the maintainer happens to have seen. There
is no guarantee that the maintainer has enough bandwidth to pick up any
and all topics that are remotely promising from the list traffic, so
please do not read too much into a topic being on (or not on) the "seen"
branch. This branch is mainly to remind the maintainer that the topics
in them may turn out to be interesting when they are polished, nothing
more. The topics on this branch aren't usually complete, well tested,
or well documented and they often need further work. When a topic that
was in "seen" proves to be in a testable shape, it is merged to "next".

You can run "git log --first-parent master..pu" to see what topics are
You can run "git log --first-parent master..seen" to see what topics are
currently in flight. Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
to be not so good and the topic can be dropped from "seen" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
early part of the "seen" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "seen") and is used by the
maintainer for his daily work.

The two branches "master" and "maint" are never rewound, and "next"
@ -222,7 +222,7 @@ using the topics that didn't make the cut in the feature release.
Some topics that used to be in "next" during the previous cycle may
get ejected from "next" when this happens.

A natural consequence of how "next" and "pu" bundles topics together
A natural consequence of how "next" and "seen" bundles topics together
is that until a topic is merged to "next", updates to it is expected
by replacing the patch(es) in the topic with an improved version,
and once a topic is merged to "next", updates to it needs to come as

2
Make
View File

@ -215,7 +215,7 @@ export LANG LC_ALL
branch=$(determine_branch)

case "$branch" in
next | maint | master | pu | jch)
next | maint | master | seen | jch)
prefix="$inst_prefix/git-$branch"
;;
snap)

2
V
View File

@ -14,7 +14,7 @@ inst_prefix=$(
echo $HOME
)

for v in maint master next pu jch
for v in maint master next seen jch
do
installed=$(
test -f "$inst_prefix/git-$v/bin/git" &&

2
WCBCC
View File

@ -3,7 +3,7 @@
BASE=${1-HEAD}

(
echo pu
echo seen
sed -ne 's/^\* \([^ ]*\) ([-0-9]*) [1-9][0-9]* commits\{0,1\}$/\1/p' \
Meta/whats-cooking.txt |
while read branch

26
cook
View File

@ -107,7 +107,7 @@ Returns a hash:
=cut

sub get_commit {
my (@base) = qw(master next pu);
my (@base) = qw(master next seen);
my $fh;
open($fh, '-|',
qw(git for-each-ref),
@ -182,7 +182,7 @@ sub get_commit {
my $co = $commit{$sha1};
if (exists $co->{'branch'}{'next'}) {
$sign = '+';
} elsif (exists $co->{'branch'}{'pu'}) {
} elsif (exists $co->{'branch'}{'seen'}) {
$sign = '-';
} else {
$sign = '.';
@ -254,11 +254,11 @@ sub get_commit {
# NEEDSWORK:
# This is done a bit too early. We grabbed all
# under refs/heads/??/* without caring if they are
# merged to 'pu' yet, and it is correct because
# merged to 'seen' yet, and it is correct because
# we want to describe a topic that is in the old
# edition that is tentatively kicked out of 'pu'.
# edition that is tentatively kicked out of 'seen'.
# However, we do not want to say a topic is used
# by a new topic that is not yet in 'pu'!
# by a new topic that is not yet in 'seen'!
my $relation = describe_relation($topic{$branch});
$topic{$branch}{'desc'} = $head . $list;
if ($relation) {
@ -286,9 +286,9 @@ sub blurb_text {
$next_at ||= '0' x 40;
$text ||= <<'EOF';
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
The ones marked with '.' do not appear in any of the integration branches,
but I am still holding onto them.
only in 'seen' (formerly 'pu'---proposed updates) while commits prefixed
with '+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.

You can find the changes described here in the integration branches of the
repositories listed at
@ -546,7 +546,7 @@ sub update_issue {
return $incremental;
}

sub topic_in_pu {
sub topic_in_seen {
my ($topic_desc) = @_;
for my $line (split(/\n/, $topic_desc)) {
if ($line =~ /^ [+-] /) {
@ -624,7 +624,7 @@ sub merge_cooking {
for my $topic (sort keys %{$current}) {
if (!exists $td->{$topic}) {
# Ignore new topics without anything merged
if (topic_in_pu($current->{$topic}{'desc'})) {
if (topic_in_seen($current->{$topic}{'desc'})) {
push @new_topic, $topic;
}
next;
@ -737,7 +737,7 @@ sub wildo {
if (/^\* (\S+) \(([-0-9]+)\) (\d+) commits?$/) {
wildo_flush_topic($in_section, \%what, $topic);

# tip-date, next-date, topic, count, pu-count
# tip-date, next-date, topic, count, seen-count
$topic = [$2, $too_recent, $1, $3, 0];
$in_desc = undef;
next;
@ -778,10 +778,10 @@ sub wildo {
for $topic (sort { (($a->[1] cmp $b->[1]) ||
($a->[0] cmp $b->[0])) }
@{$what{$what}}) {
my ($tip, $next, $name, $count, $pu) = @$topic;
my ($tip, $next, $name, $count, $seen) = @$topic;
my ($sign);
$tip =~ s/^\d{4}-//;
if (($next eq $too_recent) || (0 < $pu)) {
if (($next eq $too_recent) || (0 < $seen)) {
$sign = "-";
$next = " " x 6;
} else {

View File

@ -8,7 +8,7 @@ use Getopt::Long;

my $topic_pattern = '??*/*';
my $base = 'next';
my @stage = qw(next pu);
my @stage = qw(next seen);
my @mark = ('.', '?', '-', '+');
my $all = 0;
my $merges = 0;

View File

@ -2,7 +2,7 @@

. git-sh-setup

# Avoid duplicated test numbers --- checking 'pu' is enough
# Avoid duplicated test numbers --- checking 'seen' is enough
# as we will usually add, but never remove them.
added=$(
git diff-index --cached --name-only --diff-filter=A HEAD -- t |
@ -12,7 +12,7 @@ if test -n "$added"
then
bad=
exists=$(
git ls-tree --name-only pu:t |
git ls-tree --name-only seen:t |
sed -ne 's|^\(t[0-9][0-9][0-9][0-9]\)-.*\.sh$|\1|p' |
tr "\012" " "
)