[re-send as text-only. sorry, new system]
On 9/14/11 10:49 AM, Junio C Hamano wrote:
The extra line in the pull request is cheap - it's not like we need to
> ration them. The above format, in contrast, requires that the person
> doing the*pull* have a recent enough git client, otherwise the merge
> commit message will be just horrible.
In a re-roll patch I've added ";# branch-name" at the end of that line for
people with older git, but existing git wouldn't allow you to fetch anything
but refs so you won't risk getting "just horrible" merge message;-)
If the system is watertight enough, then you could have verified pushes
ONLY under some new refspace, like:
refs/forks/forkid/branch
"forkid" is set up when you choose to "follow" someone's pushes. ie,
you say something like:
git fork follow linustorvalds@xxxxxxxx
<http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x17762C4676E21CBB>
"torvalds@xxxxxxxx" here representing a PGP key ID search string. It
could be instead, "0x17762c4676e21cbb"
And then the "refs/forks/linus/xxx" space gets populated as signed
pushes are seen on the network (perhaps when fetching from a pull
request, or perhaps via a service). A configuration option can be set
to warn if you are not merging a signed branch. If the new "pull
request/push" object is a distinct object type or tag object, then it
could be the destination of the 'refs/forks/...' ref, and the branch
desription and hence the default merge message be retrieved from that.
Sam
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html