Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stefan Beller <sbeller@xxxxxxxxxx> writes:

>> * sb/push-options (2016-07-12) 5 commits
>>  - add a test for push options
>>  - push: accept push options
>>  - SQUASH???
>
> Squash? I do not find a squashable commit in what you pushed,
> do you intend to squash the first 2 patches instead?

$ git log --oneline --first-parent master..pu | grep push-options
f8e50d4 Merge branch 'sb/push-options' into pu
$ git log --oneline master..f8e50d4^2
d6fd535 add a test for push options
ef00034 push: accept push options
6c5282d SQUASH???
ed0c716 receive-pack: implement advertising and receiving push options
f7c760f push options: {pre,post}-receive hook learns about push options
$ git show 6c5282d
commit 6c5282d7c5b50f362aaee2059c0253ab17b4fcd3
Author: Junio C Hamano <gitster@xxxxxxxxx>
Date:   Tue Jul 12 14:54:58 2016 -0700

    SQUASH???

diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 754db6e..4d8041a 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -1503,8 +1503,6 @@ static struct string_list *read_push_options(void)
 {
 	int i;
 	struct string_list *ret = xmalloc(sizeof(*ret));
-	string_list_init(ret, 1);
-
 	/* NEEDSWORK: expose the limitations to be configurable. */
 	int max_options = 32;
 
@@ -1518,6 +1516,7 @@ static struct string_list *read_push_options(void)
 	 */
 	int max_size = 1024;
 
+	string_list_init(ret, 1);
 	for (i = 0; i < max_options; i++) {
 		char *line;
 		int len;

i.e. compilation fix for decl-after-stmt.

>>  - receive-pack: implement advertising and receiving push options
>>  - push options: {pre,post}-receive hook learns about push options
>>
>>  "git push" learned to accept and pass extra options to the
>>  receiving end so that hooks can read and react to them.
>>
>>  Discussion continues, expecting a further reroll.
>>  ($gmane/299156)
>
> Yeah there were some late comments, so I did not reroll right away.
> I think Shawns proposal to have a receive.maxCommandBytes is a
> good way for an overall upper bound, but how does it stop us from
> going forward with this series?

If we were to do maxcommandbytes, then max_options would become
irrelevant, no?
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]