{"thread":{"id":"38591","subject":"[RFH] GSoC 2015 application","startedAt":"2015-02-18T19:14:17Z","lastAt":"2015-03-10T10:16:35Z","messageCount":74,"participants":["Jeff King","Junio C Hamano","Matthieu Moy","Duy Nguyen","Michael Haggerty","Dennis Kaarsemaker","Eric Sunshine","Johannes Schindelin","Stefan Beller","Michael J Gruber","Christian Couder","Nguyễn Thái Ngọc Duy","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"256301","messageId":"20150218191417.GA7767@peff.net","threadId":"38591","inReplyTo":null,"subject":"[RFH] GSoC 2015 application","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-02-18T19:14:17Z","receivedAt":"2015-02-18T19:14:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The response to my previous email was not overwhelming, but people did\nexpress some interest in Git doing GSoC this year. So I've started on\nthe application, using last year's version as a template.\n\nThe materials are all in:\n\n https://github.com/git/git.github.io\n\nIf you'd like to help, I'm happy to take emailed patches, pull requests,\nor just plain-English suggestions. If you want push access to that\nrepository, email me.\n\nA draft of the application is here:\n\n http://git.github.io/SoC-2015-Org-Application.html\n\nThe questions are the same as last year, so with the exception of some\nreviewing and updating for the new year, this shouldn't be too much\nwork. I do need somebody to volunteer as backup admin. This doesn't need\nto involve any specific commitment, but is mostly about what to do if I\nget hit by a bus. Of course helping with application review,\ncoordinating mentors, etc, is welcome from the backup admin.\n\nWhere I really need help now is in the \"ideas\" page:\n\n http://git.github.io/SoC-2015-Ideas.html\n\nand the list of microprojects:\n\n http://git.github.io/SoC-2015-Microprojects.html\n\nNote that I've listed microprojects as required for students this year\n(whereas last year, we only strongly encouraged them). I think they\nworked very well, but that requirement is up for debate.\n\nWe may be able to port over ideas or microprojects from last year, but I\nwant to do so only after somebody has confirmed that they are still in\nneed of doing. And of course new ideas and microprojects are very\nwelcome.\n\nThe students will not begin looking at these until the participating\nprojects are announced. But the GSoC folks _will_ be looking at the\nIdeas page, which is linked from the application. So while we can tweak\nit later, it needs to have content now (in the next 48 hours). So if you\nmust choose which to focus your efforts on, do Ideas first.\n\n-Peff\n"},{"id":"256307","messageId":"20150218193234.GA8298@peff.net","threadId":"38591","inReplyTo":"20150218191417.GA7767@peff.net","subject":"Re: [RFH] GSoC 2015 application","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-02-18T19:32:34Z","receivedAt":"2015-02-18T19:32:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Cc-ing this to the msysgit list, which I should have done in the first\nplace. Certainly ideas specific to Git for Windows would be welcome.\n\nOn Wed, Feb 18, 2015 at 02:14:17PM -0500, Jeff King wrote:\n\n> The response to my previous email was not overwhelming, but people did\n> express some interest in Git doing GSoC this year. So I've started on\n> the application, using last year's version as a template.\n> \n> The materials are all in:\n> \n> https://github.com/git/git.github.io\n> \n> If you'd like to help, I'm happy to take emailed patches, pull requests,\n> or just plain-English suggestions. If you want push access to that\n> repository, email me.\n> \n> A draft of the application is here:\n> \n> http://git.github.io/SoC-2015-Org-Application.html\n> \n> The questions are the same as last year, so with the exception of some\n> reviewing and updating for the new year, this shouldn't be too much\n> work. I do need somebody to volunteer as backup admin. This doesn't need\n> to involve any specific commitment, but is mostly about what to do if I\n> get hit by a bus. Of course helping with application review,\n> coordinating mentors, etc, is welcome from the backup admin.\n> \n> Where I really need help now is in the \"ideas\" page:\n> \n> http://git.github.io/SoC-2015-Ideas.html\n> \n> and the list of microprojects:\n> \n> http://git.github.io/SoC-2015-Microprojects.html\n> \n> Note that I've listed microprojects as required for students this year\n> (whereas last year, we only strongly encouraged them). I think they\n> worked very well, but that requirement is up for debate.\n> \n> We may be able to port over ideas or microprojects from last year, but I\n> want to do so only after somebody has confirmed that they are still in\n> need of doing. And of course new ideas and microprojects are very\n> welcome.\n> \n> The students will not begin looking at these until the participating\n> projects are announced. But the GSoC folks _will_ be looking at the\n> Ideas page, which is linked from the application. So while we can tweak\n> it later, it needs to have content now (in the next 48 hours). So if you\n> must choose which to focus your efforts on, do Ideas first.\n> \n> -Peff\n"},{"id":"256317","messageId":"xmqqlhju28de.fsf@gitster.dls.corp.google.com","threadId":"38591","inReplyTo":"20150218191417.GA7767@peff.net","subject":"Re: [RFH] GSoC 2015 application","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-18T21:54:37Z","receivedAt":"2015-02-18T21:54:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> and the list of microprojects:\n>\n> http://git.github.io/SoC-2015-Microprojects.html\n\nA few for micros.\n\ndiff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md\nindex b79a89f..f3b2b55 100644\n--- a/SoC-2015-Microprojects.md\n+++ b/SoC-2015-Microprojects.md\n@@ -107,4 +107,25 @@ suitable. Just remember to keep the change small! It is much better\n for you to finish a small but complete change than to try something\n too ambitious and not get it done.\n \n-**TODO** add entries\n+### Make \"git -C '' cmd\" not to barf.\n+\n+Instead, make it just like \"cd ''\", which is a no-op that silently\n+succeeds. Cf. $gmane/258109\n+\n+### Allow \"-\" as a short-hand for \"@{-1}\" in more places.\n+\n+Pick one command that operates on branch names. Teach it the \"-\"\n+shorthand that stands for \"the branch we were previously on\", like we\n+did for \"git merge -\" sometime after we introduced \"git checkout -\".\n+Cf. $gmane/230828\n+\n+### Make \"git diff --no-index $directory $file\" DWIM better.\n+\n+\"git diff --no-index $directory $directory/$file\" is obviously what\n+the user wanted.\n+\n+### Forbid \"log --graph --no-walk\"\n+\n+Because --graph is about connected history while --no-walk is about\n+discrete points. Cf. $gmane/216083\n+\n"},{"id":"256335","messageId":"CAPc5daVzmMnWOdctZeYLjxocnk2vrCrwmOyFvG13mB+zmVFQRQ@mail.gmail.com","threadId":"38591","inReplyTo":"xmqqlhju28de.fsf@gitster.dls.corp.google.com","subject":"Re: [RFH] GSoC 2015 application","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-19T05:49:08Z","receivedAt":"2015-02-19T05:49:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Wed, Feb 18, 2015 at 1:54 PM, Junio C Hamano wrote:\n>\n> A few for micros.\n>\n> +### Allow \"-\" as a short-hand for \"@{-1}\" in more places.\n> +\n> +Pick one command that operates on branch names. Teach it the \"-\"\n> +shorthand that stands for \"the branch we were previously on\", like we\n\nIn the same vein (people may have noticed that \"Pick one\" is meant to\nmake this into multiple micros ;-)\n\n### Use unsigned integral type for collection of bits.\n\nPick one field of a structure that (1) is of signed integral type and (2) is\nused as a collection of multiple bits. Discuss if there is a good reason\nwhy it has to be a signed integral field and change it to an unsigned\ntype otherwise. Cf. $gmane/263751\n"},{"id":"256340","messageId":"vpqzj8ary29.fsf@anie.imag.fr","threadId":"38591","inReplyTo":"20150218191417.GA7767@peff.net","subject":"Re: [RFH] GSoC 2015 application","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-02-19T10:32:46Z","receivedAt":"2015-02-19T10:32:46Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King writes:\n\n> I do need somebody to volunteer as backup admin. This doesn't need\n> to involve any specific commitment, but is mostly about what to do if I\n> get hit by a bus.\n\nIf you promise me to try hard not to be hit by a bus and no one else\nsteps in, I can be the backup admin.\n\n> Where I really need help now is in the \"ideas\" page:\n>\n> http://git.github.io/SoC-2015-Ideas.html\n\nThrowing out a few ideas for discussion, I can write something if people\nagree.\n\n* \"git bisect fixed/unfixed\", to allow bisecting a fix instead of a\n regression less painfully. There were already some proposed patches\n ( https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed ),\n so it shouldn't be too hard. Perhaps this item can be included in the\n \"git bisect --first-parent\" idea (turning it into \"git bisect\n improvements\").\n\n* Be nicer to the user on tracked/untracked merge conflicts\n\n I've had it on\n https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#Be_nicer_to_the_user_on_tracked.2Funtracked_merge_conflicts\n for a while but never got someone to do it.\n\n \"When merging a commit which has tracked files with the same name as local untracked files, Git refuses to proceed. It could be nice to:\n\n - Accept the situation without conflict when the tracked file has\n the exact same content as the local untracked file (which would\n become tracked). No data is lost, nothing can be committed\n accidentally.\n\n - Possibly, for fast-forward merges, if a local files belongs to the\n index but not to the last commit, attempt a merge between the\n upstream version and the local one (resulting in the same content\n as if the file had just been committed, but without introducing an\n extra commit). \n\n Recent versions SVN do something similar: on update, it considers\n added but not committed files like normal tracked files, and\n attempts a merge of the upstream version with the local one (which\n always succeeds when the files have identical content). Attempting a\n merge for non-fast forward cases would probably not make sense: it\n would mix changes coming from the merge with other changes that do\n not come from a commit.\"\n \n This shouldn't be technically too hard, but finding which behavior is\n right, where should things be customizeable and what the default value\n for the configuration should be will probably lead to interesting\n discussions. It contains two steps, which is good (all-or-nothing\n projects are much harder to deal with). The biggest drawback is that\n the first item may be simple for a GSoC while the second could be both\n controversial and hard to implement (depending on which solution is\n taken).\n\n> and the list of microprojects:\n>\n> http://git.github.io/SoC-2015-Microprojects.html\n\nHere are a few ideas, based on\nhttps://git.wiki.kernel.org/index.php/SmallProjectsIdeas\n\n-- >8 --\nFrom 513774754872436ea8b7eea63828b804c6a107e7 Mon Sep 17 00:00:00 2001\nFrom: Matthieu Moy \nDate: Thu, 19 Feb 2015 10:48:06 +0100\nSubject: [PATCH] 2015 microproject ideas\n\n---\n SoC-2015-Microprojects.md | 42 ++++++++++++++++++++++++++++++++++++++++++\n 1 file changed, 42 insertions(+)\n\ndiff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md\nindex 8cb6a8f..1abf595 100644\n--- a/SoC-2015-Microprojects.md\n+++ b/SoC-2015-Microprojects.md\n@@ -128,3 +128,45 @@ the user wanted.\n \n Because --graph is about connected history while --no-walk is about\n discrete points. Cf. $gmane/216083\n+\n+### Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git\n+\n+Most of git dotfiles can be located, at the user's option, in\n+~/. or in ~/.config/git/, following the [XDG\n+standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).\n+~/.git-credentials and ~/.git-credential-cache are still hardcoded as\n+~/., and should allow using the XDG directory layout too\n+(~/.git-credentials could be allowed as ~/.config/git/credential and\n+~/.git-credential-cache could be allowed as ~/.cache/git/credential,\n+possibly modified by $XDG_CONFIG_HOME and $XDG_CACHE_HOME).\n+\n+Each of these files can be a microproject of its own. The suggested\n+approach is:\n+\n+* See how XDG was implemented for other files (run \"git log --grep\n+ XDG\" in Git's source code) and read the XDG specification.\n+\n+* Implement and test the new behavior, without breaking compatibility\n+ with the old behavior.\n+\n+* Update the documentation\n+\n+### Add configuration options for some commonly used command-line options\n+\n+This includes:\n+\n+* git am -3\n+\n+* git am -c\n+\n+Some people always run the command with these options, and would\n+prefer to be able to activate them by default in ~/.gitconfig.\n+\n+### Add more builtin patterns for userdiff\n+\n+\"git diff\" shows the function name corresponding to each hunk after\n+the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...),\n+the way to find the function name is built-in Git's source code as\n+regular expressions (see userdiff.c). A few languages are common\n+enough to deserve a built-in driver, but are not yet recognized. For\n+example, CSS, shell.\n-- \n2.0.2.737.gfb43bde\n\n\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"256380","messageId":"20150220020022.GC16124@peff.net","threadId":"38591","inReplyTo":"vpqzj8ary29.fsf@anie.imag.fr","subject":"Re: [RFH] GSoC 2015 application","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-02-20T02:00:22Z","receivedAt":"2015-02-20T02:00:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 19, 2015 at 11:32:46AM +0100, Matthieu Moy wrote:\n\n> > I do need somebody to volunteer as backup admin. This doesn't need\n> > to involve any specific commitment, but is mostly about what to do if I\n> > get hit by a bus.\n> \n> If you promise me to try hard not to be hit by a bus and no one else\n> steps in, I can be the backup admin.\n\nThanks. I need you to register and create a profile at:\n\n https://www.google-melange.com/gsoc/homepage/google/gsoc2015\n\nand tell me your username (the information from last year does not carry\nforward automatically). Then I mark you as backup admin and (I think)\nyou have to then accept.\n\n> Throwing out a few ideas for discussion, I can write something if people\n> agree.\n> \n> * \"git bisect fixed/unfixed\", to allow bisecting a fix instead of a\n> regression less painfully. There were already some proposed patches\n> ( https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed ),\n> so it shouldn't be too hard. Perhaps this item can be included in the\n> \"git bisect --first-parent\" idea (turning it into \"git bisect\n> improvements\").\n\nThat seems like a reasonable topic. I was about to say \"but it's much\nmore complicated than fix/unfixed...\" but it looks like that wiki entry\ncovers the past discussion (and reading and understanding that would be\na first step for the student). I agree it's probably smaller than a\nfull-summer project and can get lumped into the other bisect idea.\n\n> * Be nicer to the user on tracked/untracked merge conflicts\n> [...]\n\nSounds OK to me, though I agree the merging of untracked files is a\nlittle controversial. There are also a lot of corner cases in\nmerge-recursive, and I think still some documented cases where we can\noverwrite untracked files. Maybe a more encompassing project would be to\norganize and dig into some of those corner cases.\n\n> SoC-2015-Microprojects.md | 42 ++++++++++++++++++++++++++++++++++++++++++\n> 1 file changed, 42 insertions(+)\n\nThanks, applied, although...\n\n> +### Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git\n> +\n> +Most of git dotfiles can be located, at the user's option, in\n> +~/. or in ~/.config/git/, following the [XDG\n> +standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).\n> +~/.git-credentials and ~/.git-credential-cache are still hardcoded as\n> +~/., and should allow using the XDG directory layout too\n> +(~/.git-credentials could be allowed as ~/.config/git/credential and\n> +~/.git-credential-cache could be allowed as ~/.cache/git/credential,\n> +possibly modified by $XDG_CONFIG_HOME and $XDG_CACHE_HOME).\n> +\n> +Each of these files can be a microproject of its own. The suggested\n> +approach is:\n> +\n> +* See how XDG was implemented for other files (run \"git log --grep\n> + XDG\" in Git's source code) and read the XDG specification.\n> +\n> +* Implement and test the new behavior, without breaking compatibility\n> + with the old behavior.\n> +\n> +* Update the documentation\n\nI think these might be getting a little larger than \"micro\". That's OK\nif the student can handle it, but we may want to mark them as such. I'll\nleave it for now, though, as we have a bit more breathing room on the\nmicroprojects.\n\n> +### Add configuration options for some commonly used command-line options\n> +\n> +This includes:\n> +\n> +* git am -3\n> +\n> +* git am -c\n> +\n> +Some people always run the command with these options, and would\n> +prefer to be able to activate them by default in ~/.gitconfig.\n\nThe direction here seems reasonable, though I think we have\nmailinfo.scissors already, so \"-c\" may not be a good example.\n\n> +### Add more builtin patterns for userdiff\n> +\n> +\"git diff\" shows the function name corresponding to each hunk after\n> +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...),\n> +the way to find the function name is built-in Git's source code as\n> +regular expressions (see userdiff.c). A few languages are common\n> +enough to deserve a built-in driver, but are not yet recognized. For\n> +example, CSS, shell.\n\nI am not sure that understanding the horrible regexes involved in some\nuserdiff counts as \"micro\", but OK. :)\n\n-Peff\n"},{"id":"256381","messageId":"CACsJy8B_zkAecL2Wag8a5c9-_C9eoA9dYj4ciBXqXRVmRW77zw@mail.gmail.com","threadId":"38591","inReplyTo":"20150218191417.GA7767@peff.net","subject":"Re: [RFH] GSoC 2015 application","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-02-20T03:26:15Z","receivedAt":"2015-02-20T03:26:15Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Feb 19, 2015 at 2:14 AM, Jeff King wrote:\n> and the list of microprojects:\n>\n> http://git.github.io/SoC-2015-Microprojects.html\n>\n\nThere is debian bug 777690 [1] that's basically about making tag's\nversion sort aware about -rc, -pre suffixes. I imagine it would touch\nversioncmp.c and builtin/tag.c (to retrieve the suffixes from config\nfile).\n\n[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690\n-- \nDuy\n"},{"id":"256384","messageId":"54E6C78D.3070506@alum.mit.edu","threadId":"38591","inReplyTo":"20150218191417.GA7767@peff.net","subject":"Re: [RFH] GSoC 2015 application","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2015-02-20T05:35:09Z","receivedAt":"2015-02-20T05:35:09Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/18/2015 08:14 PM, Jeff King wrote:\n> The response to my previous email was not overwhelming, but people did\n> express some interest in Git doing GSoC this year. So I've started on\n> the application, using last year's version as a template.\n\nRegretfully, I can't in good conscience volunteer to be a GSoC mentor\nthis year. I have too many other projects going on and don't see how I\ncan free up enough time to be a good mentor.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\n"},{"id":"256386","messageId":"20150220071342.GB8763@peff.net","threadId":"38591","inReplyTo":"CACsJy8B_zkAecL2Wag8a5c9-_C9eoA9dYj4ciBXqXRVmRW77zw@mail.gmail.com","subject":"Re: [RFH] GSoC 2015 application","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-02-20T07:13:42Z","receivedAt":"2015-02-20T07:13:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 20, 2015 at 10:26:15AM +0700, Duy Nguyen wrote:\n\n> On Thu, Feb 19, 2015 at 2:14 AM, Jeff King wrote:\n> > and the list of microprojects:\n> >\n> > http://git.github.io/SoC-2015-Microprojects.html\n> >\n> \n> There is debian bug 777690 [1] that's basically about making tag's\n> version sort aware about -rc, -pre suffixes. I imagine it would touch\n> versioncmp.c and builtin/tag.c (to retrieve the suffixes from config\n> file).\n> \n> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690\n\nI think that's a reasonable thing to work on, but it's too big for a\nmicroproject and too small for a GSoC.\n\nI think this could be an \"extra credit\" for the project to unify\nfor-each-ref, \"tag -l\", and \"branch -l\", though. That will vastly\nenhance the supporting abilities the latter two (e.g., you could sort by\ntaggerdate).\n\n-Peff\n"},{"id":"256387","messageId":"20150220072924.GC8763@peff.net","threadId":"38591","inReplyTo":"54E6C78D.3070506@alum.mit.edu","subject":"Re: [RFH] GSoC 2015 application","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-02-20T07:29:25Z","receivedAt":"2015-02-20T07:29:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 20, 2015 at 06:35:09AM +0100, Michael Haggerty wrote:\n\n> On 02/18/2015 08:14 PM, Jeff King wrote:\n> > The response to my previous email was not overwhelming, but people did\n> > express some interest in Git doing GSoC this year. So I've started on\n> > the application, using last year's version as a template.\n> \n> Regretfully, I can't in good conscience volunteer to be a GSoC mentor\n> this year. I have too many other projects going on and don't see how I\n> can free up enough time to be a good mentor.\n\nThanks for letting us know. I am somewhat in the same boat. I might be\nable to make time, but the bar that the student/project combo would have\nto clear would be quite high for me to agree to do so.\n\nThis brings up an important issue. We cannot do GSoC without mentors. I\nhad hoped that people populating the \"ideas\" list would volunteer to\nmentor for their projects.\n\nBut so far the possibilities are:\n\n - Stefan\n\n - me, who has already promised to be stingy\n\n - Matthieu, who also cited time constraints\n\n - Junio, who contributed some project ideas, but who in the past has\n declined to mentor in order to remain impartial as the maintainer\n who evaluates student results (which I think is quite reasonable)\n\nSo...basically 1 mentor and 2 reticent maybes? That doesn't look good.\nWe are not committed to anything until we accept student proposals,\nof course. But I would not want to waste students' time in applying if\nit is not realistic for us to accept them.\n\n-Peff\n"},{"id":"256389","messageId":"CAPc5daVUqHd4YAJh9TyMZ8Og12ZGj1A9v=qpVNa+kV6E6U16Mg@mail.gmail.com","threadId":"38591","inReplyTo":"20150220072924.GC8763@peff.net","subject":"Re: [RFH] GSoC 2015 application","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-20T08:06:21Z","receivedAt":"2015-02-20T08:06:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Thu, Feb 19, 2015 at 11:29 PM, Jeff King wrote:\n>\n> This brings up an important issue. We cannot do GSoC without mentors. I\n> had hoped that people populating the \"ideas\" list would volunteer to\n> mentor for their projects.\n>\n> But so far the possibilities are:\n>\n> - Stefan\n>\n> - me, who has already promised to be stingy\n>\n> - Matthieu, who also cited time constraints\n>\n> - Junio, who contributed some project ideas, but who in the past has\n> declined to mentor in order to remain impartial as the maintainer\n> who evaluates student results (which I think is quite reasonable)\n>\n> So...basically 1 mentor and 2 reticent maybes? That doesn't look good.\n\nIndeed, the mentor panel looks particularly weak this year, if nobody\ncan afford the time for proper mentoring.\n\nEven though I can indirectly help by giving reviews at a more hand-holding\nlevel than usual, there is a limit. And I definitely do not foresee acting as a\nmentor myself.\n"},{"id":"256392","messageId":"CAPc5daVJ_nYk=tWqpUYPpsX6Z50H429jOh8QfMwUdNDdTDMq9w@mail.gmail.com","threadId":"38591","inReplyTo":"20150220071342.GB8763@peff.net","subject":"Re: [RFH] GSoC 2015 application","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-20T08:26:29Z","receivedAt":"2015-02-20T08:26:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Thu, Feb 19, 2015 at 11:13 PM, Jeff King wrote:\n\n>> There is debian bug 777690 [1] that's basically about making tag's\n>> version sort aware about -rc, -pre suffixes. I imagine it would touch\n>> versioncmp.c and builtin/tag.c (to retrieve the suffixes from config\n>> file).\n>>\n>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690\n>\n> I think that's a reasonable thing to work on, but it's too big for a\n> microproject and too small for a GSoC.\n\nThat is certainly too big as a Micro, but I do not think it is too small\nfor GSoC, if it is to be done right (meaning, not just implementing an\narbitrary version comparison hardwired, but design how to make it\nextensible).\n\nI have a feeling that I am complaining that student projects are\ndesigned to be too grand and getting told that I am overly pessimistic\nby everybody else every year. Perhaps this year others may prove\nme wrong, if we can find mentors, that is ;-)\n"},{"id":"256393","messageId":"vpqpp94exb5.fsf@anie.imag.fr","threadId":"38591","inReplyTo":"20150220072924.GC8763@peff.net","subject":"Re: [RFH] GSoC 2015 application","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-02-20T09:39:42Z","receivedAt":"2015-02-20T09:39:42Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King writes:\n\n> - Matthieu, who also cited time constraints\n\nJust to clarify: last year we were co-mentoring with Ram. I ended up\nhaving a lot of time and did most of the work (not blaming Ram, and I\nenjoyed the experience). I'm still motivated to co-mentor, but this time\nthe co-mentoring has to be more balanced (or unballanced to the other\nmentor ;-) ).\n\n> - Junio, who contributed some project ideas, but who in the past has\n> declined to mentor in order to remain impartial as the maintainer\n> who evaluates student results (which I think is quite reasonable)\n\nYes, as a mentor I did appreciate having Junio as impartial\nmaintainer/reviewer. And he did for sure contribute even without being a\nmentor!\n\n>From your list, it seems we can target 1 or 2 slots. I'd say it's still\nworth applying, but if we don't find more mentors then perhaps it would\nmake sense to say so explicitely in\nhttp://git.github.io/SoC-2015-Ideas.html so that students looking for\norganization know that we'll have very few slots.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"256394","messageId":"20150220094844.GB30127@peff.net","threadId":"38591","inReplyTo":"vpqpp94exb5.fsf@anie.imag.fr","subject":"Re: [RFH] GSoC 2015 application","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-02-20T09:48:44Z","receivedAt":"2015-02-20T09:48:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 20, 2015 at 10:39:42AM +0100, Matthieu Moy wrote:\n\n> Jeff King writes:\n> \n> > - Matthieu, who also cited time constraints\n> \n> Just to clarify: last year we were co-mentoring with Ram. I ended up\n> having a lot of time and did most of the work (not blaming Ram, and I\n> enjoyed the experience). I'm still motivated to co-mentor, but this time\n> the co-mentoring has to be more balanced (or unballanced to the other\n> mentor ;-) ).\n\nYes, but who is your co-mentor this year? :)\n\n> From your list, it seems we can target 1 or 2 slots. I'd say it's still\n> worth applying, but if we don't find more mentors then perhaps it would\n> make sense to say so explicitely in\n> http://git.github.io/SoC-2015-Ideas.html so that students looking for\n> organization know that we'll have very few slots.\n\nI don't mind doing 1 slot if that's what we have resources for. But if\nwe have to say \"eh, we do not really have enough mentors to support\nyou\", then I wonder if it is worth doing. They do not know how many\npeople have applied, or how tight the competition is.\n\n-Peff\n"},{"id":"256395","messageId":"vpqwq3cdhhe.fsf@anie.imag.fr","threadId":"38591","inReplyTo":"20150220020022.GC16124@peff.net","subject":"Re: [RFH] GSoC 2015 application","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-02-20T10:06:53Z","receivedAt":"2015-02-20T10:06:53Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King writes:\n\n>> * Be nicer to the user on tracked/untracked merge conflicts\n>> [...]\n>\n> Sounds OK to me, though I agree the merging of untracked files is a\n> little controversial.\n\nYes. To me, part of the project is to identify cases where this is\nactually not controversial (OTOH, it's a bit frustrating when I do a\ntrivial pull and Git complains because I already have the file).\n\n>> +### Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git\n>> +\n>> +Most of git dotfiles can be located, at the user's option, in\n>> +~/. or in ~/.config/git/, following the [XDG\n>> +standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).\n>> +~/.git-credentials and ~/.git-credential-cache are still hardcoded as\n>> +~/., and should allow using the XDG directory layout too\n>> +(~/.git-credentials could be allowed as ~/.config/git/credential and\n>> +~/.git-credential-cache could be allowed as ~/.cache/git/credential,\n>> +possibly modified by $XDG_CONFIG_HOME and $XDG_CACHE_HOME).\n>> +\n>> +Each of these files can be a microproject of its own. The suggested\n>> +approach is:\n>> +\n>> +* See how XDG was implemented for other files (run \"git log --grep\n>> + XDG\" in Git's source code) and read the XDG specification.\n>> +\n>> +* Implement and test the new behavior, without breaking compatibility\n>> + with the old behavior.\n>> +\n>> +* Update the documentation\n>\n> I think these might be getting a little larger than \"micro\".\n\nThe ~/.git-credential-cache may be a bit harder, but the case of\n~/.git-credentials should follow the same pattern as files for which\nthis is already done. So, doing it by mimicking existing code shouldn't\nbe too hard.\n\nBut maybe that's me being optimistic ;-).\n\n>> +### Add configuration options for some commonly used command-line options\n>> +\n>> +This includes:\n>> +\n>> +* git am -3\n>> +\n>> +* git am -c\n>> +\n>> +Some people always run the command with these options, and would\n>> +prefer to be able to activate them by default in ~/.gitconfig.\n>\n> The direction here seems reasonable, though I think we have\n> mailinfo.scissors already, so \"-c\" may not be a good example.\n\nAh, indeed. The documentation makes it a bit hard to find, but I'll send\na patch.\n\n>> +### Add more builtin patterns for userdiff\n>> +\n>> +\"git diff\" shows the function name corresponding to each hunk after\n>> +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...),\n>> +the way to find the function name is built-in Git's source code as\n>> +regular expressions (see userdiff.c). A few languages are common\n>> +enough to deserve a built-in driver, but are not yet recognized. For\n>> +example, CSS, shell.\n>\n> I am not sure that understanding the horrible regexes involved in some\n> userdiff counts as \"micro\", but OK. :)\n\nI agree the regexes are horrible, but here also the project is not about\ndoing something really new, but reproducing what has already been done\nfor others.\n\nAt least, students not fluent with regular expressions have a pointer to\nuserdiff.c and can quickly see that the microproject is not meant for\nthem ;-).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"256401","messageId":"1424427763.30155.28.camel@kaarsemaker.net","threadId":"38591","inReplyTo":"vpqwq3cdhhe.fsf@anie.imag.fr","subject":"Re: [RFH] GSoC 2015 application","fromName":"Dennis Kaarsemaker","fromEmail":"dennis@kaarsemaker.net","sentAt":"2015-02-20T10:22:43Z","receivedAt":"2015-02-20T10:22:43Z","isPatch":false,"sender":{"key":"dennis@kaarsemaker.net","avatar":"https://avatars.githubusercontent.com/u/200649?v=4"},"body":"On vr, 2015-02-20 at 11:06 +0100, Matthieu Moy wrote:\n> The ~/.git-credential-cache may be a bit harder, but the case of\n> ~/.git-credentials should follow the same pattern as files for which\n> this is already done. So, doing it by mimicking existing code\n> shouldn't\n> be too hard.\n> \n> But maybe that's me being optimistic ;-)\n\nHaving just copied that logic to one of my tools, I reaclly would have\nfount if useful to have something that, given a config file name tells\nyou where it should be, maybe in the resident kitchen-sink that is\nrev-parse:\n\n$ git rev-parse --config git\n/home/dennis/.gitconfig\n$ git rev-parse --config gitk\n/home/dennis/.gitk\n$ git rev-parse --config foobar\n/home/dennis/.foobar\n\nOr, when XDG config files are used:\n\n$ git rev-parse --config gitk\n/home/dennis/.config/git/gitk\n$ git rev-parse --config git\n/home/dennis/.config/git/config\n$ git rev-parse --config foobar\n/home/dennis/.config/git/foobar\n\nSo, ~/.$filename or $XDG_CONFIG_HOME/git/filename, with a special case\nonly for git itself, with consistent selection of which to use\n(currently gitk and git are inconsistent).\n\n-- \nDennis Kaarsemaker\nhttp://www.kaarsemaker.net\n"},{"id":"256405","messageId":"1424428317-1682-1-git-send-email-Matthieu.Moy@imag.fr","threadId":"38591","inReplyTo":"20150220020022.GC16124@peff.net","subject":"[PATCH 1/3] microprojects: tweaks after discussion with Peff","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2015-02-20T10:31:55Z","receivedAt":"2015-02-20T10:31:55Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Signed-off-by: Matthieu Moy \n---\n SoC-2015-Microprojects.md | 8 ++++++--\n 1 file changed, 6 insertions(+), 2 deletions(-)\n\ndiff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md\nindex e49cb07..c6123bb 100644\n--- a/SoC-2015-Microprojects.md\n+++ b/SoC-2015-Microprojects.md\n@@ -158,14 +158,16 @@ approach is:\n \n * Update the documentation\n \n+Even though the amount of code to write is small, these projects\n+involve a lot of prior work to understand the specification and deal\n+with all potential corner-cases.\n+\n ### Add configuration options for some commonly used command-line options\n \n This includes:\n \n * git am -3\n \n-* git am -c\n-\n Some people always run the command with these options, and would\n prefer to be able to activate them by default in ~/.gitconfig.\n \n@@ -177,3 +179,5 @@ the way to find the function name is built-in Git's source code as\n regular expressions (see userdiff.c). A few languages are common\n enough to deserve a built-in driver, but are not yet recognized. For\n example, CSS, shell.\n+\n+This project requires a very good knowledge of regular expressions.\n-- \n2.3.0.157.g79e124b\n"},{"id":"256406","messageId":"1424428317-1682-2-git-send-email-Matthieu.Moy@imag.fr","threadId":"38591","inReplyTo":"1424428317-1682-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 2/3] GSoC ideas: git bisect fixed/unfixed","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2015-02-20T10:31:56Z","receivedAt":"2015-02-20T10:31:56Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Signed-off-by: Matthieu Moy \n---\n SoC-2015-Ideas.md | 45 ++++++++++++++++++++++++++++++++++++++++++++-\n 1 file changed, 44 insertions(+), 1 deletion(-)\n\ndiff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md\nindex a3e988e..4641800 100644\n--- a/SoC-2015-Ideas.md\n+++ b/SoC-2015-Ideas.md\n@@ -34,7 +34,9 @@ should be honored without checking the ownership. Cf. $gmane/243628\n Takes eol attributes into account to correct lossage/addition of CR at\n the end of line, with updates to \"am\". Cf. $gmane/257445\n \n-### \"git bisect --first-parent\".\n+### git bisect improvements\n+\n+#### \"git bisect --first-parent\".\n \n When your project is strictly \"new features are merged into trunk,\n never the other way around\", it is handy to be able to first find\n@@ -42,6 +44,47 @@ a merge on the trunk that merged a topic to point fingers at when\n a bug appears, instead of having to drill down to the individual\n commit on the faulty side branch.\n \n+#### \"git bisect fixed/unfixed\"\n+\n+\"git bisect\" is initially meant to find regressions (i.e. the new code\n+is bad, and the old one used to work). The opposite may happen too:\n+look for the commit which fixed a bug. It is already possible using\n+\"git bisect\", but the user has to type \"good\" to mean \"the bug is\n+there\" and \"bad\" to mean \"the bug is fixed\", which isn't convenient.\n+\n+It would be nice to allow the user to explicitely say \"git bisect\n+fixed\" and \"git bisect unfixed\" instead. It is actually much harder\n+than defining \"fixed\"/\"unfixed\" as aliases for \"bad\"/\"good\".\n+\n+A patch for this feature was sent to the mailing list in this thread a\n+few years ago by Dscho:\n+http://thread.gmane.org/gmane.comp.version-control.git/86063\n+\n+Unfortunately there were some problems with the patch and no one tried\n+to fix them. So the same problem/suggestion is often reported on the\n+mailing list, for example:\n+\n+ http://thread.gmane.org/gmane.comp.version-control.git/165141\n+ http://thread.gmane.org/gmane.comp.version-control.git/170113\n+ http://thread.gmane.org/gmane.comp.version-control.git/182398 \n+\n+A patch series to let \"old/new\" be used instead of \"good/bad\" was\n+started here:\n+\n+http://thread.gmane.org/gmane.comp.version-control.git/199758/focus=199869\n+\n+There is still work to be done to complete it.\n+\n+Note than another feature with the name \"git bisect fix\" was suggested\n+to do something else:\n+\n+http://thread.gmane.org/gmane.comp.version-control.git/169026\n+\n+Since there have already been discussions and patches, the remaining\n+work is probably less than a GSoC, so this project should be grouped\n+with another one (like git bisect --first-parent) to make a full GSoC\n+proposal.\n+\n ### Unifying `git branch -l`, `git tag -l`, and `git for-each-ref`\n \n These three commands are all about selecting a subset of a repository's\n-- \n2.3.0.157.g79e124b\n"},{"id":"256404","messageId":"1424428317-1682-3-git-send-email-Matthieu.Moy@imag.fr","threadId":"38591","inReplyTo":"1424428317-1682-1-git-send-email-Matthieu.Moy@imag.fr","subject":"[PATCH 3/3] idea: Be nicer to the user on tracked/untracked merge conflicts","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2015-02-20T10:31:57Z","receivedAt":"2015-02-20T10:31:57Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Signed-off-by: Matthieu Moy \n---\n SoC-2015-Ideas.md | 27 +++++++++++++++++++++++++++\n 1 file changed, 27 insertions(+)\n\ndiff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md\nindex 4641800..86de476 100644\n--- a/SoC-2015-Ideas.md\n+++ b/SoC-2015-Ideas.md\n@@ -117,3 +117,30 @@ Cf. $gmane/213180 $gmane/212950\n ### Introduce threading to checkout codepath, possibly helping Windows folks.\n \n Cf. $gmane/235874\n+\n+### Be nicer to the user on tracked/untracked merge conflicts\n+\n+When merging a commit which has tracked files with the same name as\n+local untracked files, Git refuses to proceed. It could be nice to:\n+\n+ - Accept the situation without conflict when the tracked file has the\n+ exact same content as the local untracked file (which would become\n+ tracked). No data is lost, nothing can be committed accidentally.\n+\n+ - Possibly, for fast-forward merges, if a local files belongs to the\n+ index but not to the last commit, attempt a merge between the\n+ upstream version and the local one (resulting in the same content\n+ as if the file had just been committed, but without introducing an\n+ extra commit).\n+\n+Recent versions SVN do something similar: on update, it considers\n+added but not committed files like normal tracked files, and attempts\n+a merge of the upstream version with the local one (which always\n+succeeds when the files have identical content). Attempting a merge\n+for non-fast forward cases would probably not make sense: it would mix\n+changes coming from the merge with other changes that do not come from\n+a commit.\n+\n+One difficulty with this project is to identify uncontroversial cases\n+(where Git should merge without complaining) and all the possible\n+corner-cases.\n-- \n2.3.0.157.g79e124b\n"},{"id":"256407","messageId":"vpqmw48c1ms.fsf@anie.imag.fr","threadId":"38591","inReplyTo":"1424427763.30155.28.camel@kaarsemaker.net","subject":"Re: [RFH] GSoC 2015 application","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-02-20T10:34:35Z","receivedAt":"2015-02-20T10:34:35Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Dennis Kaarsemaker writes:\n\n> given a config file name tells\n> you where it should be, maybe in the resident kitchen-sink that is\n> rev-parse:\n\nIt's actually a bit harder than this, since when both XDG and ~/.\nexist, we read from both but write to one only. So there's not just one\nanswer to the question.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"256449","messageId":"20150220113538.GA5491@peff.net","threadId":"38591","inReplyTo":"20150220094844.GB30127@peff.net","subject":"Re: [RFH] GSoC 2015 application","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-02-20T11:35:38Z","receivedAt":"2015-02-20T11:35:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 20, 2015 at 04:48:44AM -0500, Jeff King wrote:\n\n> > From your list, it seems we can target 1 or 2 slots. I'd say it's still\n> > worth applying, but if we don't find more mentors then perhaps it would\n> > make sense to say so explicitely in\n> > http://git.github.io/SoC-2015-Ideas.html so that students looking for\n> > organization know that we'll have very few slots.\n> \n> I don't mind doing 1 slot if that's what we have resources for. But if\n> we have to say \"eh, we do not really have enough mentors to support\n> you\", then I wonder if it is worth doing. They do not know how many\n> people have applied, or how tight the competition is.\n\nSo that being said, I did complete the application. We can still\nwithdraw if we want before students start applying, or we can put a\ndisclaimer on the ideas page.\n\nI tweaked the application text to update it for this year, but nothing\ntoo major. The result is at:\n\n http://git.github.io/SoC-2015-Org-Application.html\n\nThat content was cut-and-pasted into Google's application interface.\nMatthieu, as backup admin you should have access to tweak that if there\nare typos, etc (and I will probably not be available to apply fixes from\nnow until the deadline, so please do so if you see anything).\n\nWe can continue to improve the ideas page as time goes on. At some point\nGoogle will look at as part of the application, but probably not right\nat the deadline. :)\n\n-Peff\n"},{"id":"256445","messageId":"CAPig+cR_OaJGAR--04YWW1KHm+1UA7q7O9e4TTcZksGo9s4+8w@mail.gmail.com","threadId":"38591","inReplyTo":"vpqwq3cdhhe.fsf@anie.imag.fr","subject":"Re: [RFH] GSoC 2015 application","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-02-20T23:06:29Z","receivedAt":"2015-02-20T23:06:29Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Feb 20, 2015 at 5:06 AM, Matthieu Moy\n wrote:\n> Jeff King writes:\n>> I think these might be getting a little larger than \"micro\".\n>\n> The ~/.git-credential-cache may be a bit harder, but the case of\n> ~/.git-credentials should follow the same pattern as files for which\n> this is already done. So, doing it by mimicking existing code shouldn't\n> be too hard.\n>\n> But maybe that's me being optimistic ;-).\n\nAs a person who did a significant number of GSoC 2014 micro-project\nreviews (as well as many actual GSoC reviews), I probably ought to\nweigh in and say that this may be too optimistic. In fact, most of the\nGSoC 2015 micro-project suggestions[1] seem far too large and\ninvolved.\n\nFor 2014, most of the GSoC micro-projects were extremely simple, of\nthe form \"replace starts_with() with skip_prefix()\", yet most\napplicants still required three or four (or more) attempts to get it\nright (and some never did), even with extremely detailed hand-holding\nreviews at each step. (And, such reviews are quite time-consuming. I\nwas allocating six to eight hours each day to those reviews, yet I\ncouldn't keep up with all the submissions.)\n\nAlthough quite simple, many of the 2014 micro-projects[2]\n(particularly from Michael Haggerty) had a bit of a twist (or trick\nquestion) thrown in, requiring a tad more thought and effort than mere\nmechanical search-and-replace. That was useful because it helped\nidentify potentially acceptable candidates more easily, however, that\nadded twist was probably a good upper limit on difficulty for\nmicro-projects.\n\nAnother important aspect of 2014's micro-projects was that they could\nbe accomplished with only very localized knowledge: that is, a student\ncould read the logic of the one function being touched and learn\nenough to be successful. The micro-projects did not require global\nknowledge of Git internals or hours of research.\n\nThe attitude in 2014 was that it was important for students to get a\ntaste of what it is like working on the Git project and what would be\nexpected of them as submitters, and for GSoC administrators and\nmentors to get a feel for the applicants by how they interacted with\nreviewers. By going through the review process on a project with high\nengineering standards, it also was hope that students would learn and\nbenefit from the experience even if not selected. Extremely simple\nmicro-projects (possibly with a twist) in the style of 2014's were\nmore than sufficient to satisfy these goals, and were more than enough\nto consume significant reviewer time. The suggested 2015's\nmicro-projects seem far in excess.\n\n[1]: http://git.github.io/SoC-2015-Microprojects.html\n[2]: http://git.github.io/SoC-2014-Microprojects.html\n"},{"id":"256450","messageId":"20150221030209.GA567@lanh","threadId":"38591","inReplyTo":"CAPc5daVJ_nYk=tWqpUYPpsX6Z50H429jOh8QfMwUdNDdTDMq9w@mail.gmail.com","subject":"Support customized reordering in version sort","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-02-21T03:02:10Z","receivedAt":"2015-02-21T03:02:10Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Feb 20, 2015 at 12:26:29AM -0800, Junio C Hamano wrote:\n> On Thu, Feb 19, 2015 at 11:13 PM, Jeff King wrote:\n> \n> >> There is debian bug 777690 [1] that's basically about making tag's\n> >> version sort aware about -rc, -pre suffixes. I imagine it would touch\n> >> versioncmp.c and builtin/tag.c (to retrieve the suffixes from config\n> >> file).\n> >>\n> >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690\n> >\n> > I think that's a reasonable thing to work on, but it's too big for a\n> > microproject and too small for a GSoC.\n> \n> That is certainly too big as a Micro, but I do not think it is too small\n> for GSoC, if it is to be done right (meaning, not just implementing an\n> arbitrary version comparison hardwired, but design how to make it\n> extensible).\n\nI did write \"maybe more of mini-size than micro\" then looked at the\nmicro list again and somehow decided to delete that. Anyway while I\nstill have my attention on it, might as well do it.\n\nMy idea is to make it easy for the user to change the sort algorithm.\nAnd it's probably intuitive to just substitute a string with\nsomething. So if \"1-rc1\" is put incorrectly before \"1.1\" and you\nrealize that \"1.999\" ought to be the last one before \"2\". You could\ntell git to internally replace \"1-rc1\" with \"1.999\".\n\nThis patch does that. The user feeds substitution rules via\nversionsort.substitute config keys, e.g.\n\n git config versionsort.substitute \"-rc .999\"\n\nPerformance is not a concern because I don't think people would throw\n100k tags to it. There are two issues I'm aware of but not addressed:\n\n - the order of substitution matters, but right now it's up in the air\n - case-sensitiveness may surprise users\n\n-- 8< --\ndiff --git a/versioncmp.c b/versioncmp.c\nindex 7511e08..2419e38 100644\n--- a/versioncmp.c\n+++ b/versioncmp.c\n@@ -1,4 +1,5 @@\n #include \"cache.h\"\n+#include \"strbuf.h\"\n \n /*\n * versioncmp(): copied from string/strverscmp.c in glibc commit\n@@ -20,6 +21,57 @@\n #define CMP 2\n #define LEN 3\n \n+struct subst_rule\n+{\n+\tconst char *before;\n+\tconst char *after;\n+};\n+static struct subst_rule *rules;\n+static int rule_nr, rule_alloc;\n+\n+static int versioncmp_config(const char *k, const char *v, void *cb)\n+{\n+\tchar *p, *s;\n+\tif (strcmp(k, \"versionsort.substitute\"))\n+\t\treturn 0;\n+\tALLOC_GROW(rules, rule_nr + 1, rule_alloc);\n+\ts = xstrdup(v);\n+\tp = strchr(s, ' ');\n+\tif (!p)\n+\t\treturn error(\"missing space in %s\", v);\n+\t*p = '\\0';\n+\trules[rule_nr].before = s;\n+\trules[rule_nr].after = p + 1;\n+\trule_nr++;\n+\treturn 0;\n+}\n+\n+static char *substitute(const unsigned char **strp)\n+{\n+\tstruct strbuf sb = STRBUF_INIT;\n+\tconst char *str = (const char *)*strp;\n+\tint i;\n+\tif (!rules) {\n+\t\trules = xmalloc(sizeof(*rules));\n+\t\trule_alloc = 1;\n+\t\tgit_config(versioncmp_config, NULL);\n+\t}\n+\tfor (i = 0; i < rule_nr; i++) {\n+\t\tconst struct subst_rule *r = rules + i;\n+\t\tconst char *p = strstr(str, r->before);\n+\t\tif (!p)\n+\t\t\tcontinue;\n+\t\tif (!sb.len)\n+\t\t\tstrbuf_addstr(&sb, str);\n+\t\tstrbuf_splice(&sb, p - str, strlen(r->before),\n+\t\t\t r->after, strlen(r->after));\n+\t\tstr = sb.buf;\n+\t}\n+\tif ((const unsigned char *)str == *strp)\n+\t\treturn NULL;\n+\t*strp = (const unsigned char *)sb.buf;\n+\treturn sb.buf;\n+}\n \n /*\n * Compare S1 and S2 as strings holding indices/version numbers,\n@@ -32,6 +84,7 @@ int versioncmp(const char *s1, const char *s2)\n {\n \tconst unsigned char *p1 = (const unsigned char *) s1;\n \tconst unsigned char *p2 = (const unsigned char *) s2;\n+\tchar *free1, *free2;\n \tunsigned char c1, c2;\n \tint state, diff;\n \n@@ -58,6 +111,8 @@ int versioncmp(const char *s1, const char *s2)\n \n \tif (p1 == p2)\n \t\treturn 0;\n+\tfree1 = substitute(&p1);\n+\tfree2 = substitute(&p2);\n \n \tc1 = *p1++;\n \tc2 = *p2++;\n@@ -75,6 +130,10 @@ int versioncmp(const char *s1, const char *s2)\n \t}\n \n \tstate = result_type[state * 3 + (((c2 == '0') + (isdigit (c2) != 0)))];\n+\tif (state != LEN) {\n+\t\tfree(free1);\n+\t\tfree(free2);\n+\t}\n \n \tswitch (state) {\n \tcase CMP:\n@@ -82,10 +141,16 @@ int versioncmp(const char *s1, const char *s2)\n \n \tcase LEN:\n \t\twhile (isdigit (*p1++))\n-\t\t\tif (!isdigit (*p2++))\n+\t\t\tif (!isdigit (*p2++)) {\n+\t\t\t\tfree(free1);\n+\t\t\t\tfree(free2);\n \t\t\t\treturn 1;\n+\t\t\t}\n \n-\t\treturn isdigit (*p2) ? -1 : diff;\n+\t\tc2 = *p2;\n+\t\tfree(free1);\n+\t\tfree(free2);\n+\t\treturn isdigit (c2) ? -1 : diff;\n \n \tdefault:\n \t\treturn state;\n-- 8< --\n"},{"id":"256451","messageId":"CAPc5daXtmvfgkFA_YeQxunjSWYGUQB0uWCQVgfxMP_M9fB9qEw@mail.gmail.com","threadId":"38591","inReplyTo":"20150221030209.GA567@lanh","subject":"Re: Support customized reordering in version sort","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-21T03:25:59Z","receivedAt":"2015-02-21T03:25:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen wrote:\n>\n> My idea is to make it easy for the user to change the sort algorithm.\n> And it's probably intuitive to just substitute a string with\n> something. So if \"1-rc1\" is put incorrectly before \"1.1\" and you\n> realize that \"1.999\" ought to be the last one before \"2\". You could\n> tell git to internally replace \"1-rc1\" with \"1.999\".\n>\n> This patch does that. The user feeds substitution rules via\n> versionsort.substitute config keys, e.g.\n>\n> git config versionsort.substitute \"-rc .999\"\n\nI would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then\n1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, ...\nand then 1.1 (aka 1.1-final).\n\nIf 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does\nit make 1 come after 1.99911, and 1.1.9992 come before 1.1?\n\nI didn't read the patch text and perhaps the explanation above is the only\nthing faulty about your message, or perhaps my reading is faulty and the\nabove describes a sound idea, but I do not see how the above makes sense.\n"},{"id":"256452","messageId":"CACsJy8BFZ2O62f+QofSqZRoQ9BOX0SLnXHY_g93iMnyikW8H7g@mail.gmail.com","threadId":"38591","inReplyTo":"CAPc5daXtmvfgkFA_YeQxunjSWYGUQB0uWCQVgfxMP_M9fB9qEw@mail.gmail.com","subject":"Re: Support customized reordering in version sort","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-02-21T03:33:03Z","receivedAt":"2015-02-21T03:33:03Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Feb 21, 2015 at 10:25 AM, Junio C Hamano wrote:\n> On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen wrote:\n>>\n>> My idea is to make it easy for the user to change the sort algorithm.\n>> And it's probably intuitive to just substitute a string with\n>> something. So if \"1-rc1\" is put incorrectly before \"1.1\" and you\n>> realize that \"1.999\" ought to be the last one before \"2\". You could\n>> tell git to internally replace \"1-rc1\" with \"1.999\".\n>>\n>> This patch does that. The user feeds substitution rules via\n>> versionsort.substitute config keys, e.g.\n>>\n>> git config versionsort.substitute \"-rc .999\"\n>\n> I would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then\n> 1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, ...\n> and then 1.1 (aka 1.1-final).\n>\n> If 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does\n> it make 1 come after 1.99911, and 1.1.9992 come before 1.1?\n>\n> I didn't read the patch text and perhaps the explanation above is the only\n> thing faulty about your message, or perhaps my reading is faulty and the\n> above describes a sound idea, but I do not see how the above makes sense.\n\nNo, faulty thinking. Back to the whiteboard..\n\n-- \nDuy\n"},{"id":"256457","messageId":"CAPc5daVJJcC--mwq0PfAczge3zG44ToDKP853FkyZ3x1KUfsig@mail.gmail.com","threadId":"38591","inReplyTo":"CACsJy8BFZ2O62f+QofSqZRoQ9BOX0SLnXHY_g93iMnyikW8H7g@mail.gmail.com","subject":"Re: Support customized reordering in version sort","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-21T05:12:49Z","receivedAt":"2015-02-21T05:12:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Fri, Feb 20, 2015 at 7:33 PM, Duy Nguyen wrote:\n> On Sat, Feb 21, 2015 at 10:25 AM, Junio C Hamano wrote:\n>> On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen wrote:\n>>>\n>>> My idea is to make it easy for the user to change the sort algorithm.\n>>> And it's probably intuitive to just substitute a string with\n>>> something. So if \"1-rc1\" is put incorrectly before \"1.1\" and you\n>>> realize that \"1.999\" ought to be the last one before \"2\". You could\n>>> tell git to internally replace \"1-rc1\" with \"1.999\".\n>>>\n>>> This patch does that. The user feeds substitution rules via\n>>> versionsort.substitute config keys, e.g.\n>>>\n>>> git config versionsort.substitute \"-rc .999\"\n>>\n>> I would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then\n>> 1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, ...\n>> and then 1.1 (aka 1.1-final).\n>>\n>> If 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does\n>> it make 1 come after 1.99911, and 1.1.9992 come before 1.1?\n>>\n>> I didn't read the patch text and perhaps the explanation above is the only\n>> thing faulty about your message, or perhaps my reading is faulty and the\n>> above describes a sound idea, but I do not see how the above makes sense.\n>\n> No, faulty thinking. Back to the whiteboard..\n\nOne version of vercmp() I read went like this:\n\n (1) Chomp the version strings into an alternate runs of digits and\nnon-digits. e.g. 1.2.13 becomes\n \"1\", \".\", \"2\", \".\" and \"13\" while 1.2.9 becomes \"1\", \".\", \"2\",\n\".\" and \"9\".\n (2) Compare corresponding elements with strcmp() for runs of\nnon-digits, and numerically for\n runs of digits. In the above example, up to the shared \"1.2.\"\nwould compare equal, and the\n final run of digits, \"13\" and \"9\" are compared numerically and\nwe declare that 1.2.13 comes\n later.\n\nI think you can add a twist by introducing \"optionally this can\nappear\" substring. When there is\nsuch an optional substring defined, you also define if the side that\nlack the optional substring\ncomes before or after the side that has one. For example, you declare\n\"[-]rc\" as \"optional\nsubstring that makes the owner of such a substring sort before others\"\n(call it \"optional negative\nsubstring\") and comparing 2.0-rc12, 2.0-rc2 and 2.0:\n\n - \"2.0\" becomes \"2\", \".\", \"0\" and \"2.0-rc2\" becomes \"2\", \".\", \"0\",\n\"-rc\", \"2\". Comparing them\n from left to right, the first difference is \"lack of anything (2.0\nside runs out tokens)\" and\n \"-rc\", which is marked as optional negative. Hence 2.0-rc2 sorts before 2.0\n\n - \"2.0-rc12\" and \"2.0-rc2\" splits into tokens similarly. The first\ndifference you see will be\n after you match \"-rc\" and \"-rc\", which is \"12\" vs \"2\". Comparing\nthem numerically, you\n know \"2.0-rc12\" comes later.\n\nYou can define values to optional negatives and optional positives to\nexpress a more\nelaborate sort order e.g.\n\n 1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1\n\neven though \"-post\" does not have to be declared as optional positive.\n"},{"id":"256459","messageId":"xmqqh9ufygdt.fsf@gitster.dls.corp.google.com","threadId":"38591","inReplyTo":"CAPc5daVJJcC--mwq0PfAczge3zG44ToDKP853FkyZ3x1KUfsig@mail.gmail.com","subject":"Re: Support customized reordering in version sort","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-21T05:37:18Z","receivedAt":"2015-02-21T05:37:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> You can define values to optional negatives and optional positives to\n> express a more\n> elaborate sort order e.g.\n>\n> 1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1\n>\n> even though \"-post\" does not have to be declared as optional positive.\n\n... that is, you say \"-pre\" is a more negative optional than \"-rc\"\nthat is also a negative optional.\n"},{"id":"256498","messageId":"vpqfv9xxdfx.fsf@anie.imag.fr","threadId":"38591","inReplyTo":"20150220113538.GA5491@peff.net","subject":"Re: [RFH] GSoC 2015 application","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-02-23T08:02:58Z","receivedAt":"2015-02-23T08:02:58Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King writes:\n\n> So that being said, I did complete the application. We can still\n> withdraw if we want before students start applying, or we can put a\n> disclaimer on the ideas page.\n\nI'm in favor of the disclaimer, but I won't fight if other people think\nit's better to just withdraw.\n\n> That content was cut-and-pasted into Google's application interface.\n> Matthieu, as backup admin you should have access to tweak that if there\n> are typos, etc (and I will probably not be available to apply fixes from\n> now until the deadline, so please do so if you see anything).\n\nI do have access to the text here:\n\n http://www.google-melange.com/gsoc/org/survey_response/show/google/gsoc2015/git\n\nbut I did not find an \"edit\" button. I can edit\n\n http://www.google-melange.com/gsoc/org/profile/edit/google/gsoc2015/git\n\nOTOH.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"256513","messageId":"20150223153604.GA19129@peff.net","threadId":"38591","inReplyTo":"vpqfv9xxdfx.fsf@anie.imag.fr","subject":"Re: [RFH] GSoC 2015 application","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-02-23T15:36:04Z","receivedAt":"2015-02-23T15:36:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 23, 2015 at 09:02:58AM +0100, Matthieu Moy wrote:\n\n> > That content was cut-and-pasted into Google's application interface.\n> > Matthieu, as backup admin you should have access to tweak that if there\n> > are typos, etc (and I will probably not be available to apply fixes from\n> > now until the deadline, so please do so if you see anything).\n> \n> I do have access to the text here:\n> \n> http://www.google-melange.com/gsoc/org/survey_response/show/google/gsoc2015/git\n> \n> but I did not find an \"edit\" button. I can edit\n> \n> http://www.google-melange.com/gsoc/org/profile/edit/google/gsoc2015/git\n> \n> OTOH.\n\nI think it's just because the application period has ended, so our\nanswers to the questions are frozen.\n\n-Peff\n"},{"id":"256566","messageId":"5f6dbabdf4da3c3c757d92ba00a8b7d1@www.dscho.org","threadId":"38591","inReplyTo":"20150218193234.GA8298@peff.net","subject":"Re: Re: [RFH] GSoC 2015 application","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-02-24T12:01:17Z","receivedAt":"2015-02-24T12:01:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn 2015-02-18 20:32, Jeff King wrote:\n\n> On Wed, Feb 18, 2015 at 02:14:17PM -0500, Jeff King wrote:\n> \n>> The response to my previous email was not overwhelming, but people did\n>> express some interest in Git doing GSoC this year. So I've started on\n>> the application, using last year's version as a template.\n\nI feel unqualified to fill in the information, having kept out of the loop of the past years' GSoC efforts.\n\nAfter considerable consideration, I am offering to mentor Windows-related projects (into which I count conversion of scripts into builtins).\n\nThanks,\nDscho\n\n-- \n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n\n--- \nYou received this message because you are subscribed to the Google Groups \"Git for Windows\" group.\nTo unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.\nFor more options, visit https://groups.google.com/d/optout.\n"},{"id":"256567","messageId":"20150224120607.GA1906@peff.net","threadId":"38591","inReplyTo":"5f6dbabdf4da3c3c757d92ba00a8b7d1@www.dscho.org","subject":"Re: [msysGit] Re: [RFH] GSoC 2015 application","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-02-24T12:06:08Z","receivedAt":"2015-02-24T12:06:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 24, 2015 at 01:01:17PM +0100, Johannes Schindelin wrote:\n\n> After considerable consideration, I am offering to mentor\n> Windows-related projects (into which I count conversion of scripts\n> into builtins).\n\nThanks! No rush, as we are not even accepted yet, but you can create a\nprofile at:\n\n http://google-melange.com\n\nand ask to join the \"git\" project as a mentor.\n\nYou may also want to add Windows-specific ideas to the page at:\n\n https://github.com/git/git.github.io/blob/master/SoC-2015-Ideas.md\n\nEven something high-level like \"helping move programs to builtins to\nhelp Windows\" will let students know that it's a potential direction.\n\n-Peff\n"},{"id":"256570","messageId":"ed760450b06fd41c8bcaea7aaf526b94@www.dscho.org","threadId":"38591","inReplyTo":"20150224120607.GA1906@peff.net","subject":"Re: Re: [RFH] GSoC 2015 application","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-02-24T12:25:32Z","receivedAt":"2015-02-24T12:25:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn 2015-02-24 13:06, Jeff King wrote:\n> On Tue, Feb 24, 2015 at 01:01:17PM +0100, Johannes Schindelin wrote:\n> \n>> After considerable consideration, I am offering to mentor\n>> Windows-related projects (into which I count conversion of scripts\n>> into builtins).\n> \n> Thanks! No rush, as we are not even accepted yet, but you can create a\n> profile at:\n> \n> http://google-melange.com\n> \n> and ask to join the \"git\" project as a mentor.\n\nI guess I can only ask that after the org is accepted, I will do so when (and if) that is the case.\n\n> You may also want to add Windows-specific ideas to the page at:\n> \n> https://github.com/git/git.github.io/blob/master/SoC-2015-Ideas.md\n> \n> Even something high-level like \"helping move programs to builtins to\n> help Windows\" will let students know that it's a potential direction.\n\nDone: https://github.com/git/git.github.io/pull/12\n\nThank you,\nDscho\n\n-- \n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n\n--- \nYou received this message because you are subscribed to the Google Groups \"Git for Windows\" group.\nTo unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.\nFor more options, visit https://groups.google.com/d/optout.\n"},{"id":"256571","messageId":"20150224122846.GA2631@peff.net","threadId":"38591","inReplyTo":"ed760450b06fd41c8bcaea7aaf526b94@www.dscho.org","subject":"Re: [msysGit] Re: [RFH] GSoC 2015 application","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-02-24T12:28:46Z","receivedAt":"2015-02-24T12:28:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:\n\n> > Thanks! No rush, as we are not even accepted yet, but you can create a\n> > profile at:\n> > \n> > http://google-melange.com\n> > \n> > and ask to join the \"git\" project as a mentor.\n> \n> I guess I can only ask that after the org is accepted, I will do so\n> when (and if) that is the case.\n\nI think you can do it now; I had to create the project profile in order\nto do the application. But again, no rush.\n\n> Done: https://github.com/git/git.github.io/pull/12\n\nThanks, merged.\n\n-Peff\n"},{"id":"256581","messageId":"vpqioerz03s.fsf@anie.imag.fr","threadId":"38591","inReplyTo":"5f6dbabdf4da3c3c757d92ba00a8b7d1@www.dscho.org","subject":"Re: Re: [RFH] GSoC 2015 application","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-02-24T17:32:39Z","receivedAt":"2015-02-24T17:32:39Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Johannes Schindelin writes:\n\n> After considerable consideration, I am offering to mentor\n> Windows-related projects (into which I count conversion of scripts\n> into builtins).\n\nGood news!\n\nAbout the proposal:\n\n The idea of this project is to dive into the Git source code and\n convert, say, git-add--interactive.perl and/or git stash into proper C\n code, making it a so-called \"built-in\".\n\nMy advice would be to try converting several small scripts, and avoid\ntargetting a big one. This way, you can have a first patch series\nreviewed on-list, and merged in pu rather soon. From my experience, an\nearly review is very important to get the student on track, and\nsplitting the GSoC into multiple related projects avoids the situation\nwhere you have the feature \"95% completed\" at the end of the GSoC, but\nnothing merged.\n\nadd--interactive and stash are relatively complex beasts, perhaps\ngit-pull.sh would be easier to start with.\n\nOTOH, you know which script would be most useful to be converted into a\nbuiltin much better than me!\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n\n-- \n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n\n--- \nYou received this message because you are subscribed to the Google Groups \"Git for Windows\" group.\nTo unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.\nFor more options, visit https://groups.google.com/d/optout.\n"},{"id":"256582","messageId":"CAPc5daXTLRZW-uk++ZjbtafbR6SB41dyc0Cu1gN=Qy7CEhOq-A@mail.gmail.com","threadId":"38591","inReplyTo":"vpqioerz03s.fsf@anie.imag.fr","subject":"Re: Re: [RFH] GSoC 2015 application","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-24T18:25:12Z","receivedAt":"2015-02-24T18:25:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy\n wrote:\n> About the proposal:\n>\n> The idea of this project is to dive into the Git source code and\n> convert, say, git-add--interactive.perl and/or git stash into proper C\n> code, making it a so-called \"built-in\".\n>\n> My advice would be to try converting several small scripts, and avoid\n> targetting a big one....\n> add--interactive and stash are relatively complex beasts, perhaps\n> git-pull.sh would be easier to start with.\n\nYeah, I think that is a very good suggestion.\n\nAlso drop \"proper\" as if scripted Porcelains are second class citizens ;-)\n\n-- \n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n\n--- \nYou received this message because you are subscribed to the Google Groups \"Git for Windows\" group.\nTo unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.\nFor more options, visit https://groups.google.com/d/optout.\n"},{"id":"256591","messageId":"c9ff859363d2d637b3607aaf6cb9295d@www.dscho.org","threadId":"38591","inReplyTo":"CAPc5daXTLRZW-uk++ZjbtafbR6SB41dyc0Cu1gN=Qy7CEhOq-A@mail.gmail.com","subject":"Re: Re: [RFH] GSoC 2015 application","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-02-24T20:33:13Z","receivedAt":"2015-02-24T20:33:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn 2015-02-24 19:25, Junio C Hamano wrote:\n> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy\n> wrote:\n>> About the proposal:\n>>\n>> The idea of this project is to dive into the Git source code and\n>> convert, say, git-add--interactive.perl and/or git stash into proper C\n>> code, making it a so-called \"built-in\".\n>>\n>> My advice would be to try converting several small scripts, and avoid\n>> targetting a big one....\n>> add--interactive and stash are relatively complex beasts, perhaps\n>> git-pull.sh would be easier to start with.\n> \n> Yeah, I think that is a very good suggestion.\n\nWell, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR.\n\n> Also drop \"proper\" as if scripted Porcelains are second class citizens ;-)\n\nIf you had to deal with the portability/performance issues of the shell scripts I am frequently faced with, you would not call them first class citizens, either.\n\nCiao,\nDscho\n\n-- \n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n\n--- \nYou received this message because you are subscribed to the Google Groups \"Git for Windows\" group.\nTo unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.\nFor more options, visit https://groups.google.com/d/optout.\n"},{"id":"256593","messageId":"xmqqwq37owe9.fsf@gitster.dls.corp.google.com","threadId":"38591","inReplyTo":"c9ff859363d2d637b3607aaf6cb9295d@www.dscho.org","subject":"Re: [RFH] GSoC 2015 application","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-24T21:02:54Z","receivedAt":"2015-02-24T21:02:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> Also drop \"proper\" as if scripted Porcelains are second class citizens ;-)\n>\n> If you had to deal with the portability/performance issues of the\n> shell scripts I am frequently faced with, you would not call them\n> first class citizens, either.\n\nPerhaps that might be the case.\n\nBut I am polite enough to refrain from calling that \"not a problem\non 'proper' platforms\". I expect the same courtesy from others ;-).\n\n-- \n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n\n--- \nYou received this message because you are subscribed to the Google Groups \"Git for Windows\" group.\nTo unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.\nFor more options, visit https://groups.google.com/d/optout.\n"},{"id":"256609","messageId":"vpqh9uavp6q.fsf@anie.imag.fr","threadId":"38591","inReplyTo":"c9ff859363d2d637b3607aaf6cb9295d@www.dscho.org","subject":"Re: Re: [RFH] GSoC 2015 application","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-02-24T23:56:45Z","receivedAt":"2015-02-24T23:56:45Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Johannes Schindelin writes:\n\n> Hi Junio,\n>\n> On 2015-02-24 19:25, Junio C Hamano wrote:\n>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy\n>> wrote:\n>>> About the proposal:\n>>>\n>>> The idea of this project is to dive into the Git source code and\n>>> convert, say, git-add--interactive.perl and/or git stash into proper C\n>>> code, making it a so-called \"built-in\".\n>>>\n>>> My advice would be to try converting several small scripts, and avoid\n>>> targetting a big one....\n>>> add--interactive and stash are relatively complex beasts, perhaps\n>>> git-pull.sh would be easier to start with.\n>> \n>> Yeah, I think that is a very good suggestion.\n>\n> Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR.\n\nTo get an idea, I counted the lines of code written by the student I\nmentored last year:\n\n$ git log --author tanayabh@gmail.com -p | diffstat -s \n 43 files changed, 1225 insertions(+), 367 deletions(-)\n\nI would consider this GSoC as \"average\" (i.e. not exceptionnally good,\nbut certainly not a bad one either), so you may hope for more, but you\nshould not _expect_ much more IMHO.\n\nIn comparison:\n\n$ wc -l git-add--interactive.perl\n1654 git-add--interactive.perl\n$ wc -l git-stash.sh\n617 git-stash.sh\n\nI'd expect a rewrite in C to at least double the number of lines of\ncode, so rewriting git-stash would mean writting at least as many lines\nof code as the GSoC above. git-add--interactive.perl would be rather far\nabove.\n\nBut my point was not to convert _only_ git-pull.sh, but to have a GSoC\nstarting with this one and plan more. Then, depending on how it goes,\nyou can adjust the target.\n\nThis all depends on what you intend to do if the student does not finish\nthe job. If you're going to do the rewrite yourself anyway, then having\nthe student do even half of it is good already. If you're not going to\nfinish the job by yourself, then a 95%-done-rewrite means a piece of\ncode posted on the mailing list and never merged (and a lot of time\nwasted).\n\nIn any case, these are just advices, certainly not objections or hard\nrequests to change.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n\n-- \n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n\n--- \nYou received this message because you are subscribed to the Google Groups \"Git for Windows\" group.\nTo unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.\nFor more options, visit https://groups.google.com/d/optout.\n"},{"id":"256610","messageId":"CAGZ79kbcoN=-Byu8fPV9_9ZpFhsuZ=5U=V-Xif_30s-J8OWfJg@mail.gmail.com","threadId":"38591","inReplyTo":"vpqh9uavp6q.fsf@anie.imag.fr","subject":"Re: [msysGit] Re: [RFH] GSoC 2015 application","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-02-25T00:34:19Z","receivedAt":"2015-02-25T00:34:19Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy\n wrote:\n> Johannes Schindelin writes:\n>\n>> Hi Junio,\n>>\n>> On 2015-02-24 19:25, Junio C Hamano wrote:\n>>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy\n>>> wrote:\n>>>> About the proposal:\n>>>>\n>>>> The idea of this project is to dive into the Git source code and\n>>>> convert, say, git-add--interactive.perl and/or git stash into proper C\n>>>> code, making it a so-called \"built-in\".\n>>>>\n>>>> My advice would be to try converting several small scripts, and avoid\n>>>> targetting a big one....\n>>>> add--interactive and stash are relatively complex beasts, perhaps\n>>>> git-pull.sh would be easier to start with.\n>>>\n>>> Yeah, I think that is a very good suggestion.\n>>\n>> Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR.\n>\n> To get an idea, I counted the lines of code written by the student I\n> mentored last year:\n>\n> $ git log --author tanayabh@gmail.com -p | diffstat -s\n> 43 files changed, 1225 insertions(+), 367 deletions(-)\n>\n> I would consider this GSoC as \"average\" (i.e. not exceptionnally good,\n> but certainly not a bad one either), so you may hope for more, but you\n> should not _expect_ much more IMHO.\n>\n> In comparison:\n>\n> $ wc -l git-add--interactive.perl\n> 1654 git-add--interactive.perl\n> $ wc -l git-stash.sh\n> 617 git-stash.sh\n>\n> I'd expect a rewrite in C to at least double the number of lines of\n> code, so rewriting git-stash would mean writting at least as many lines\n> of code as the GSoC above. git-add--interactive.perl would be rather far\n> above.\n>\n> But my point was not to convert _only_ git-pull.sh, but to have a GSoC\n> starting with this one and plan more. Then, depending on how it goes,\n> you can adjust the target.\n>\n> This all depends on what you intend to do if the student does not finish\n> the job. If you're going to do the rewrite yourself anyway, then having\n> the student do even half of it is good already. If you're not going to\n> finish the job by yourself, then a 95%-done-rewrite means a piece of\n> code posted on the mailing list and never merged (and a lot of time\n> wasted).\n>\n> In any case, these are just advices, certainly not objections or hard\n> requests to change.\n>\n\n\nOnce upon a time (Sep 2013) I rewrote builtin/repack.c which was a\nshell script before. I did not have much real-coding expertise with the\ngit community before and by today there are 403 lines of code in\nbuiltin/repack.c. so going for roughly 3 times (1200 lines of code) change\nwould make a summer, specially if you need to learn how the workflow\nis in the open source world. There the lines in c doubled nearly exactly.\n(before 197 shell lines, afterwards 387 c lines).\n\nJust last weekend I met people, who were afraid of contributing to open source\n\"because sometimes the internet can be very mean\". Git being quite a high\nprofile project, as it is widely used, might not help, but rather fear\npeople away.\nThat said I would not underestimate the initial time a student needs to learn\nthe workflow. Though most of that learning is done in the micro project phase.\n"},{"id":"256617","messageId":"3e3da365d9b6021c9b6d8547ad8df788@www.dscho.org","threadId":"38591","inReplyTo":"vpqh9uavp6q.fsf@anie.imag.fr","subject":"Re: Re: [RFH] GSoC 2015 application","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-02-25T08:44:04Z","receivedAt":"2015-02-25T08:44:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Matthieu,\n\nOn 2015-02-25 00:56, Matthieu Moy wrote:\n> Johannes Schindelin writes:\n> \n>> On 2015-02-24 19:25, Junio C Hamano wrote:\n>>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy\n>>> wrote:\n>>>> About the proposal:\n>>>>\n>>>> The idea of this project is to dive into the Git source code and\n>>>> convert, say, git-add--interactive.perl and/or git stash into proper C\n>>>> code, making it a so-called \"built-in\".\n>>>>\n>>>> My advice would be to try converting several small scripts, and avoid\n>>>> targetting a big one....\n>>>> add--interactive and stash are relatively complex beasts, perhaps\n>>>> git-pull.sh would be easier to start with.\n>>>\n>>> Yeah, I think that is a very good suggestion.\n>>\n>> Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR.\n> \n> To get an idea, I counted the lines of code written by the student I\n> mentored last year:\n> \n> $ git log --author tanayabh@gmail.com -p | diffstat -s \n> 43 files changed, 1225 insertions(+), 367 deletions(-)\n> \n> I would consider this GSoC as \"average\" (i.e. not exceptionnally good,\n> but certainly not a bad one either), so you may hope for more, but you\n> should not _expect_ much more IMHO.\n> \n> In comparison:\n> \n> $ wc -l git-add--interactive.perl\n> 1654 git-add--interactive.perl\n> $ wc -l git-stash.sh\n> 617 git-stash.sh\n> \n> I'd expect a rewrite in C to at least double the number of lines of\n> code, so rewriting git-stash would mean writting at least as many lines\n> of code as the GSoC above. git-add--interactive.perl would be rather far\n> above.\n\nSure. You're right, I was thinking too big.\n\n> But my point was not to convert _only_ git-pull.sh, but to have a GSoC\n> starting with this one and plan more. Then, depending on how it goes,\n> you can adjust the target.\n\nThat's excellent advice.\n\n> This all depends on what you intend to do if the student does not finish\n> the job. If you're going to do the rewrite yourself anyway, then having\n> the student do even half of it is good already. If you're not going to\n> finish the job by yourself, then a 95%-done-rewrite means a piece of\n> code posted on the mailing list and never merged (and a lot of time\n> wasted).\n\nWell, all of this is academic at this point. Let's see whether we get accepted, and then, if a student finds this project compelling enough.\n\nIf both things happen, I will definitely heed your advice and encourage the student to start with some script that is easily converted, to \"get her feet wet\".\n\nCiao,\nDscho\n\n-- \n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n\n--- \nYou received this message because you are subscribed to the Google Groups \"Git for Windows\" group.\nTo unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.\nFor more options, visit https://groups.google.com/d/optout.\n"},{"id":"256619","messageId":"1029c184eae22b9d27fae5de2c04238b@www.dscho.org","threadId":"38591","inReplyTo":"20150224122846.GA2631@peff.net","subject":"Re: [msysGit] Re: [RFH] GSoC 2015 application","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-02-25T09:25:37Z","receivedAt":"2015-02-25T09:25:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn 2015-02-24 13:28, Jeff King wrote:\n> On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:\n> \n>> > Thanks! No rush, as we are not even accepted yet, but you can create a\n>> > profile at:\n>> >\n>> > http://google-melange.com\n>> >\n>> > and ask to join the \"git\" project as a mentor.\n>>\n>> I guess I can only ask that after the org is accepted, I will do so\n>> when (and if) that is the case.\n> \n> I think you can do it now; I had to create the project profile in order\n> to do the application. But again, no rush.\n\nI tried, but there are no orgs listed as of yet when I click \"Make connection\".\n\n>> Done: https://github.com/git/git.github.io/pull/12\n> \n> Thanks, merged.\n\nI opened another PR, based on Mathieu's advice.\n\nCiao,\nDscho\n"},{"id":"256618","messageId":"54ED951B.8020105@drmicha.warpmail.net","threadId":"38591","inReplyTo":"CAGZ79kbcoN=-Byu8fPV9_9ZpFhsuZ=5U=V-Xif_30s-J8OWfJg@mail.gmail.com","subject":"Re: [msysGit] Re: [RFH] GSoC 2015 application","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-02-25T09:25:47Z","receivedAt":"2015-02-25T09:25:47Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Stefan Beller venit, vidit, dixit 25.02.2015 01:34:\n> On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy\n> wrote:\n>> Johannes Schindelin writes:\n>>\n>>> Hi Junio,\n>>>\n>>> On 2015-02-24 19:25, Junio C Hamano wrote:\n>>>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy\n>>>> wrote:\n>>>>> About the proposal:\n>>>>>\n>>>>> The idea of this project is to dive into the Git source code and\n>>>>> convert, say, git-add--interactive.perl and/or git stash into proper C\n>>>>> code, making it a so-called \"built-in\".\n>>>>>\n>>>>> My advice would be to try converting several small scripts, and avoid\n>>>>> targetting a big one....\n>>>>> add--interactive and stash are relatively complex beasts, perhaps\n>>>>> git-pull.sh would be easier to start with.\n>>>>\n>>>> Yeah, I think that is a very good suggestion.\n>>>\n>>> Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR.\n>>\n>> To get an idea, I counted the lines of code written by the student I\n>> mentored last year:\n>>\n>> $ git log --author tanayabh@gmail.com -p | diffstat -s\n>> 43 files changed, 1225 insertions(+), 367 deletions(-)\n>>\n>> I would consider this GSoC as \"average\" (i.e. not exceptionnally good,\n>> but certainly not a bad one either), so you may hope for more, but you\n>> should not _expect_ much more IMHO.\n>>\n>> In comparison:\n>>\n>> $ wc -l git-add--interactive.perl\n>> 1654 git-add--interactive.perl\n>> $ wc -l git-stash.sh\n>> 617 git-stash.sh\n>>\n>> I'd expect a rewrite in C to at least double the number of lines of\n>> code, so rewriting git-stash would mean writting at least as many lines\n>> of code as the GSoC above. git-add--interactive.perl would be rather far\n>> above.\n>>\n>> But my point was not to convert _only_ git-pull.sh, but to have a GSoC\n>> starting with this one and plan more. Then, depending on how it goes,\n>> you can adjust the target.\n>>\n>> This all depends on what you intend to do if the student does not finish\n>> the job. If you're going to do the rewrite yourself anyway, then having\n>> the student do even half of it is good already. If you're not going to\n>> finish the job by yourself, then a 95%-done-rewrite means a piece of\n>> code posted on the mailing list and never merged (and a lot of time\n>> wasted).\n>>\n>> In any case, these are just advices, certainly not objections or hard\n>> requests to change.\n>>\n> \n> \n> Once upon a time (Sep 2013) I rewrote builtin/repack.c which was a\n> shell script before. I did not have much real-coding expertise with the\n> git community before and by today there are 403 lines of code in\n> builtin/repack.c. so going for roughly 3 times (1200 lines of code) change\n> would make a summer, specially if you need to learn how the workflow\n> is in the open source world. There the lines in c doubled nearly exactly.\n> (before 197 shell lines, afterwards 387 c lines).\n> \n> Just last weekend I met people, who were afraid of contributing to open source\n> \"because sometimes the internet can be very mean\". Git being quite a high\n> profile project, as it is widely used, might not help, but rather fear\n> people away.\n\nI guess they've read about the lkml too much :)\n\nI consider the gitml to be a relatively civilized place for constructive\ncriticism, without rants, flame wars and ad hominem swear word attacks.\nI don't know how it's perceived from the outside (but that drew me in\nback then).\n\nMaybe we can attach a photo of our maintainer to the GSOC page? That\nwould prove we're nice and polite :)\n\n> That said I would not underestimate the initial time a student needs to learn\n> the workflow. Though most of that learning is done in the micro project phase.\n\nYes, the technical workflow as well as the \"social habits\". They should\nfollow the gitml even before, and then the micro projects are a great\nlearning ground.\n\nMichael\n"},{"id":"256620","messageId":"vpqlhjmnxe2.fsf@anie.imag.fr","threadId":"38591","inReplyTo":"1029c184eae22b9d27fae5de2c04238b@www.dscho.org","subject":"Re: Re: [RFH] GSoC 2015 application","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-02-25T09:39:01Z","receivedAt":"2015-02-25T09:39:01Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Johannes Schindelin writes:\n\n>>> Done: https://github.com/git/git.github.io/pull/12\n>> \n>> Thanks, merged.\n>\n> I opened another PR, based on Mathieu's advice.\n\nThanks, merged.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n\n-- \n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n\n--- \nYou received this message because you are subscribed to the Google Groups \"Git for Windows\" group.\nTo unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.\nFor more options, visit https://groups.google.com/d/optout.\n"},{"id":"256624","messageId":"CACsJy8CU5N+3rMh1Png=8YQNMb5s8JT9Py9FdLekae6Dkds3BQ@mail.gmail.com","threadId":"38591","inReplyTo":"vpqh9uavp6q.fsf@anie.imag.fr","subject":"Re: Re: [RFH] GSoC 2015 application","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-02-25T10:02:24Z","receivedAt":"2015-02-25T10:02:24Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Feb 25, 2015 at 6:56 AM, Matthieu Moy\n wrote:\n> To get an idea, I counted the lines of code written by the student I\n> mentored last year:\n>\n> $ git log --author tanayabh@gmail.com -p | diffstat -s\n> 43 files changed, 1225 insertions(+), 367 deletions(-)\n>\n> I would consider this GSoC as \"average\" (i.e. not exceptionnally good,\n> but certainly not a bad one either), so you may hope for more, but you\n> should not _expect_ much more IMHO.\n>\n> In comparison:\n>\n> $ wc -l git-add--interactive.perl\n> 1654 git-add--interactive.perl\n> $ wc -l git-stash.sh\n> 617 git-stash.sh\n>\n> I'd expect a rewrite in C to at least double the number of lines of\n> code, so rewriting git-stash would mean writting at least as many lines\n> of code as the GSoC above. git-add--interactive.perl would be rather far\n> above.\n>\n> But my point was not to convert _only_ git-pull.sh, but to have a GSoC\n> starting with this one and plan more. Then, depending on how it goes,\n> you can adjust the target.\n\nSome data point as I have a half-baked builtin/pull.c in my\n(forgotten) private branch for 3 years. pull.c has 389 lines (with 24\nshell lines left in \"#if 0\"). git-pull.sh has 340 lines. Let's add 100\nC lines to pull.c when it's complete, that's 50% more lines. But in\nthe git-pull case the student could get a good head start by reusing\nmy code, maybe.\n-- \nDuy\n\n-- \n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n\n--- \nYou received this message because you are subscribed to the Google Groups \"Git for Windows\" group.\nTo unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.\nFor more options, visit https://groups.google.com/d/optout.\n"},{"id":"256625","messageId":"CAP8UFD2PcBsU6=FK4OHVrB7E98ycohS_0pYcbCBar=of1HLx+Q@mail.gmail.com","threadId":"38591","inReplyTo":"3e3da365d9b6021c9b6d8547ad8df788@www.dscho.org","subject":"Re: [msysGit] Re: [RFH] GSoC 2015 application","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-02-25T10:04:06Z","receivedAt":"2015-02-25T10:04:06Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wed, Feb 25, 2015 at 9:44 AM, Johannes Schindelin\n wrote:\n> Hi Matthieu,\n>\n> On 2015-02-25 00:56, Matthieu Moy wrote:\n>> Johannes Schindelin writes:\n>>\n>>> On 2015-02-24 19:25, Junio C Hamano wrote:\n>>>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy\n>>>> wrote:\n>>>>> About the proposal:\n>>>>>\n>>>>> The idea of this project is to dive into the Git source code and\n>>>>> convert, say, git-add--interactive.perl and/or git stash into proper C\n>>>>> code, making it a so-called \"built-in\".\n>>>>>\n>>>>> My advice would be to try converting several small scripts, and avoid\n>>>>> targetting a big one....\n>>>>> add--interactive and stash are relatively complex beasts, perhaps\n>>>>> git-pull.sh would be easier to start with.\n>>>>\n>>>> Yeah, I think that is a very good suggestion.\n>>>\n>>> Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR.\n>>\n>> To get an idea, I counted the lines of code written by the student I\n>> mentored last year:\n>>\n>> $ git log --author tanayabh@gmail.com -p | diffstat -s\n>> 43 files changed, 1225 insertions(+), 367 deletions(-)\n>>\n>> I would consider this GSoC as \"average\" (i.e. not exceptionnally good,\n>> but certainly not a bad one either), so you may hope for more, but you\n>> should not _expect_ much more IMHO.\n>>\n>> In comparison:\n>>\n>> $ wc -l git-add--interactive.perl\n>> 1654 git-add--interactive.perl\n>> $ wc -l git-stash.sh\n>> 617 git-stash.sh\n\nThere is also:\n\n$ wc -l git-bisect.sh\n528 git-bisect.sh\n\nAnd there is already builtin/bisect--helper.c that can be used to\nconvert step by step shell code to C. I can mentor or co-mentor this\nconvertion by the way, but that would conflict with the other bisect\nrelated GSoC project if a student takes it.\n\n>> I'd expect a rewrite in C to at least double the number of lines of\n>> code, so rewriting git-stash would mean writting at least as many lines\n>> of code as the GSoC above. git-add--interactive.perl would be rather far\n>> above.\n>\n> Sure. You're right, I was thinking too big.\n>\n>> But my point was not to convert _only_ git-pull.sh, but to have a GSoC\n>> starting with this one and plan more. Then, depending on how it goes,\n>> you can adjust the target.\n>\n> That's excellent advice.\n\nYeah!\n\n>> This all depends on what you intend to do if the student does not finish\n>> the job. If you're going to do the rewrite yourself anyway, then having\n>> the student do even half of it is good already. If you're not going to\n>> finish the job by yourself, then a 95%-done-rewrite means a piece of\n>> code posted on the mailing list and never merged (and a lot of time\n>> wasted).\n>\n> Well, all of this is academic at this point.\n\nYeah, but it's still worth keeping in many parts of our collective mind :-)\n\n> Let's see whether we get accepted, and then, if a student finds this project compelling enough.\n>\n> If both things happen, I will definitely heed your advice and encourage the student to start with some script that is easily converted, to \"get her feet wet\".\n\nGreat!\n\nThanks,\nChristian.\n"},{"id":"256628","messageId":"614912493.13990870.1424859945767.JavaMail.zimbra@imag.fr","threadId":"38591","inReplyTo":"1029c184eae22b9d27fae5de2c04238b@www.dscho.org","subject":"Re: Re: [RFH] GSoC 2015 application","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-02-25T10:25:45Z","receivedAt":"2015-02-25T10:25:45Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"----- Original Message -----\n> Hi Peff,\n> \n> On 2015-02-24 13:28, Jeff King wrote:\n> > On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:\n> > \n> >> > Thanks! No rush, as we are not even accepted yet, but you can create a\n> >> > profile at:\n> >> >\n> >> > http://google-melange.com\n> >> >\n> >> > and ask to join the \"git\" project as a mentor.\n> >>\n> >> I guess I can only ask that after the org is accepted, I will do so\n> >> when (and if) that is the case.\n> > \n> > I think you can do it now; I had to create the project profile in order\n> > to do the application. But again, no rush.\n> \n> I tried, but there are no orgs listed as of yet when I click \"Make\n> connection\".\n\nNot sure what it's supposed to look like, but I think if you give us your username we can invite you as mentor.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n\n-- \n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n\n--- \nYou received this message because you are subscribed to the Google Groups \"Git for Windows\" group.\nTo unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.\nFor more options, visit https://groups.google.com/d/optout.\n"},{"id":"256634","messageId":"f509e16aee45d64227879cdafdc106a3@www.dscho.org","threadId":"38591","inReplyTo":"CACsJy8CU5N+3rMh1Png=8YQNMb5s8JT9Py9FdLekae6Dkds3BQ@mail.gmail.com","subject":"Re: Re: [RFH] GSoC 2015 application","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-02-25T12:10:53Z","receivedAt":"2015-02-25T12:10:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Duy,\n\nOn 2015-02-25 11:02, Duy Nguyen wrote:\n> On Wed, Feb 25, 2015 at 6:56 AM, Matthieu Moy\n> wrote:\n>> To get an idea, I counted the lines of code written by the student I\n>> mentored last year:\n>>\n>> $ git log --author tanayabh@gmail.com -p | diffstat -s\n>> 43 files changed, 1225 insertions(+), 367 deletions(-)\n>>\n>> I would consider this GSoC as \"average\" (i.e. not exceptionnally good,\n>> but certainly not a bad one either), so you may hope for more, but you\n>> should not _expect_ much more IMHO.\n>>\n>> In comparison:\n>>\n>> $ wc -l git-add--interactive.perl\n>> 1654 git-add--interactive.perl\n>> $ wc -l git-stash.sh\n>> 617 git-stash.sh\n>>\n>> I'd expect a rewrite in C to at least double the number of lines of\n>> code, so rewriting git-stash would mean writting at least as many lines\n>> of code as the GSoC above. git-add--interactive.perl would be rather far\n>> above.\n>>\n>> But my point was not to convert _only_ git-pull.sh, but to have a GSoC\n>> starting with this one and plan more. Then, depending on how it goes,\n>> you can adjust the target.\n> \n> Some data point as I have a half-baked builtin/pull.c in my\n> (forgotten) private branch for 3 years. pull.c has 389 lines (with 24\n> shell lines left in \"#if 0\"). git-pull.sh has 340 lines. Let's add 100\n> C lines to pull.c when it's complete, that's 50% more lines. But in\n> the git-pull case the student could get a good head start by reusing\n> my code, maybe.\n\nThanks for the pointer, I will keep that in mind!\n\nCiao,\nDscho\n\n-- \n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n\n--- \nYou received this message because you are subscribed to the Google Groups \"Git for Windows\" group.\nTo unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.\nFor more options, visit https://groups.google.com/d/optout.\n"},{"id":"256635","messageId":"ff84346567e67b0d46cb40efef31916d@www.dscho.org","threadId":"38591","inReplyTo":"614912493.13990870.1424859945767.JavaMail.zimbra@imag.fr","subject":"Re: Re: [RFH] GSoC 2015 application","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-02-25T12:15:01Z","receivedAt":"2015-02-25T12:15:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Matthieu,\n\nOn 2015-02-25 11:25, Matthieu Moy wrote:\n> ----- Original Message -----\n\n>> On 2015-02-24 13:28, Jeff King wrote:\n>> > On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:\n>> >\n>> >> > Thanks! No rush, as we are not even accepted yet, but you can create a\n>> >> > profile at:\n>> >> >\n>> >> > http://google-melange.com\n>> >> >\n>> >> > and ask to join the \"git\" project as a mentor.\n>> >>\n>> >> I guess I can only ask that after the org is accepted, I will do so\n>> >> when (and if) that is the case.\n>> >\n>> > I think you can do it now; I had to create the project profile in order\n>> > to do the application. But again, no rush.\n>>\n>> I tried, but there are no orgs listed as of yet when I click \"Make\n>> connection\".\n> \n> Not sure what it's supposed to look like, but I think if you give us\n> your username we can invite you as mentor.\n\nThanks. My username is – surprise! – 'dscho' ;-)\n\nCiao,\nDscho\n\n-- \n-- \n*** Please reply-to-all at all times ***\n*** (do not pretend to know who is subscribed and who is not) ***\n*** Please avoid top-posting. ***\nThe msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.\n\nYou received this message because you are subscribed to the Google\nGroups \"msysGit\" group.\nTo post to this group, send email to msysgit@googlegroups.com\nTo unsubscribe from this group, send email to\nmsysgit+unsubscribe@googlegroups.com\nFor more options, and view previous threads, visit this group at\nhttp://groups.google.com/group/msysgit?hl=en_US?hl=en\n\n--- \nYou received this message because you are subscribed to the Google Groups \"Git for Windows\" group.\nTo unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.\nFor more options, visit https://groups.google.com/d/optout.\n"},{"id":"256674","messageId":"1424947441-19134-1-git-send-email-pclouds@gmail.com","threadId":"38591","inReplyTo":"CAPc5daVJJcC--mwq0PfAczge3zG44ToDKP853FkyZ3x1KUfsig@mail.gmail.com","subject":"[PATCH] versionsort: support reorder prerelease suffixes","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2015-02-26T10:44:01Z","receivedAt":"2015-02-26T10:44:01Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Signed-off-by: Nguyễn Thái Ngọc Duy \n---\n Second round. Looking better. We can do\n \"1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1\" too but it relies on\n config key's loading order, a bit iffy.\n\n Documentation/config.txt | 7 +++++++\n t/t7004-tag.sh | 28 +++++++++++++++++++++++++++\n versioncmp.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++\n 3 files changed, 85 insertions(+)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 04e2a71..8e078df 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -2539,6 +2539,13 @@ user.signingkey::\n \tThis option is passed unchanged to gpg's --local-user parameter,\n \tso you may specify a key using any method that gpg supports.\n \n+versionsort.prereleaseSuffix::\n+\tWhen version sort is used in linkgit:git-tag[1], prerelease\n+\ttags (e.g. \"1.0-rc1\") may appear after the main release\n+\t\"1.0\". By specifying the suffix \"-rc\" in this variable,\n+\t\"1.0-rc1\" will appear before \"1.0\". One variable assignment\n+\tper suffix.\n+\n web.browser::\n \tSpecify a web browser that may be used by some commands.\n \tCurrently only linkgit:git-instaweb[1] and linkgit:git-help[1]\ndiff --git a/t/t7004-tag.sh b/t/t7004-tag.sh\nindex 35c805a..8bfeef9 100755\n--- a/t/t7004-tag.sh\n+++ b/t/t7004-tag.sh\n@@ -1459,6 +1459,34 @@ test_expect_success 'invalid sort parameter in configuratoin' '\n \ttest_cmp expect actual\n '\n \n+test_expect_success 'version sort with prerelease reordering' '\n+\tgit config --unset tag.sort &&\n+\tgit config versionsort.prereleaseSuffix -rc &&\n+\tgit tag foo1.6-rc1 &&\n+\tgit tag foo1.6-rc2 &&\n+\tgit tag -l --sort=version:refname \"foo*\" >actual &&\n+\tcat >expect <<-\\EOF &&\n+\tfoo1.3\n+\tfoo1.6-rc1\n+\tfoo1.6-rc2\n+\tfoo1.6\n+\tfoo1.10\n+\tEOF\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'reverse version sort with prerelease reordering' '\n+\tgit tag -l --sort=-version:refname \"foo*\" >actual &&\n+\tcat >expect <<-\\EOF &&\n+\tfoo1.10\n+\tfoo1.6\n+\tfoo1.6-rc2\n+\tfoo1.6-rc1\n+\tfoo1.3\n+\tEOF\n+\ttest_cmp expect actual\n+'\n+\n run_with_limited_stack () {\n \t(ulimit -s 128 && \"$@\")\n }\ndiff --git a/versioncmp.c b/versioncmp.c\nindex 7511e08..80bfd10 100644\n--- a/versioncmp.c\n+++ b/versioncmp.c\n@@ -1,4 +1,5 @@\n #include \"cache.h\"\n+#include \"string-list.h\"\n \n /*\n * versioncmp(): copied from string/strverscmp.c in glibc commit\n@@ -20,6 +21,48 @@\n #define CMP 2\n #define LEN 3\n \n+static const struct string_list *prereleases;\n+static int initialized;\n+\n+/*\n+ * p1 and p2 point to the first different character in two strings. If\n+ * either p1 or p2 starts with a prerelease suffix, it will be forced\n+ * to be on top.\n+ *\n+ * If both p1 and p2 start with (different) suffix, the order is\n+ * determined by config file.\n+ *\n+ * Note that we don't have to deal with the situation when both p1 and\n+ * p2 start with the same suffix because the common part is already\n+ * consumed by the caller.\n+ *\n+ * Return non-zero if *diff contains the return value for versioncmp()\n+ */\n+static int swap_prereleases(const void *p1_,\n+\t\t\t const void *p2_,\n+\t\t\t int *diff)\n+{\n+\tconst char *p1 = p1_;\n+\tconst char *p2 = p2_;\n+\tint i, i1 = -1, i2 = -1;\n+\n+\tfor (i = 0; i < prereleases->nr; i++) {\n+\t\tconst char *suffix = prereleases->items[i].string;\n+\t\tif (i1 == -1 && starts_with(p1, suffix))\n+\t\t\ti1 = i;\n+\t\tif (i2 == -1 && starts_with(p2, suffix))\n+\t\t\ti2 = i;\n+\t}\n+\tif (i1 == -1 && i2 == -1)\n+\t\treturn 0;\n+\tif (i1 >= 0 && i2 >= 0)\n+\t\t*diff = i1 - i2;\n+\telse if (i1 >= 0)\n+\t\t*diff = -1;\n+\telse /* if (i2 >= 0) */\n+\t\t*diff = 1;\n+\treturn 1;\n+}\n \n /*\n * Compare S1 and S2 as strings holding indices/version numbers,\n@@ -74,6 +117,13 @@ int versioncmp(const char *s1, const char *s2)\n \t\tstate += (c1 == '0') + (isdigit (c1) != 0);\n \t}\n \n+\tif (!initialized) {\n+\t\tinitialized = 1;\n+\t\tprereleases = git_config_get_value_multi(\"versionsort.prereleasesuffix\");\n+\t}\n+\tif (prereleases && swap_prereleases(p1 - 1, p2 - 1, &diff))\n+\t\treturn diff;\n+\n \tstate = result_type[state * 3 + (((c2 == '0') + (isdigit (c2) != 0)))];\n \n \tswitch (state) {\n-- \n2.3.0.rc1.137.g477eb31\n"},{"id":"256685","messageId":"CACsJy8D6nAt3fMw=oh5mwUwfAJKViN1pk9pf9gZSBGyquU_WBQ@mail.gmail.com","threadId":"38591","inReplyTo":"20150218191417.GA7767@peff.net","subject":"Re: [RFH] GSoC 2015 application","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-02-26T13:10:38Z","receivedAt":"2015-02-26T13:10:38Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Feb 19, 2015 at 2:14 AM, Jeff King wrote:\n> Where I really need help now is in the \"ideas\" page:\n>\n> http://git.github.io/SoC-2015-Ideas.html\n\nIs this too ambitious for a summer? I suspect the answer is yes, but anyway..\n\nDue to http limitations and stateless decision, a lot of data is sent\nback and forth during have/want negotiation for smart-http. I wonder\nif we could implement the \"long polling\" scheme in a CGI program. The\nprogram terminates HTTP requests and recreates a full duplex\nconnection for upload-pack to talk to the client. upload-pack falls\nback to the normal mode, used by git:// and ssh://.\n\nAn example of this is BOSH [1]. From a quick glance it does not seem\nto require any special thing, so it's unlikely to cause problems with\nfirewalls, proxies.. If this is implemented as cgi (instead of http\nserver), we'll need to save session infos somewhere. I suppose shm\nwith proper locking is enough.\n\n[1] http://xmpp.org/extensions/xep-0124.html\n-- \nDuy\n"},{"id":"256754","messageId":"xmqqvbinhw7l.fsf@gitster.dls.corp.google.com","threadId":"38591","inReplyTo":"1424947441-19134-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] versionsort: support reorder prerelease suffixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-27T21:37:50Z","receivedAt":"2015-02-27T21:37:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> Signed-off-by: Nguyễn Thái Ngọc Duy \n> ---\n> Second round. Looking better. We can do\n> \"1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1\" too but it relies on\n> config key's loading order, a bit iffy.\n>\n> Documentation/config.txt | 7 +++++++\n> t/t7004-tag.sh | 28 +++++++++++++++++++++++++++\n> versioncmp.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++\n> 3 files changed, 85 insertions(+)\n>\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 04e2a71..8e078df 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -2539,6 +2539,13 @@ user.signingkey::\n> \tThis option is passed unchanged to gpg's --local-user parameter,\n> \tso you may specify a key using any method that gpg supports.\n> \n> +versionsort.prereleaseSuffix::\n> +\tWhen version sort is used in linkgit:git-tag[1], prerelease\n> +\ttags (e.g. \"1.0-rc1\") may appear after the main release\n> +\t\"1.0\". By specifying the suffix \"-rc\" in this variable,\n> +\t\"1.0-rc1\" will appear before \"1.0\". One variable assignment\n> +\tper suffix.\n\nI think the last half-sentence want to mean that\n\n\t[versionsort]\n prereleaseSuffix = -pre\n \tprereleaseSuffix = -rc\n\nis the supported way to write, and not\n\n\t[versionsort]\n \tprereleaseSuffix = -pre -rc\n\nbut it probably is unclear unless the reader already knows what it\nis trying to say. The reader also needs to learn somewhere how the\norder of the entries affects the result.\n\n> +\tif (i1 == -1 && i2 == -1)\n> +\t\treturn 0;\n> +\tif (i1 >= 0 && i2 >= 0)\n> +\t\t*diff = i1 - i2;\n> +\telse if (i1 >= 0)\n> +\t\t*diff = -1;\n\np1 is a prerelease and p2 is not, so p1 comes before p2.\n\n> +\telse /* if (i2 >= 0) */\n> +\t\t*diff = 1;\n\nand the other way around.\n\nThe math makes sense, I think.\n"},{"id":"256989","messageId":"20150304103119.GA19234@peff.net","threadId":"38591","inReplyTo":"CACsJy8D6nAt3fMw=oh5mwUwfAJKViN1pk9pf9gZSBGyquU_WBQ@mail.gmail.com","subject":"Re: [RFH] GSoC 2015 application","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-03-04T10:31:19Z","receivedAt":"2015-03-04T10:31:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 26, 2015 at 08:10:38PM +0700, Duy Nguyen wrote:\n\n> On Thu, Feb 19, 2015 at 2:14 AM, Jeff King wrote:\n> > Where I really need help now is in the \"ideas\" page:\n> >\n> > http://git.github.io/SoC-2015-Ideas.html\n> \n> Is this too ambitious for a summer? I suspect the answer is yes, but anyway..\n> \n> Due to http limitations and stateless decision, a lot of data is sent\n> back and forth during have/want negotiation for smart-http. I wonder\n> if we could implement the \"long polling\" scheme in a CGI program. The\n> program terminates HTTP requests and recreates a full duplex\n> connection for upload-pack to talk to the client. upload-pack falls\n> back to the normal mode, used by git:// and ssh://.\n\nSo basically Git-over-TCP-over-HTTP? :)\n\nThat would be a nice thing to have, though looking over the BOSH link\n(which this is my first exposure to), it does look rather complicated.\nIt's not clear to me how easily one could plug in an existing tunneling\nsolution, and just stick git programs at the endpoints (in other words,\nlet that solution manage all of the connection state and just present a\nsocketpair() to git).\n\nI'm not sure it is too ambitious in terms of actual implementation time,\nbut I think the design work may exceed what most students are capable\nof.\n\n-Peff\n"},{"id":"256994","messageId":"CACsJy8DCBEp9jPrq=vR-dcJ4hSZss=4i900OCDzUFm_NvonvTg@mail.gmail.com","threadId":"38591","inReplyTo":"20150304103119.GA19234@peff.net","subject":"Re: [RFH] GSoC 2015 application","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-03-04T11:21:20Z","receivedAt":"2015-03-04T11:21:20Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Mar 4, 2015 at 5:31 PM, Jeff King wrote:\n> On Thu, Feb 26, 2015 at 08:10:38PM +0700, Duy Nguyen wrote:\n>\n>> On Thu, Feb 19, 2015 at 2:14 AM, Jeff King wrote:\n>> > Where I really need help now is in the \"ideas\" page:\n>> >\n>> > http://git.github.io/SoC-2015-Ideas.html\n>>\n>> Is this too ambitious for a summer? I suspect the answer is yes, but anyway..\n>>\n>> Due to http limitations and stateless decision, a lot of data is sent\n>> back and forth during have/want negotiation for smart-http. I wonder\n>> if we could implement the \"long polling\" scheme in a CGI program. The\n>> program terminates HTTP requests and recreates a full duplex\n>> connection for upload-pack to talk to the client. upload-pack falls\n>> back to the normal mode, used by git:// and ssh://.\n>\n> So basically Git-over-TCP-over-HTTP? :)\n\nYes. The hidden agenda was, if it works well, we might be able to\ndeprecate smart-http one day. That day, if happens, would be in far\nfuture though. By that time hopefully we could just use http2\ninsteadof tcp-over-http1.\n\n> I'm not sure it is too ambitious in terms of actual implementation time,\n> but I think the design work may exceed what most students are capable\n> of.\n\nNot to mention that I think it can be man-in-the-middle attacked if\nwe're not careful (e.g. send to session token in unencrypted). Which\nmakes it less appealing to me.\n-- \nDuy\n"},{"id":"257030","messageId":"70A3994196D94205B75660D9DEFF0A12@PhilipOakley","threadId":"38591","inReplyTo":"vpqpp94exb5.fsf@anie.imag.fr","subject":"Re: [RFH] GSoC 2015 application","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2015-03-04T21:33:23Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Matthieu Moy\" \nSent: Friday, February 20, 2015 9:39 AM\n> Jeff King writes:\n>\n>> - Matthieu, who also cited time constraints\n>\n> Just to clarify: last year we were co-mentoring with Ram. I ended up\n> having a lot of time and did most of the work (not blaming Ram, and I\n> enjoyed the experience). I'm still motivated to co-mentor, but this \n> time\n> the co-mentoring has to be more balanced (or unballanced to the other\n> mentor ;-) ).\n>\n>> - Junio, who contributed some project ideas, but who in the past \n>> has\n>> declined to mentor in order to remain impartial as the maintainer\n>> who evaluates student results (which I think is quite reasonable)\n>\n> Yes, as a mentor I did appreciate having Junio as impartial\n> maintainer/reviewer. And he did for sure contribute even without being \n> a\n> mentor!\n>\n> From your list, it seems we can target 1 or 2 slots. I'd say it's \n> still\n> worth applying, but if we don't find more mentors then perhaps it \n> would\n> make sense to say so explicitely in\n> http://git.github.io/SoC-2015-Ideas.html so that students looking for\n> organization know that we'll have very few slots.\n>\n> -- \nHi,\nGiven the mention of the GSoC ideas list, I thought it worth writing out \none of my little ideas..\n\n\nA possible idea is to add a date based variant of shallow clone :\n\n 'git clone --date ...'\n\nin the same vein as the existing depth (shallow) clone.\n\nOn the wire advertise a 'shallow-date' capability, passing a signed big \ninteger as the unix time for the shallow cut-off point (i.e. future \nextensible to cover a very wide date range), with optional(?) date+depth \nhysteresis (clock skew) parameters.\n\nCommand line interface to use existing date/time formats, (and possibly \nrevision dates?).\n\nExtend 'git fetch' to include the --date option.\n\nEnsure that 'git push' continues to work with and between \nshallow/shallow-date clones.\n\nUpdate the documentation in line with the capability.\n\nDocument any migration plan (if required)\n\nWhy\n===\n\nThis capability would eliminate the existing confusion over the --depth \nparameter as different branches may require different depths to reach a \n\"common\" start point.\n\nExtra points for an easy method of '--unshallow-date ' to \nremove 'old' commits that the user may no longer need locally. \n(unshallow may not be the right term...)\n\n--\nPhilip\n"},{"id":"257035","messageId":"CAGZ79kaNZsBP19gLvsrDx6RLyQ7QhmbKAgSDcXg71Uwcvf9tNQ@mail.gmail.com","threadId":"38591","inReplyTo":"70A3994196D94205B75660D9DEFF0A12@PhilipOakley","subject":"Re: [RFH] GSoC 2015 application","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-03-04T23:55:22Z","receivedAt":"2015-03-04T23:55:22Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley wrote:\n\n> A possible idea is to add a date based variant of shallow clone :\n>\n> 'git clone --date ...'\n>\n> in the same vein as the existing depth (shallow) clone.\n\nAs food for thought:\nMaybe broaden this further up to the git-ish way of describing refs, so\n\n git clone --since 2.weeks.ago \n git clone --since v2.10 \n git clone --since c0ffee^^ \n\nwould all equally work?\n\nI am not sure if that is feasible though, but it would come in handy. (E.g.\nyou are an end user and want to bisect down a bug which you notice in the\nnew version X but not in old version Y, so you start on getting the sources,\ncompiling, bisecting)\n"},{"id":"257037","messageId":"75FBE31490904D8EA82F5C445F1F33E1@PhilipOakley","threadId":"38591","inReplyTo":"CAGZ79kaNZsBP19gLvsrDx6RLyQ7QhmbKAgSDcXg71Uwcvf9tNQ@mail.gmail.com","subject":"Re: [RFH] GSoC 2015 application","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2015-03-04T23:59:48Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Stefan Beller\" \n> On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley \n> wrote:\n>\n>> A possible idea is to add a date based variant of shallow clone :\n>>\n>> 'git clone --date ...'\n>>\n>> in the same vein as the existing depth (shallow) clone.\n>\n> As food for thought:\n> Maybe broaden this further up to the git-ish way of describing refs, \n> so\n>\n> git clone --since 2.weeks.ago \n> git clone --since v2.10 \n> git clone --since c0ffee^^ \n>\n> would all equally work?\n\nThe use of --since instead of --date would be an equally valid way of \nspelling the option (coders choice;-)\n\nAt the clone stage, the local Git can't determine (for the 2nd & 3d \noption) where such a revison is located, so would have to send the \nrevision string to the server for processing, which could complicate the \nprotocol. Hence my choice of a simple unix time value at the protocol \nlevel.\n\nAn alternate/addition is to use a nominated sha1 (from ls-remote) as a \nstand in for a date, allowing your option 2 (--since ) to be \nimplemented as an alias or script.\n\nIt all depends on how complicated we want it to become, but starting \nsimple (though extensible) is important.\n\n>\n> I am not sure if that is feasible though, but it would come in handy. \n> (E.g.\n> you are an end user and want to bisect down a bug which you notice in \n> the\n> new version X but not in old version Y, so you start on getting the \n> sources,\n> compiling, bisecting)\n> --\nPhilip \n"},{"id":"257040","messageId":"CAPc5daV_igiExbvY1eH0T2SKxgawO86F0eZyoai_QK-dXc5fDg@mail.gmail.com","threadId":"38591","inReplyTo":"75FBE31490904D8EA82F5C445F1F33E1@PhilipOakley","subject":"Re: [RFH] GSoC 2015 application","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-05T00:22:18Z","receivedAt":"2015-03-05T00:22:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley wrote:\n>>\n>> git clone --since 2.weeks.ago \n>> git clone --since v2.10 \n>\n> The use of --since instead of --date would be an equally valid way of\n> spelling the option (coders choice;-)\n\nI think it is a demonstration of poor taste. Everywhere else, --since\nis a way to\nspecify the date, not a revision. Why should this one alone should be different?\n"},{"id":"257041","messageId":"CACsJy8BcL3=uYa6=zA9UfV5A9sYqhcrJte40y03sfCcsCkKdhA@mail.gmail.com","threadId":"38591","inReplyTo":"CAGZ79kaNZsBP19gLvsrDx6RLyQ7QhmbKAgSDcXg71Uwcvf9tNQ@mail.gmail.com","subject":"Re: [RFH] GSoC 2015 application","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-03-05T00:26:43Z","receivedAt":"2015-03-05T00:26:43Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Mar 5, 2015 at 6:55 AM, Stefan Beller wrote:\n> On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley wrote:\n>\n>> A possible idea is to add a date based variant of shallow clone :\n>>\n>> 'git clone --date ...'\n>>\n>> in the same vein as the existing depth (shallow) clone.\n>\n> As food for thought:\n> Maybe broaden this further up to the git-ish way of describing refs, so\n>\n> git clone --since 2.weeks.ago \n> git clone --since v2.10 \n> git clone --since c0ffee^^ \n>\n> would all equally work?\n\nYes, and we could generalize it further: add shallow-rev-list\ncapability and send \"shallow-rev-list \" line to define shallow boundary. The protocol change would be\nsimple enough. The hard part is select a safe subset of rev-list\noptions that can be used in this mode and reject the rest.\n\n> I am not sure if that is feasible though, but it would come in handy. (E.g.\n> you are an end user and want to bisect down a bug which you notice in the\n> new version X but not in old version Y, so you start on getting the sources,\n> compiling, bisecting)\n-- \nDuy\n"},{"id":"257042","messageId":"CAGZ79kZzB8-r2a4VGG23GL1ZqxY7c34391vMwVr09MnCV6Hqcg@mail.gmail.com","threadId":"38591","inReplyTo":"CAPc5daV_igiExbvY1eH0T2SKxgawO86F0eZyoai_QK-dXc5fDg@mail.gmail.com","subject":"Re: [RFH] GSoC 2015 application","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-03-05T00:32:05Z","receivedAt":"2015-03-05T00:32:05Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano wrote:\n> On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley wrote:\n>>>\n>>> git clone --since 2.weeks.ago \n>>> git clone --since v2.10 \n>>\n>> The use of --since instead of --date would be an equally valid way of\n>> spelling the option (coders choice;-)\n>\n> I think it is a demonstration of poor taste. Everywhere else, --since\n> is a way to\n> specify the date, not a revision. Why should this one alone should be different?\n\nI wanted to point out the broader use case than being stylish correct,\nthough from\nan English grammars point of view `--since` should also be able to\ndescribe a point\nin time (\"since 2 weeks ago\" is as valid as \"since Feb 17th\")\n\nI cannot remember the usual option off hand to describe the revision\ninstead of a date.\nMaybe we want to have one option long term to allow any kind of input (revision\nand date), as this may be easier to remember, especially if it aligns well with\nthe English language.\n"},{"id":"257046","messageId":"xmqqr3t45jjz.fsf@gitster.dls.corp.google.com","threadId":"38591","inReplyTo":"CAGZ79kZzB8-r2a4VGG23GL1ZqxY7c34391vMwVr09MnCV6Hqcg@mail.gmail.com","subject":"Re: [RFH] GSoC 2015 application","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-05T01:17:52Z","receivedAt":"2015-03-05T01:17:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano wrote:\n>> On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley wrote:\n>>>>\n>>>> git clone --since 2.weeks.ago \n>>>> git clone --since v2.10 \n>>>\n>>> The use of --since instead of --date would be an equally valid way of\n>>> spelling the option (coders choice;-)\n>>\n>> I think it is a demonstration of poor taste. Everywhere else,\n>> --since is a way to specify the date, not a revision. Why should\n>> this one alone should be different?\n>\n> I wanted to point out the broader use case than being stylish correct,\n\nOK.\n\nI actually think it is OK to envision that \"--since\" will be made\nappliable to non-dates in the longer term. The proposal, when dug\ninto minor detail, may include extending approxidate() to take a\nrevision name, i.e.\n\n\tgit log --since=v2.0.0 master\n\nwould behave as if\n\n\tgit log --since=@1401300269 master\n\nbecause that is the timestamp the v2.0.0 tag carries.\n\nNote that I do not think it is a good idea to rewrite the above to \n\n\tgit log v2.0.0..master\n\nat all (hint: think how you would rewrite --until).\n\nAs to the shallow-boundary capability implementation, I think what\nhas been discussed in the thread is basically sound. Just send the\nend-user supplied string (\"2.weeks.ago\", \"v2.10\", etc.) over the\nwire without interpreting locally, and have the server end apply (an\nupdated) approxidate() on it, internally compute the exact cut-point\njust like \"git bundle create\" does when it computes the prerequisites,\nand use the resulting commits as the shallow boundary.\n"},{"id":"257048","messageId":"xmqqmw3s5j1y.fsf@gitster.dls.corp.google.com","threadId":"38591","inReplyTo":"xmqqvbinhw7l.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] versionsort: support reorder prerelease suffixes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-05T01:28:41Z","receivedAt":"2015-03-05T01:28:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>> +versionsort.prereleaseSuffix::\n>> +\tWhen version sort is used in linkgit:git-tag[1], prerelease\n>> +\ttags (e.g. \"1.0-rc1\") may appear after the main release\n>> +\t\"1.0\". By specifying the suffix \"-rc\" in this variable,\n>> +\t\"1.0-rc1\" will appear before \"1.0\". One variable assignment\n>> +\tper suffix.\n>\n> I think the last half-sentence want to mean that\n>\n> \t[versionsort]\n> prereleaseSuffix = -pre\n> \tprereleaseSuffix = -rc\n>\n> is the supported way to write, and not\n>\n> \t[versionsort]\n> \tprereleaseSuffix = -pre -rc\n>\n> but it probably is unclear unless the reader already knows what it\n> is trying to say. The reader also needs to learn somewhere how the\n> order of the entries affects the result.\n\nThis is already in 'next', so could you fix that half-sentence in\nthe documentation via an incremental update?\n\nThanks.\n"},{"id":"257056","messageId":"xmqqsidk3r17.fsf@gitster.dls.corp.google.com","threadId":"38591","inReplyTo":"CAGZ79kZzB8-r2a4VGG23GL1ZqxY7c34391vMwVr09MnCV6Hqcg@mail.gmail.com","subject":"Re: [RFH] GSoC 2015 application","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-05T06:19:16Z","receivedAt":"2015-03-05T06:19:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> I cannot remember the usual option off hand to describe the revision\n> instead of a date.\n\nBecause \"log --since= master\" and \"log v1.0..master\"\nmean two completely different things, we need some way to specify\nwhich one of these two the user wants to \"git clone\" so that the\nuser can say at what point the user wants the shallow history to\nbegin.\n\nI think it is a good idea to use --since for date-based cut-off, in\naddition to the existing --depth that is depth-based cut-off, and we\nprobably would want another one that gives the topology-based\ncut-off, so that we can express the range in a similar way to \"log\nv1.0..master\".\n\nBut when we talk about the topology-based cut-off locally, we always\nuse the set syntax A..B, ^A B, etc. and never a command line option\nwith an argument to specify \"the bottom of the history\". It is not\nsurprising that you don't remember any usual option for that,\nbecause there isn't one.\n\nThe closest thing I can think of that looks somewhat like a command\nline option is \"--not\", as in\n\n git log A B --not C D E\n\nthat is equivalent to \"A B ^C ^D ^E\", but that is not an option that\ntakes an argument. I do not know if it is particularly a good idea\nto say:\n\n git clone --not v2.0 $URL\n\nto specify topology-based cut-off.\n\nBut we would need some way to say a set-based cut-off; I do not\nthink using --since for that purpose is a good idea, though, because\nthat is already taken for date-based cut-off, and mixing them\ntogether will introduce confusion.\n"},{"id":"257060","messageId":"1425551295-28653-1-git-send-email-pclouds@gmail.com","threadId":"38591","inReplyTo":"70A3994196D94205B75660D9DEFF0A12@PhilipOakley","subject":"Re: [RFH] GSoC 2015 application","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2015-03-05T10:28:09Z","receivedAt":"2015-03-05T10:28:09Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Mar 5, 2015 at 5:05 AM, Philip Oakley wrote:\n> Given the mention of the GSoC ideas list, I thought it worth writing out one\n> of my little ideas..\n>\n>\n> A possible idea is to add a date based variant of shallow clone :\n>\n>  'git clone --date ...'\n>\n> in the same vein as the existing depth (shallow) clone.\n\nI do have plenty of topics to finish up. But I wanted to see how this\nfeature would look like. I needed to write some code for that and for\nstraightening my thoughts. Totally untested, but I think it looks cool :)\n\nI think this feature is feasible. The protocol and UI are still up in\nthe air. Plenty of work for any student who wants to pick this up.\n\nNguyễn Thái Ngọc Duy (6):\n upload-pack: move shallow deepen code out of receive_needs()\n upload-pack: move \"shallow\" sending code out of deepen()\n upload-pack: remove unused variable \"backup\"\n upload-pack: move \"unshallow\" sending code out of deepen()\n shallow.c: implement a generic shallow boundary finder based on rev-list\n upload-pack: example code to use get_shallow_commits_by_rev_list\n\n commit.h | 2 +\n shallow.c | 65 +++++++++++++++++++++++++++++\n upload-pack.c | 129 +++++++++++++++++++++++++++++++++++++---------------------\n 3 files changed, 149 insertions(+), 47 deletions(-)\n\n-- \n2.3.0.rc1.137.g477eb31\n"},{"id":"257066","messageId":"1425551295-28653-2-git-send-email-pclouds@gmail.com","threadId":"38591","inReplyTo":"1425551295-28653-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 1/6] upload-pack: move shallow deepen code out of receive_needs()","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2015-03-05T10:28:10Z","receivedAt":"2015-03-05T10:28:10Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"This is a prep step for further refactoring. Besides reindentation and\ns/shallows\\./shallows->/g, no other changes are expected.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n upload-pack.c | 99 +++++++++++++++++++++++++++++++----------------------------\n 1 file changed, 52 insertions(+), 47 deletions(-)\n\ndiff --git a/upload-pack.c b/upload-pack.c\nindex b531a32..74f48f9 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -531,6 +531,55 @@ error:\n \t}\n }\n \n+static void deepen(int depth, const struct object_array *shallows)\n+{\n+\tstruct commit_list *result = NULL, *backup = NULL;\n+\tint i;\n+\tif (depth == INFINITE_DEPTH && !is_repository_shallow())\n+\t\tfor (i = 0; i < shallows->nr; i++) {\n+\t\t\tstruct object *object = shallows->objects[i].item;\n+\t\t\tobject->flags |= NOT_SHALLOW;\n+\t\t}\n+\telse\n+\t\tbackup = result =\n+\t\t\tget_shallow_commits(&want_obj, depth,\n+\t\t\t\t\t SHALLOW, NOT_SHALLOW);\n+\twhile (result) {\n+\t\tstruct object *object = &result->item->object;\n+\t\tif (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {\n+\t\t\tpacket_write(1, \"shallow %s\",\n+\t\t\t\t sha1_to_hex(object->sha1));\n+\t\t\tregister_shallow(object->sha1);\n+\t\t\tshallow_nr++;\n+\t\t}\n+\t\tresult = result->next;\n+\t}\n+\tfree_commit_list(backup);\n+\tfor (i = 0; i < shallows->nr; i++) {\n+\t\tstruct object *object = shallows->objects[i].item;\n+\t\tif (object->flags & NOT_SHALLOW) {\n+\t\t\tstruct commit_list *parents;\n+\t\t\tpacket_write(1, \"unshallow %s\",\n+\t\t\t\t sha1_to_hex(object->sha1));\n+\t\t\tobject->flags &= ~CLIENT_SHALLOW;\n+\t\t\t/* make sure the real parents are parsed */\n+\t\t\tunregister_shallow(object->sha1);\n+\t\t\tobject->parsed = 0;\n+\t\t\tparse_commit_or_die((struct commit *)object);\n+\t\t\tparents = ((struct commit *)object)->parents;\n+\t\t\twhile (parents) {\n+\t\t\t\tadd_object_array(&parents->item->object,\n+\t\t\t\t\t\t NULL, &want_obj);\n+\t\t\t\tparents = parents->next;\n+\t\t\t}\n+\t\t\tadd_object_array(object, NULL, &extra_edge_obj);\n+\t\t}\n+\t\t/* make sure commit traversal conforms to client */\n+\t\tregister_shallow(object->sha1);\n+\t}\n+\tpacket_flush(1);\n+}\n+\n static void receive_needs(void)\n {\n \tstruct object_array shallows = OBJECT_ARRAY_INIT;\n@@ -623,53 +672,9 @@ static void receive_needs(void)\n \n \tif (depth == 0 && shallows.nr == 0)\n \t\treturn;\n-\tif (depth > 0) {\n-\t\tstruct commit_list *result = NULL, *backup = NULL;\n-\t\tint i;\n-\t\tif (depth == INFINITE_DEPTH && !is_repository_shallow())\n-\t\t\tfor (i = 0; i < shallows.nr; i++) {\n-\t\t\t\tstruct object *object = shallows.objects[i].item;\n-\t\t\t\tobject->flags |= NOT_SHALLOW;\n-\t\t\t}\n-\t\telse\n-\t\t\tbackup = result =\n-\t\t\t\tget_shallow_commits(&want_obj, depth,\n-\t\t\t\t\t\t SHALLOW, NOT_SHALLOW);\n-\t\twhile (result) {\n-\t\t\tstruct object *object = &result->item->object;\n-\t\t\tif (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {\n-\t\t\t\tpacket_write(1, \"shallow %s\",\n-\t\t\t\t\t\tsha1_to_hex(object->sha1));\n-\t\t\t\tregister_shallow(object->sha1);\n-\t\t\t\tshallow_nr++;\n-\t\t\t}\n-\t\t\tresult = result->next;\n-\t\t}\n-\t\tfree_commit_list(backup);\n-\t\tfor (i = 0; i < shallows.nr; i++) {\n-\t\t\tstruct object *object = shallows.objects[i].item;\n-\t\t\tif (object->flags & NOT_SHALLOW) {\n-\t\t\t\tstruct commit_list *parents;\n-\t\t\t\tpacket_write(1, \"unshallow %s\",\n-\t\t\t\t\tsha1_to_hex(object->sha1));\n-\t\t\t\tobject->flags &= ~CLIENT_SHALLOW;\n-\t\t\t\t/* make sure the real parents are parsed */\n-\t\t\t\tunregister_shallow(object->sha1);\n-\t\t\t\tobject->parsed = 0;\n-\t\t\t\tparse_commit_or_die((struct commit *)object);\n-\t\t\t\tparents = ((struct commit *)object)->parents;\n-\t\t\t\twhile (parents) {\n-\t\t\t\t\tadd_object_array(&parents->item->object,\n-\t\t\t\t\t\t\tNULL, &want_obj);\n-\t\t\t\t\tparents = parents->next;\n-\t\t\t\t}\n-\t\t\t\tadd_object_array(object, NULL, &extra_edge_obj);\n-\t\t\t}\n-\t\t\t/* make sure commit traversal conforms to client */\n-\t\t\tregister_shallow(object->sha1);\n-\t\t}\n-\t\tpacket_flush(1);\n-\t} else\n+\tif (depth > 0)\n+\t\tdeepen(depth, &shallows);\n+\telse\n \t\tif (shallows.nr > 0) {\n \t\t\tint i;\n \t\t\tfor (i = 0; i < shallows.nr; i++)\n-- \n2.3.0.rc1.137.g477eb31\n"},{"id":"257062","messageId":"1425551295-28653-3-git-send-email-pclouds@gmail.com","threadId":"38591","inReplyTo":"1425551295-28653-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 2/6] upload-pack: move \"shallow\" sending code out of deepen()","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2015-03-05T10:28:11Z","receivedAt":"2015-03-05T10:28:11Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Signed-off-by: Nguyễn Thái Ngọc Duy \n---\n upload-pack.c | 25 +++++++++++++++----------\n 1 file changed, 15 insertions(+), 10 deletions(-)\n\ndiff --git a/upload-pack.c b/upload-pack.c\nindex 74f48f9..ea030f3 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -531,6 +531,20 @@ error:\n \t}\n }\n \n+static void send_shallow(struct commit_list *result)\n+{\n+\twhile (result) {\n+\t\tstruct object *object = &result->item->object;\n+\t\tif (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {\n+\t\t\tpacket_write(1, \"shallow %s\",\n+\t\t\t\t sha1_to_hex(object->sha1));\n+\t\t\tregister_shallow(object->sha1);\n+\t\t\tshallow_nr++;\n+\t\t}\n+\t\tresult = result->next;\n+\t}\n+}\n+\n static void deepen(int depth, const struct object_array *shallows)\n {\n \tstruct commit_list *result = NULL, *backup = NULL;\n@@ -544,16 +558,7 @@ static void deepen(int depth, const struct object_array *shallows)\n \t\tbackup = result =\n \t\t\tget_shallow_commits(&want_obj, depth,\n \t\t\t\t\t SHALLOW, NOT_SHALLOW);\n-\twhile (result) {\n-\t\tstruct object *object = &result->item->object;\n-\t\tif (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {\n-\t\t\tpacket_write(1, \"shallow %s\",\n-\t\t\t\t sha1_to_hex(object->sha1));\n-\t\t\tregister_shallow(object->sha1);\n-\t\t\tshallow_nr++;\n-\t\t}\n-\t\tresult = result->next;\n-\t}\n+\tsend_shallow(result);\n \tfree_commit_list(backup);\n \tfor (i = 0; i < shallows->nr; i++) {\n \t\tstruct object *object = shallows->objects[i].item;\n-- \n2.3.0.rc1.137.g477eb31\n"},{"id":"257061","messageId":"1425551295-28653-4-git-send-email-pclouds@gmail.com","threadId":"38591","inReplyTo":"1425551295-28653-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 3/6] upload-pack: remove unused variable \"backup\"","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2015-03-05T10:28:12Z","receivedAt":"2015-03-05T10:28:12Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Signed-off-by: Nguyễn Thái Ngọc Duy \n---\n upload-pack.c | 6 +++---\n 1 file changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/upload-pack.c b/upload-pack.c\nindex ea030f3..79f5525 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -547,7 +547,7 @@ static void send_shallow(struct commit_list *result)\n \n static void deepen(int depth, const struct object_array *shallows)\n {\n-\tstruct commit_list *result = NULL, *backup = NULL;\n+\tstruct commit_list *result = NULL;\n \tint i;\n \tif (depth == INFINITE_DEPTH && !is_repository_shallow())\n \t\tfor (i = 0; i < shallows->nr; i++) {\n@@ -555,11 +555,11 @@ static void deepen(int depth, const struct object_array *shallows)\n \t\t\tobject->flags |= NOT_SHALLOW;\n \t\t}\n \telse\n-\t\tbackup = result =\n+\t\tresult =\n \t\t\tget_shallow_commits(&want_obj, depth,\n \t\t\t\t\t SHALLOW, NOT_SHALLOW);\n \tsend_shallow(result);\n-\tfree_commit_list(backup);\n+\tfree_commit_list(result);\n \tfor (i = 0; i < shallows->nr; i++) {\n \t\tstruct object *object = shallows->objects[i].item;\n \t\tif (object->flags & NOT_SHALLOW) {\n-- \n2.3.0.rc1.137.g477eb31\n"},{"id":"257063","messageId":"1425551295-28653-5-git-send-email-pclouds@gmail.com","threadId":"38591","inReplyTo":"1425551295-28653-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 4/6] upload-pack: move \"unshallow\" sending code out of deepen()","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2015-03-05T10:28:13Z","receivedAt":"2015-03-05T10:28:13Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Signed-off-by: Nguyễn Thái Ngọc Duy \n---\n upload-pack.c | 33 ++++++++++++++++++++-------------\n 1 file changed, 20 insertions(+), 13 deletions(-)\n\ndiff --git a/upload-pack.c b/upload-pack.c\nindex 79f5525..69a3828 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -545,21 +545,10 @@ static void send_shallow(struct commit_list *result)\n \t}\n }\n \n-static void deepen(int depth, const struct object_array *shallows)\n+static void send_unshallow(const struct object_array *shallows)\n {\n-\tstruct commit_list *result = NULL;\n \tint i;\n-\tif (depth == INFINITE_DEPTH && !is_repository_shallow())\n-\t\tfor (i = 0; i < shallows->nr; i++) {\n-\t\t\tstruct object *object = shallows->objects[i].item;\n-\t\t\tobject->flags |= NOT_SHALLOW;\n-\t\t}\n-\telse\n-\t\tresult =\n-\t\t\tget_shallow_commits(&want_obj, depth,\n-\t\t\t\t\t SHALLOW, NOT_SHALLOW);\n-\tsend_shallow(result);\n-\tfree_commit_list(result);\n+\n \tfor (i = 0; i < shallows->nr; i++) {\n \t\tstruct object *object = shallows->objects[i].item;\n \t\tif (object->flags & NOT_SHALLOW) {\n@@ -582,6 +571,24 @@ static void deepen(int depth, const struct object_array *shallows)\n \t\t/* make sure commit traversal conforms to client */\n \t\tregister_shallow(object->sha1);\n \t}\n+}\n+\n+static void deepen(int depth, const struct object_array *shallows)\n+{\n+\tstruct commit_list *result = NULL;\n+\tint i;\n+\tif (depth == INFINITE_DEPTH && !is_repository_shallow())\n+\t\tfor (i = 0; i < shallows->nr; i++) {\n+\t\t\tstruct object *object = shallows->objects[i].item;\n+\t\t\tobject->flags |= NOT_SHALLOW;\n+\t\t}\n+\telse\n+\t\tresult =\n+\t\t\tget_shallow_commits(&want_obj, depth,\n+\t\t\t\t\t SHALLOW, NOT_SHALLOW);\n+\tsend_shallow(result);\n+\tfree_commit_list(result);\n+\tsend_unshallow(shallows);\n \tpacket_flush(1);\n }\n \n-- \n2.3.0.rc1.137.g477eb31\n"},{"id":"257064","messageId":"1425551295-28653-6-git-send-email-pclouds@gmail.com","threadId":"38591","inReplyTo":"1425551295-28653-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 5/6] shallow.c: implement a generic shallow boundary finder based on rev-list","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2015-03-05T10:28:14Z","receivedAt":"2015-03-05T10:28:14Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Instead of a custom commit walker like get_shallow_commits(), this new\nfunction uses rev-list to mark SHALLOW to all reachable commits. The\ndefinition of reachable is to be defined by the protocol later. This\nmakes it more flexible to define shallow boundary.\n\nNote: if a commit has one not_shallow parent and one shallow parent,\nthen it's considered the boundary. Which means in the client side,\nthis commit has _no_ parents. This could lead to surprising cuts if\nwe're not careful.\n\nAnother option is to include more commits and only mark commits whose\nall parents are not-shallow as boundary.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n commit.h | 2 ++\n shallow.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 67 insertions(+)\n\ndiff --git a/commit.h b/commit.h\nindex 9f189cb..5c80eea 100644\n--- a/commit.h\n+++ b/commit.h\n@@ -254,6 +254,8 @@ extern int for_each_commit_graft(each_commit_graft_fn, void *);\n extern int is_repository_shallow(void);\n extern struct commit_list *get_shallow_commits(struct object_array *heads,\n \t\tint depth, int shallow_flag, int not_shallow_flag);\n+extern struct commit_list *get_shallow_commits_by_rev_list(\n+\t\tint ac, const char **av, int shallow_flag, int not_shallow_flag);\n extern void set_alternate_shallow_file(const char *path, int override);\n extern int write_shallow_commits(struct strbuf *out, int use_pack_protocol,\n \t\t\t\t const struct sha1_array *extra);\ndiff --git a/shallow.c b/shallow.c\nindex d8bf40a..1db2768 100644\n--- a/shallow.c\n+++ b/shallow.c\n@@ -10,6 +10,8 @@\n #include \"revision.h\"\n #include \"commit-slab.h\"\n #include \"sigchain.h\"\n+#include \"revision.h\"\n+#include \"list-objects.h\"\n \n static int is_shallow = -1;\n static struct stat_validity shallow_stat;\n@@ -137,6 +139,69 @@ struct commit_list *get_shallow_commits(struct object_array *heads, int depth,\n \treturn result;\n }\n \n+static void show_commit(struct commit *commit, void *data)\n+{\n+\tcommit->object.flags |= *(int *)data;\n+}\n+\n+struct commit_list *get_shallow_commits_by_rev_list(int ac, const char **av,\n+\t\t\t\t\t\t int shallow_flag, int not_shallow_flag)\n+{\n+\tstruct commit_list *result = NULL;\n+\tstruct rev_info revs;\n+\tunsigned int i, nr;\n+\n+\t/*\n+\t * SHALLOW and NOT_SHALLOW should not be set at this\n+\t * point. But better be safe than sorry.\n+\t */\n+\tnr = get_max_object_index();\n+\tfor (i = 0; i < nr; i++) {\n+\t\tstruct object *o = get_indexed_object(i);\n+\t\to->flags &= ~(shallow_flag | not_shallow_flag);\n+\t}\n+\n+\tis_repository_shallow(); /* make sure shallows are read */\n+\n+\tinit_revisions(&revs, NULL);\n+\tsave_commit_buffer = 0;\n+\tsetup_revisions(ac, av, &revs, NULL);\n+\n+\t/* mark all reachable commits as SHALLOW */\n+\tif (prepare_revision_walk(&revs))\n+\t\tdie(\"revision walk setup failed\");\n+\ttraverse_commit_list(&revs, show_commit, NULL, &shallow_flag);\n+\n+\tnr = get_max_object_index();\n+\tfor (i = 0; i < nr; i++) {\n+\t\tstruct object *o = get_indexed_object(i);\n+\t\tstruct commit *c = (struct commit *)o;\n+\t\tstruct commit_list *p;\n+\t\tint parent_is_not_shallow = 0;\n+\n+\t\tif (o->type != OBJ_COMMIT || !(o->flags & shallow_flag))\n+\t\t\tcontinue;\n+\n+\t\tif (parse_commit(c))\n+\t\t\tdie(\"unable to parse commit %s\",\n+\t\t\t sha1_to_hex(c->object.sha1));\n+\n+\t\tfor (p = c->parents; p; p = p->next) {\n+\t\t\tif (p->item->object.flags & shallow_flag)\n+\t\t\t\tcontinue;\n+\t\t\tparent_is_not_shallow = 1;\n+\t\t\tif (p->item->object.flags & not_shallow_flag)\n+\t\t\t\tcontinue;\n+\t\t\tp->item->object.flags |= not_shallow_flag;\n+\t\t\tcommit_list_insert(p->item, &result);\n+\t\t}\n+\n+\t\tif (parent_is_not_shallow)\n+\t\t\tcommit_list_insert(c, &result);\n+\t}\n+\treturn result;\n+}\n+\n static void check_shallow_file_for_update(void)\n {\n \tif (is_shallow == -1)\n-- \n2.3.0.rc1.137.g477eb31\n"},{"id":"257065","messageId":"1425551295-28653-7-git-send-email-pclouds@gmail.com","threadId":"38591","inReplyTo":"1425551295-28653-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 6/6] upload-pack: example code to use get_shallow_commits_by_rev_list","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2015-03-05T10:28:15Z","receivedAt":"2015-03-05T10:28:15Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Signed-off-by: Nguyễn Thái Ngọc Duy \n---\n upload-pack.c | 18 ++++++++++++++++++\n 1 file changed, 18 insertions(+)\n\ndiff --git a/upload-pack.c b/upload-pack.c\nindex 69a3828..e616e19 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -592,6 +592,18 @@ static void deepen(int depth, const struct object_array *shallows)\n \tpacket_flush(1);\n }\n \n+static void deepen_by_rev_list(int ac, const char **av,\n+\t\t\t struct object_array *shallows)\n+{\n+\tstruct commit_list *result;\n+\n+\tresult = get_shallow_commits_by_rev_list(ac, av, SHALLOW, NOT_SHALLOW);\n+\tsend_shallow(result);\n+\tfree_commit_list(result);\n+\tsend_unshallow(shallows);\n+\tpacket_flush(1);\n+}\n+\n static void receive_needs(void)\n {\n \tstruct object_array shallows = OBJECT_ARRAY_INIT;\n@@ -686,6 +698,12 @@ static void receive_needs(void)\n \t\treturn;\n \tif (depth > 0)\n \t\tdeepen(depth, &shallows);\n+#if 0\n+\telse if (since_is_specified) {\n+\t\t/* prepare ac, av */\n+\t\tdeepen_by_rev_list(ac, av, &shallows);\n+\t}\n+#endif\n \telse\n \t\tif (shallows.nr > 0) {\n \t\t\tint i;\n-- \n2.3.0.rc1.137.g477eb31\n"},{"id":"257149","messageId":"20150306112434.GA10703@lanh","threadId":"38591","inReplyTo":"xmqqsidk3r17.fsf@gitster.dls.corp.google.com","subject":"Re: [RFH] GSoC 2015 application","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-03-06T11:24:34Z","receivedAt":"2015-03-06T11:24:34Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Mar 04, 2015 at 10:19:16PM -0800, Junio C Hamano wrote:\n> But we would need some way to say a set-based cut-off; I do not\n> think using --since for that purpose is a good idea, though, because\n> that is already taken for date-based cut-off, and mixing them\n> together will introduce confusion.\n\nI agree. Although I look at this from the implementation perspective:\nmixing the two would make it really hard to detect which is which.\nSpeaking of implementation..\n\nOn Thu, Mar 5, 2015 at 5:28 PM, Nguyễn Thái Ngọc Duy wrote:\n> I do have plenty of topics to finish up. But I wanted to see how this\n> feature would look like. I needed to write some code for that and for\n> straightening my thoughts. Totally untested, but I think it looks cool :)\n>\n> I think this feature is feasible. The protocol and UI are still up in\n> the air. Plenty of work for any student who wants to pick this up.\n\nI think students are losing the chance to have this fun now. A rough\nimplementation is available at\n\n https://github.com/pclouds/git/tree/shallow-since\n\nif anybody wants to try out. I don't post it here yet because while it\nseems to be working in my limited tests, there could be some corner\ncases to sort out, bugs and style violations. Also tests to be added.\n\nDocumentation changes below. --not and --since can be mixed. Neither\nof them can be used with --depth though, but I'd consider it a\ntemporary limitation.\n\ndiff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\nindex b09a783..ec68374 100644\n--- a/Documentation/fetch-options.txt\n+++ b/Documentation/fetch-options.txt\n@@ -13,6 +13,15 @@\n \tto the specified number of commits from the tip of each remote\n \tbranch history. Tags for the deepened commits are not fetched.\n \n+--since=::\n+\tDeepen or shorten the history of a 'shallow' repository to\n+\tinclude all reachable commits that are after .\n+\n+--not=::\n+\tDeepen or shorten the history of a 'shallow' repository to\n+\texclude commits reachable from a specified remote branch or tag.\n+\tThis option can be specified multiple times.\n+\n --unshallow::\n \tIf the source repository is complete, convert a shallow\n \trepository to a complete one, removing all the limitations\ndiff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\nindex f1f2a3f..fc094c6 100644\n--- a/Documentation/git-clone.txt\n+++ b/Documentation/git-clone.txt\n@@ -187,6 +187,14 @@ objects from the source repository into a pack in the cloned repository.\n \tCreate a 'shallow' clone with a history truncated to the\n \tspecified number of revisions.\n \n+--since=::\n+\tCreate a 'shallow' clone with a history after the specified time.\n+\n+--not=::\n+\tCreate a 'shallow' clone with a history, excluding commits\n+\treachable from a specified remote branch or tag. This option\n+\tcan be specified multiple times.\n+\n --[no-]single-branch::\n \tClone only the history leading to the tip of a single branch,\n \teither specified by the `--branch` option or the primary\ndiff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt\nindex 4f8a7bf..3649301 100644\n--- a/Documentation/technical/protocol-capabilities.txt\n+++ b/Documentation/technical/protocol-capabilities.txt\n@@ -179,6 +179,24 @@ This capability adds \"deepen\", \"shallow\" and \"unshallow\" commands to\n the fetch-pack/upload-pack protocol so clients can request shallow\n clones.\n \n+deepen-since\n+------------\n+\n+This capability adds \"deepen-since\" command to fetch-pack/upload-pack\n+protocol so the client can request shallow clones that are cut at a\n+specific time, instead of depth. Internally it's equivalent of doing\n+\"rev-list --since=