[RFH] GSoC 2015 application

The response to my previous email was not overwhelming, but people did
express some interest in Git doing GSoC this year. So I've started on
the application, using last year's version as a template.

The materials are all in:

  https://github.com/git/git.github.io

If you'd like to help, I'm happy to take emailed patches, pull requests,
or just plain-English suggestions. If you want push access to that
repository, email me.

A draft of the application is here:

  http://git.github.io/SoC-2015-Org-Application.html

The questions are the same as last year, so with the exception of some
reviewing and updating for the new year, this shouldn't be too much
work. I do need somebody to volunteer as backup admin. This doesn't need
to involve any specific commitment, but is mostly about what to do if I
get hit by a bus. Of course helping with application review,
coordinating mentors, etc, is welcome from the backup admin.

Where I really need help now is in the "ideas" page:

  http://git.github.io/SoC-2015-Ideas.html

and the list of microprojects:

  http://git.github.io/SoC-2015-Microprojects.html

Note that I've listed microprojects as required for students this year
(whereas last year, we only strongly encouraged them). I think they
worked very well, but that requirement is up for debate.

We may be able to port over ideas or microprojects from last year, but I
want to do so only after somebody has confirmed that they are still in
need of doing. And of course new ideas and microprojects are very
welcome.

The students will not begin looking at these until the participating
projects are announced. But the GSoC folks _will_ be looking at the
Ideas page, which is linked from the application. So while we can tweak
it later, it needs to have content now (in the next 48 hours). So if you
must choose which to focus your efforts on, do Ideas first.

-Peff

Cc-ing this to the msysgit list, which I should have done in the first
place. Certainly ideas specific to Git for Windows would be welcome.

On Wed, Feb 18, 2015 at 02:14:17PM -0500, Jeff King wrote:

The response to my previous email was not overwhelming, but people did
express some interest in Git doing GSoC this year. So I've started on
the application, using last year's version as a template.

The materials are all in:

  https://github.com/git/git.github.io

If you'd like to help, I'm happy to take emailed patches, pull requests,
or just plain-English suggestions. If you want push access to that
repository, email me.

A draft of the application is here:

  http://git.github.io/SoC-2015-Org-Application.html

The questions are the same as last year, so with the exception of some
reviewing and updating for the new year, this shouldn't be too much
work. I do need somebody to volunteer as backup admin. This doesn't need
to involve any specific commitment, but is mostly about what to do if I
get hit by a bus. Of course helping with application review,
coordinating mentors, etc, is welcome from the backup admin.

Where I really need help now is in the "ideas" page:

  http://git.github.io/SoC-2015-Ideas.html

and the list of microprojects:

  http://git.github.io/SoC-2015-Microprojects.html

Note that I've listed microprojects as required for students this year
(whereas last year, we only strongly encouraged them). I think they
worked very well, but that requirement is up for debate.

We may be able to port over ideas or microprojects from last year, but I
want to do so only after somebody has confirmed that they are still in
need of doing. And of course new ideas and microprojects are very
welcome.

The students will not begin looking at these until the participating
projects are announced. But the GSoC folks _will_ be looking at the
Ideas page, which is linked from the application. So while we can tweak
it later, it needs to have content now (in the next 48 hours). So if you
must choose which to focus your efforts on, do Ideas first.

-Peff

On Thu, Feb 19, 2015 at 2:14 AM, Jeff King [off-list ref] wrote:

and the list of microprojects:

  http://git.github.io/SoC-2015-Microprojects.html

There is debian bug 777690 [1] that's basically about making tag's
version sort aware about -rc, -pre suffixes. I imagine it would touch
versioncmp.c and builtin/tag.c (to retrieve the suffixes from config
file).

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690
-- 
Duy

On 02/18/2015 08:14 PM, Jeff King wrote:

The response to my previous email was not overwhelming, but people did
express some interest in Git doing GSoC this year. So I've started on
the application, using last year's version as a template.

Regretfully, I can't in good conscience volunteer to be a GSoC mentor
this year. I have too many other projects going on and don't see how I
can free up enough time to be a good mentor.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu

On Fri, Feb 20, 2015 at 10:26:15AM +0700, Duy Nguyen wrote:

On Thu, Feb 19, 2015 at 2:14 AM, Jeff King [off-list ref] wrote:

quoted

and the list of microprojects:

  http://git.github.io/SoC-2015-Microprojects.html

There is debian bug 777690 [1] that's basically about making tag's
version sort aware about -rc, -pre suffixes. I imagine it would touch
versioncmp.c and builtin/tag.c (to retrieve the suffixes from config
file).

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690

I think that's a reasonable thing to work on, but it's too big for a
microproject and too small for a GSoC.

I think this could be an "extra credit" for the project to unify
for-each-ref, "tag -l", and "branch -l", though. That will vastly
enhance the supporting abilities the latter two (e.g., you could sort by
taggerdate).

-Peff

On Fri, Feb 20, 2015 at 06:35:09AM +0100, Michael Haggerty wrote:

On 02/18/2015 08:14 PM, Jeff King wrote:

quoted

The response to my previous email was not overwhelming, but people did
express some interest in Git doing GSoC this year. So I've started on
the application, using last year's version as a template.

Regretfully, I can't in good conscience volunteer to be a GSoC mentor
this year. I have too many other projects going on and don't see how I
can free up enough time to be a good mentor.

Thanks for letting us know. I am somewhat in the same boat. I might be
able to make time, but the bar that the student/project combo would have
to clear would be quite high for me to agree to do so.

This brings up an important issue. We cannot do GSoC without mentors. I
had hoped that people populating the "ideas" list would volunteer to
mentor for their projects.

But so far the possibilities are:

  - Stefan

  - me, who has already promised to be stingy

  - Matthieu, who also cited time constraints

  - Junio, who contributed some project ideas, but who in the past has
    declined to mentor in order to remain impartial as the maintainer
    who evaluates student results (which I think is quite reasonable)

So...basically 1 mentor and 2 reticent maybes? That doesn't look good.
We are not committed to anything until we accept student proposals,
of course. But I would not want to waste students' time in applying if
it is not realistic for us to accept them.

-Peff

On Thu, Feb 19, 2015 at 11:29 PM, Jeff King [off-list ref] wrote:

This brings up an important issue. We cannot do GSoC without mentors. I
had hoped that people populating the "ideas" list would volunteer to
mentor for their projects.

But so far the possibilities are:

  - Stefan

  - me, who has already promised to be stingy

  - Matthieu, who also cited time constraints

  - Junio, who contributed some project ideas, but who in the past has
    declined to mentor in order to remain impartial as the maintainer
    who evaluates student results (which I think is quite reasonable)

So...basically 1 mentor and 2 reticent maybes? That doesn't look good.

Indeed, the mentor panel looks particularly weak this year, if nobody
can afford the time for proper mentoring.

Even though I can indirectly help by giving reviews at a more hand-holding
level than usual, there is a limit. And I definitely do not foresee acting as a
mentor myself.

On Thu, Feb 19, 2015 at 11:13 PM, Jeff King [off-list ref] wrote:

quoted

There is debian bug 777690 [1] that's basically about making tag's
version sort aware about -rc, -pre suffixes. I imagine it would touch
versioncmp.c and builtin/tag.c (to retrieve the suffixes from config
file).

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690

I think that's a reasonable thing to work on, but it's too big for a
microproject and too small for a GSoC.

That is certainly too big as a Micro, but I do not think it is too small
for GSoC, if it is to be done right (meaning, not just implementing an
arbitrary version comparison hardwired, but design how to make it
extensible).

I have a feeling that I am complaining that student projects are
designed to be too grand and getting told that I am overly pessimistic
by everybody else every year. Perhaps this year others may prove
me wrong, if we can find mentors, that is ;-)

On Fri, Feb 20, 2015 at 12:26:29AM -0800, Junio C Hamano wrote:

On Thu, Feb 19, 2015 at 11:13 PM, Jeff King [off-list ref] wrote:

quoted

quoted

There is debian bug 777690 [1] that's basically about making tag's
version sort aware about -rc, -pre suffixes. I imagine it would touch
versioncmp.c and builtin/tag.c (to retrieve the suffixes from config
file).

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690

I think that's a reasonable thing to work on, but it's too big for a
microproject and too small for a GSoC.

That is certainly too big as a Micro, but I do not think it is too small
for GSoC, if it is to be done right (meaning, not just implementing an
arbitrary version comparison hardwired, but design how to make it
extensible).

I did write "maybe more of mini-size than micro" then looked at the
micro list again and somehow decided to delete that. Anyway while I
still have my attention on it, might as well do it.

My idea is to make it easy for the user to change the sort algorithm.
And it's probably intuitive to just substitute a string with
something. So if "1-rc1" is put incorrectly before "1.1" and you
realize that "1.999" ought to be the last one before "2". You could
tell git to internally replace "1-rc1" with "1.999".

This patch does that. The user feeds substitution rules via
versionsort.substitute config keys, e.g.

    git config versionsort.substitute "-rc .999"

Performance is not a concern because I don't think people would throw
100k tags to it. There are two issues I'm aware of but not addressed:

 - the order of substitution matters, but right now it's up in the air
 - case-sensitiveness may surprise users

-- 8< --

diff --git a/versioncmp.c b/versioncmp.c
index 7511e08..2419e38 100644
--- a/versioncmp.c
+++ b/versioncmp.c

@@ -1,4 +1,5 @@
 #include "cache.h"
+#include "strbuf.h"
 
 /*
  * versioncmp(): copied from string/strverscmp.c in glibc commit

@@ -20,6 +21,57 @@
 #define  CMP    2
 #define  LEN    3
 
+struct subst_rule
+{
+	const char *before;
+	const char *after;
+};
+static struct subst_rule *rules;
+static int rule_nr, rule_alloc;
+
+static int versioncmp_config(const char *k, const char *v, void *cb)
+{
+	char *p, *s;
+	if (strcmp(k, "versionsort.substitute"))
+		return 0;
+	ALLOC_GROW(rules, rule_nr + 1, rule_alloc);
+	s = xstrdup(v);
+	p = strchr(s, ' ');
+	if (!p)
+		return error("missing space in %s", v);
+	*p = '\0';
+	rules[rule_nr].before = s;
+	rules[rule_nr].after = p + 1;
+	rule_nr++;
+	return 0;
+}
+
+static char *substitute(const unsigned char **strp)
+{
+	struct strbuf sb = STRBUF_INIT;
+	const char *str = (const char *)*strp;
+	int i;
+	if (!rules) {
+		rules = xmalloc(sizeof(*rules));
+		rule_alloc = 1;
+		git_config(versioncmp_config, NULL);
+	}
+	for (i = 0; i < rule_nr; i++) {
+		const struct subst_rule *r = rules + i;
+		const char *p = strstr(str, r->before);
+		if (!p)
+			continue;
+		if (!sb.len)
+			strbuf_addstr(&sb, str);
+		strbuf_splice(&sb, p - str, strlen(r->before),
+			      r->after, strlen(r->after));
+		str = sb.buf;
+	}
+	if ((const unsigned char *)str == *strp)
+		return NULL;
+	*strp = (const unsigned char *)sb.buf;
+	return sb.buf;
+}
 
 /*
  * Compare S1 and S2 as strings holding indices/version numbers,

@@ -32,6 +84,7 @@ int versioncmp(const char *s1, const char *s2)
 {
 	const unsigned char *p1 = (const unsigned char *) s1;
 	const unsigned char *p2 = (const unsigned char *) s2;
+	char *free1, *free2;
 	unsigned char c1, c2;
 	int state, diff;
 

@@ -58,6 +111,8 @@ int versioncmp(const char *s1, const char *s2)
 
 	if (p1 == p2)
 		return 0;
+	free1 = substitute(&p1);
+	free2 = substitute(&p2);
 
 	c1 = *p1++;
 	c2 = *p2++;

@@ -75,6 +130,10 @@ int versioncmp(const char *s1, const char *s2)
 	}
 
 	state = result_type[state * 3 + (((c2 == '0') + (isdigit (c2) != 0)))];
+	if (state != LEN) {
+		free(free1);
+		free(free2);
+	}
 
 	switch (state) {
 	case CMP:

@@ -82,10 +141,16 @@ int versioncmp(const char *s1, const char *s2)
 
 	case LEN:
 		while (isdigit (*p1++))
-			if (!isdigit (*p2++))
+			if (!isdigit (*p2++)) {
+				free(free1);
+				free(free2);
 				return 1;
+			}
 
-		return isdigit (*p2) ? -1 : diff;
+		c2 = *p2;
+		free(free1);
+		free(free2);
+		return isdigit (c2) ? -1 : diff;
 
 	default:
 		return state;
-- 8< --

On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen [off-list ref] wrote:

My idea is to make it easy for the user to change the sort algorithm.
And it's probably intuitive to just substitute a string with
something. So if "1-rc1" is put incorrectly before "1.1" and you
realize that "1.999" ought to be the last one before "2". You could
tell git to internally replace "1-rc1" with "1.999".

This patch does that. The user feeds substitution rules via
versionsort.substitute config keys, e.g.

    git config versionsort.substitute "-rc .999"

I would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then
1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, ...
and then 1.1 (aka 1.1-final).

If 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does
it make 1 come after 1.99911, and 1.1.9992 come before 1.1?

I didn't read the patch text and perhaps the explanation above is the only
thing faulty about your message, or perhaps my reading is faulty and the
above describes a sound idea, but I do not see how the above makes sense.

On Sat, Feb 21, 2015 at 10:25 AM, Junio C Hamano [off-list ref] wrote:

On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen [off-list ref] wrote:

quoted

My idea is to make it easy for the user to change the sort algorithm.
And it's probably intuitive to just substitute a string with
something. So if "1-rc1" is put incorrectly before "1.1" and you
realize that "1.999" ought to be the last one before "2". You could
tell git to internally replace "1-rc1" with "1.999".

This patch does that. The user feeds substitution rules via
versionsort.substitute config keys, e.g.

    git config versionsort.substitute "-rc .999"

I would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then
1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, ...
and then 1.1 (aka 1.1-final).

If 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does
it make 1 come after 1.99911, and 1.1.9992 come before 1.1?

I didn't read the patch text and perhaps the explanation above is the only
thing faulty about your message, or perhaps my reading is faulty and the
above describes a sound idea, but I do not see how the above makes sense.

No, faulty thinking. Back to the whiteboard..

-- 
Duy

On Fri, Feb 20, 2015 at 7:33 PM, Duy Nguyen [off-list ref] wrote:

On Sat, Feb 21, 2015 at 10:25 AM, Junio C Hamano [off-list ref] wrote:

quoted

On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen [off-list ref] wrote:

quoted

My idea is to make it easy for the user to change the sort algorithm.
And it's probably intuitive to just substitute a string with
something. So if "1-rc1" is put incorrectly before "1.1" and you
realize that "1.999" ought to be the last one before "2". You could
tell git to internally replace "1-rc1" with "1.999".

This patch does that. The user feeds substitution rules via
versionsort.substitute config keys, e.g.

    git config versionsort.substitute "-rc .999"

I would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then
1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, ...
and then 1.1 (aka 1.1-final).

If 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does
it make 1 come after 1.99911, and 1.1.9992 come before 1.1?

I didn't read the patch text and perhaps the explanation above is the only
thing faulty about your message, or perhaps my reading is faulty and the
above describes a sound idea, but I do not see how the above makes sense.

No, faulty thinking. Back to the whiteboard..

One version of vercmp() I read went like this:

 (1) Chomp the version strings into an alternate runs of digits and
non-digits. e.g. 1.2.13 becomes
      "1", ".", "2", "." and "13" while 1.2.9 becomes "1", ".", "2",
"." and "9".
 (2) Compare corresponding elements with strcmp() for runs of
non-digits, and numerically for
      runs of digits. In the above example, up to the shared "1.2."
would compare equal, and the
      final run of digits, "13" and "9" are compared numerically and
we declare that 1.2.13 comes
      later.

I think you can add a twist by introducing "optionally this can
appear" substring. When there is
such an optional substring defined, you also define if the side that
lack the optional substring
comes before or after the side that has one. For example, you declare
"[-]rc" as "optional
substring that makes the owner of such a substring sort before others"
(call it "optional negative
substring") and comparing 2.0-rc12, 2.0-rc2 and 2.0:

 - "2.0" becomes "2", ".", "0" and "2.0-rc2" becomes "2", ".", "0",
"-rc", "2". Comparing them
   from left to right, the first difference is "lack of anything (2.0
side runs out tokens)" and
   "-rc", which is marked as optional negative. Hence 2.0-rc2 sorts before 2.0

 - "2.0-rc12" and "2.0-rc2" splits into tokens similarly. The first
difference you see will be
   after you match "-rc" and "-rc", which is "12" vs "2". Comparing
them numerically, you
   know "2.0-rc12" comes later.

You can define values to optional negatives and optional positives to
express a more
elaborate sort order e.g.

  1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1

even though "-post" does not have to be declared as optional positive.

Hi Peff,

On 2015-02-18 20:32, Jeff King wrote:

On Wed, Feb 18, 2015 at 02:14:17PM -0500, Jeff King wrote:

quoted

The response to my previous email was not overwhelming, but people did
express some interest in Git doing GSoC this year. So I've started on
the application, using last year's version as a template.

I feel unqualified to fill in the information, having kept out of the loop of the past years' GSoC efforts.

After considerable consideration, I am offering to mentor Windows-related projects (into which I count conversion of scripts into builtins).

Thanks,
Dscho

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

On Tue, Feb 24, 2015 at 01:01:17PM +0100, Johannes Schindelin wrote:

After considerable consideration, I am offering to mentor
Windows-related projects (into which I count conversion of scripts
into builtins).

Thanks! No rush, as we are not even accepted yet, but you can create a
profile at:

  http://google-melange.com

and ask to join the "git" project as a mentor.

You may also want to add Windows-specific ideas to the page at:

  https://github.com/git/git.github.io/blob/master/SoC-2015-Ideas.md

Even something high-level like "helping move programs to builtins to
help Windows" will let students know that it's a potential direction.

-Peff

Hi Peff,

On 2015-02-24 13:06, Jeff King wrote:

On Tue, Feb 24, 2015 at 01:01:17PM +0100, Johannes Schindelin wrote:

quoted

After considerable consideration, I am offering to mentor
Windows-related projects (into which I count conversion of scripts
into builtins).

Thanks! No rush, as we are not even accepted yet, but you can create a
profile at:

  http://google-melange.com

and ask to join the "git" project as a mentor.

I guess I can only ask that after the org is accepted, I will do so when (and if) that is the case.

You may also want to add Windows-specific ideas to the page at:

  https://github.com/git/git.github.io/blob/master/SoC-2015-Ideas.md

Even something high-level like "helping move programs to builtins to
help Windows" will let students know that it's a potential direction.

Done: https://github.com/git/git.github.io/pull/12

Thank you,
Dscho

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:

quoted

Thanks! No rush, as we are not even accepted yet, but you can create a
profile at:

  http://google-melange.com

and ask to join the "git" project as a mentor.

I guess I can only ask that after the org is accepted, I will do so
when (and if) that is the case.

I think you can do it now; I had to create the project profile in order
to do the application. But again, no rush.

Done: https://github.com/git/git.github.io/pull/12

Thanks, merged.

-Peff

Hi Peff,

On 2015-02-24 13:28, Jeff King wrote:

On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:

quoted

quoted

Thanks! No rush, as we are not even accepted yet, but you can create a
profile at:

  http://google-melange.com

and ask to join the "git" project as a mentor.

I guess I can only ask that after the org is accepted, I will do so
when (and if) that is the case.

I think you can do it now; I had to create the project profile in order
to do the application. But again, no rush.

I tried, but there are no orgs listed as of yet when I click "Make connection".

quoted

Done: https://github.com/git/git.github.io/pull/12

Thanks, merged.

I opened another PR, based on Mathieu's advice.

Ciao,
Dscho

----- Original Message -----

Hi Peff,

On 2015-02-24 13:28, Jeff King wrote:

quoted

On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:

quoted

quoted

Thanks! No rush, as we are not even accepted yet, but you can create a
profile at:

  http://google-melange.com

and ask to join the "git" project as a mentor.

I guess I can only ask that after the org is accepted, I will do so
when (and if) that is the case.

I think you can do it now; I had to create the project profile in order
to do the application. But again, no rush.

I tried, but there are no orgs listed as of yet when I click "Make
connection".

Not sure what it's supposed to look like, but I think if you give us your username we can invite you as mentor.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi Matthieu,

On 2015-02-25 11:25, Matthieu Moy wrote:

----- Original Message -----

quoted

On 2015-02-24 13:28, Jeff King wrote:

quoted

On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:

quoted

quoted

Thanks! No rush, as we are not even accepted yet, but you can create a
profile at:

  http://google-melange.com

and ask to join the "git" project as a mentor.

I guess I can only ask that after the org is accepted, I will do so
when (and if) that is the case.

I think you can do it now; I had to create the project profile in order
to do the application. But again, no rush.

I tried, but there are no orgs listed as of yet when I click "Make
connection".

Not sure what it's supposed to look like, but I think if you give us
your username we can invite you as mentor.

Thanks. My username is – surprise! – 'dscho' ;-)

Ciao,
Dscho

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
 Second round. Looking better. We can do
 "1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1" too but it relies on
 config key's loading order, a bit iffy.

 Documentation/config.txt |  7 +++++++
 t/t7004-tag.sh           | 28 +++++++++++++++++++++++++++
 versioncmp.c             | 50 ++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 85 insertions(+)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 04e2a71..8e078df 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt

@@ -2539,6 +2539,13 @@ user.signingkey::
 	This option is passed unchanged to gpg's --local-user parameter,
 	so you may specify a key using any method that gpg supports.
 
+versionsort.prereleaseSuffix::
+	When version sort is used in linkgit:git-tag[1], prerelease
+	tags (e.g. "1.0-rc1") may appear after the main release
+	"1.0". By specifying the suffix "-rc" in this variable,
+	"1.0-rc1" will appear before "1.0". One variable assignment
+	per suffix.
+
 web.browser::
 	Specify a web browser that may be used by some commands.
 	Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]

diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 35c805a..8bfeef9 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh

@@ -1459,6 +1459,34 @@ test_expect_success 'invalid sort parameter in configuratoin' '
 	test_cmp expect actual
 '
 
+test_expect_success 'version sort with prerelease reordering' '
+	git config --unset tag.sort &&
+	git config versionsort.prereleaseSuffix -rc &&
+	git tag foo1.6-rc1 &&
+	git tag foo1.6-rc2 &&
+	git tag -l --sort=version:refname "foo*" >actual &&
+	cat >expect <<-\EOF &&
+	foo1.3
+	foo1.6-rc1
+	foo1.6-rc2
+	foo1.6
+	foo1.10
+	EOF
+	test_cmp expect actual
+'
+
+test_expect_success 'reverse version sort with prerelease reordering' '
+	git tag -l --sort=-version:refname "foo*" >actual &&
+	cat >expect <<-\EOF &&
+	foo1.10
+	foo1.6
+	foo1.6-rc2
+	foo1.6-rc1
+	foo1.3
+	EOF
+	test_cmp expect actual
+'
+
 run_with_limited_stack () {
 	(ulimit -s 128 && "$@")
 }

diff --git a/versioncmp.c b/versioncmp.c
index 7511e08..80bfd10 100644
--- a/versioncmp.c
+++ b/versioncmp.c

@@ -1,4 +1,5 @@
 #include "cache.h"
+#include "string-list.h"
 
 /*
  * versioncmp(): copied from string/strverscmp.c in glibc commit

@@ -20,6 +21,48 @@
 #define  CMP    2
 #define  LEN    3
 
+static const struct string_list *prereleases;
+static int initialized;
+
+/*
+ * p1 and p2 point to the first different character in two strings. If
+ * either p1 or p2 starts with a prerelease suffix, it will be forced
+ * to be on top.
+ *
+ * If both p1 and p2 start with (different) suffix, the order is
+ * determined by config file.
+ *
+ * Note that we don't have to deal with the situation when both p1 and
+ * p2 start with the same suffix because the common part is already
+ * consumed by the caller.
+ *
+ * Return non-zero if *diff contains the return value for versioncmp()
+ */
+static int swap_prereleases(const void *p1_,
+			    const void *p2_,
+			    int *diff)
+{
+	const char *p1 = p1_;
+	const char *p2 = p2_;
+	int i, i1 = -1, i2 = -1;
+
+	for (i = 0; i < prereleases->nr; i++) {
+		const char *suffix = prereleases->items[i].string;
+		if (i1 == -1 && starts_with(p1, suffix))
+			i1 = i;
+		if (i2 == -1 && starts_with(p2, suffix))
+			i2 = i;
+	}
+	if (i1 == -1 && i2 == -1)
+		return 0;
+	if (i1 >= 0 && i2 >= 0)
+		*diff = i1 - i2;
+	else if (i1 >= 0)
+		*diff = -1;
+	else /* if (i2 >= 0) */
+		*diff = 1;
+	return 1;
+}
 
 /*
  * Compare S1 and S2 as strings holding indices/version numbers,

@@ -74,6 +117,13 @@ int versioncmp(const char *s1, const char *s2)
 		state += (c1 == '0') + (isdigit (c1) != 0);
 	}
 
+	if (!initialized) {
+		initialized = 1;
+		prereleases = git_config_get_value_multi("versionsort.prereleasesuffix");
+	}
+	if (prereleases && swap_prereleases(p1 - 1, p2 - 1, &diff))
+		return diff;
+
 	state = result_type[state * 3 + (((c2 == '0') + (isdigit (c2) != 0)))];
 
 	switch (state) {

-- 
2.3.0.rc1.137.g477eb31

On Thu, Feb 19, 2015 at 2:14 AM, Jeff King [off-list ref] wrote:

Where I really need help now is in the "ideas" page:

  http://git.github.io/SoC-2015-Ideas.html

Is this too ambitious for a summer? I suspect the answer is yes, but anyway..

Due to http limitations and stateless decision, a lot of data is sent
back and forth during have/want negotiation for smart-http. I wonder
if we could implement the "long polling" scheme in a CGI program. The
program terminates HTTP requests and recreates a full duplex
connection for upload-pack to talk to the client. upload-pack falls
back to the normal mode, used by git:// and ssh://.

An example of this is BOSH [1]. From a quick glance it does not seem
to require any special thing, so it's unlikely to cause problems with
firewalls, proxies.. If this is implemented as cgi (instead of http
server), we'll need to save session infos somewhere. I suppose shm
with proper locking is enough.

[1] http://xmpp.org/extensions/xep-0124.html
-- 
Duy

On Thu, Feb 26, 2015 at 08:10:38PM +0700, Duy Nguyen wrote:

On Thu, Feb 19, 2015 at 2:14 AM, Jeff King [off-list ref] wrote:

quoted

Where I really need help now is in the "ideas" page:

  http://git.github.io/SoC-2015-Ideas.html

Is this too ambitious for a summer? I suspect the answer is yes, but anyway..

Due to http limitations and stateless decision, a lot of data is sent
back and forth during have/want negotiation for smart-http. I wonder
if we could implement the "long polling" scheme in a CGI program. The
program terminates HTTP requests and recreates a full duplex
connection for upload-pack to talk to the client. upload-pack falls
back to the normal mode, used by git:// and ssh://.

So basically Git-over-TCP-over-HTTP? :)

That would be a nice thing to have, though looking over the BOSH link
(which this is my first exposure to), it does look rather complicated.
It's not clear to me how easily one could plug in an existing tunneling
solution, and just stick git programs at the endpoints (in other words,
let that solution manage all of the connection state and just present a
socketpair() to git).

I'm not sure it is too ambitious in terms of actual implementation time,
but I think the design work may exceed what most students are capable
of.

-Peff

On Wed, Mar 4, 2015 at 5:31 PM, Jeff King [off-list ref] wrote:

On Thu, Feb 26, 2015 at 08:10:38PM +0700, Duy Nguyen wrote:

quoted

On Thu, Feb 19, 2015 at 2:14 AM, Jeff King [off-list ref] wrote:

quoted

Where I really need help now is in the "ideas" page:

  http://git.github.io/SoC-2015-Ideas.html

Is this too ambitious for a summer? I suspect the answer is yes, but anyway..

Due to http limitations and stateless decision, a lot of data is sent
back and forth during have/want negotiation for smart-http. I wonder
if we could implement the "long polling" scheme in a CGI program. The
program terminates HTTP requests and recreates a full duplex
connection for upload-pack to talk to the client. upload-pack falls
back to the normal mode, used by git:// and ssh://.

So basically Git-over-TCP-over-HTTP? :)

Yes. The hidden agenda was, if it works well, we might be able to
deprecate smart-http one day. That day, if happens, would be in far
future though. By that time hopefully we could just use http2
insteadof tcp-over-http1.

I'm not sure it is too ambitious in terms of actual implementation time,
but I think the design work may exceed what most students are capable
of.

Not to mention that I think it can be man-in-the-middle attacked if
we're not careful (e.g. send to session token in unencrypted). Which
makes it less appealing to me.
-- 
Duy