Junio C Hamano <gitster@xxxxxxxxx> 于2020年4月13日周一 上午4:26写道：
> > +make_user_friendly_and_stable_output () {
> > + make_user_friendly_and_stable_output_common | sed \
> > + -e "s#To ../upstream.git#To <URL/of/upstream.git>#"
>
> Break the line immediately after the pipe, and begin the next line
> with the command. That way, the shell knows that you haven't
> finished giving the command at the end of the first line, and you do
> not have to use a backslash, i.e.
>
> make_user_friendly |
> sed -e 's/from/to/'
Will do.
> > + cd workbench &&
> > + # Try to make a stable fixed width for abbreviated commit ID,
> > + # this fixed-width oid will be replaced with "<OID>".
> > + git config core.abbrev 7 &&
> > + git remote add origin ../upstream.git &&
> > + git update-ref refs/heads/master $A &&
> > + git tag -m "v123" v123 $A &&
> > + git push origin \
> > + $B:refs/heads/master \
> > + $A:refs/heads/next
> > + ) &&
> > + TAG=$(git -C workbench rev-parse v123) &&
> > +
> > + # setup pre-receive hook
> > + cat >upstream.git/hooks/pre-receive <<-\EOF &&
>
> Use write_script and you don't need the chmod at the end.
Yes, it's tedious to write chmod again and again. Will replace all
the places for writing script.
> > + #!/bin/sh
> > +
> > + echo >&2 "# pre-receive hook"
> > +
> > + while read old new ref
> > + do
> > + echo >&2 "pre-receive< $old $new $ref"
> > + done
> > + EOF
>
> Perhaps "exec >&2" upfront?
This works for "pre-receive" and "post-receive" script. But in
"proc-receive" hook, stdout and stderr are different, and standard
output is used for protocol output.
> > diff --git a/t/t5411/common-functions.sh b/t/t5411/common-functions.sh
> > new file mode 100644
> > index 0000000000..6e400c0625
> > --- /dev/null
> > +++ b/t/t5411/common-functions.sh
> > @@ -0,0 +1,50 @@
>
> It is good that this omits "#!" and leaves the file without +x bit.
>
> > +# Format the output of git-push, git-show-ref and other commands to make a
> > +# user-friendly and stable text. We can easily prepare the expect text
> > +# without having to worry about future changes of the commit ID and spaces
> > +# of the output. We also replce single quotes with double quotes, because
> > +# it is boring to prepare unquoted single quotes in expect txt.
>
> s/txt/text/
Will do. Found it for a long time, but forgot to correct it.
> > + (starts_with(ref->name, "refs/tags/")
> > + ? "[new tag]"
> > + : (starts_with(ref->name, "refs/heads/")
> > + ? "[new branch]"
> > + : "[new reference]")),
> > + ref, ref->peer_ref, NULL, porcelain, summary_width);
>
> Now we say "outside refs/heads/ and refs/tags/, that's just a
> reference, different from branch". OK.
>
> Do we ever update refs/remotes/ with this codepath? Would we want
> to label it differently, i.e. as "remote-tracking branch"?
Can we call a reference (starts with "refs/remotes/") as a
remote-tracking branch, if it is on the remote side without a proper
remote and branch settings in .git/config?
Thanks.
