* [RFH] GSoC 2015 application @ 2015-02-18 19:14 Jeff King 2015-02-18 19:32 ` Jeff King ` (5 more replies) 0 siblings, 6 replies; 74+ messages in thread From: Jeff King @ 2015-02-18 19:14 UTC (permalink / raw) To: git The response to my previous email was not overwhelming, but people did express some interest in Git doing GSoC this year. So I've started on the application, using last year's version as a template. The materials are all in: https://github.com/git/git.github.io If you'd like to help, I'm happy to take emailed patches, pull requests, or just plain-English suggestions. If you want push access to that repository, email me. A draft of the application is here: http://git.github.io/SoC-2015-Org-Application.html The questions are the same as last year, so with the exception of some reviewing and updating for the new year, this shouldn't be too much work. I do need somebody to volunteer as backup admin. This doesn't need to involve any specific commitment, but is mostly about what to do if I get hit by a bus. Of course helping with application review, coordinating mentors, etc, is welcome from the backup admin. Where I really need help now is in the "ideas" page: http://git.github.io/SoC-2015-Ideas.html and the list of microprojects: http://git.github.io/SoC-2015-Microprojects.html Note that I've listed microprojects as required for students this year (whereas last year, we only strongly encouraged them). I think they worked very well, but that requirement is up for debate. We may be able to port over ideas or microprojects from last year, but I want to do so only after somebody has confirmed that they are still in need of doing. And of course new ideas and microprojects are very welcome. The students will not begin looking at these until the participating projects are announced. But the GSoC folks _will_ be looking at the Ideas page, which is linked from the application. So while we can tweak it later, it needs to have content now (in the next 48 hours). So if you must choose which to focus your efforts on, do Ideas first. -Peff ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-18 19:14 [RFH] GSoC 2015 application Jeff King @ 2015-02-18 19:32 ` Jeff King 2015-02-24 12:01 ` Johannes Schindelin 2015-02-18 21:54 ` Junio C Hamano ` (4 subsequent siblings) 5 siblings, 1 reply; 74+ messages in thread From: Jeff King @ 2015-02-18 19:32 UTC (permalink / raw) To: git; +Cc: msysGit Cc-ing this to the msysgit list, which I should have done in the first place. Certainly ideas specific to Git for Windows would be welcome. On Wed, Feb 18, 2015 at 02:14:17PM -0500, Jeff King wrote: > The response to my previous email was not overwhelming, but people did > express some interest in Git doing GSoC this year. So I've started on > the application, using last year's version as a template. > > The materials are all in: > > https://github.com/git/git.github.io > > If you'd like to help, I'm happy to take emailed patches, pull requests, > or just plain-English suggestions. If you want push access to that > repository, email me. > > A draft of the application is here: > > http://git.github.io/SoC-2015-Org-Application.html > > The questions are the same as last year, so with the exception of some > reviewing and updating for the new year, this shouldn't be too much > work. I do need somebody to volunteer as backup admin. This doesn't need > to involve any specific commitment, but is mostly about what to do if I > get hit by a bus. Of course helping with application review, > coordinating mentors, etc, is welcome from the backup admin. > > Where I really need help now is in the "ideas" page: > > http://git.github.io/SoC-2015-Ideas.html > > and the list of microprojects: > > http://git.github.io/SoC-2015-Microprojects.html > > Note that I've listed microprojects as required for students this year > (whereas last year, we only strongly encouraged them). I think they > worked very well, but that requirement is up for debate. > > We may be able to port over ideas or microprojects from last year, but I > want to do so only after somebody has confirmed that they are still in > need of doing. And of course new ideas and microprojects are very > welcome. > > The students will not begin looking at these until the participating > projects are announced. But the GSoC folks _will_ be looking at the > Ideas page, which is linked from the application. So while we can tweak > it later, it needs to have content now (in the next 48 hours). So if you > must choose which to focus your efforts on, do Ideas first. > > -Peff ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Re: [RFH] GSoC 2015 application 2015-02-18 19:32 ` Jeff King @ 2015-02-24 12:01 ` Johannes Schindelin 2015-02-24 12:06 ` [msysGit] " Jeff King 2015-02-24 17:32 ` Matthieu Moy 0 siblings, 2 replies; 74+ messages in thread From: Johannes Schindelin @ 2015-02-24 12:01 UTC (permalink / raw) To: Jeff King; +Cc: git, msysGit Hi Peff, On 2015-02-18 20:32, Jeff King wrote: > On Wed, Feb 18, 2015 at 02:14:17PM -0500, Jeff King wrote: > >> The response to my previous email was not overwhelming, but people did >> express some interest in Git doing GSoC this year. So I've started on >> the application, using last year's version as a template. I feel unqualified to fill in the information, having kept out of the loop of the past years' GSoC efforts. After considerable consideration, I am offering to mentor Windows-related projects (into which I count conversion of scripts into builtins). Thanks, Dscho -- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups "msysGit" group. To post to this group, send email to msysgit@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscribe@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "Git for Windows" group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [msysGit] Re: [RFH] GSoC 2015 application 2015-02-24 12:01 ` Johannes Schindelin @ 2015-02-24 12:06 ` Jeff King 2015-02-24 12:25 ` Johannes Schindelin 2015-02-24 17:32 ` Matthieu Moy 1 sibling, 1 reply; 74+ messages in thread From: Jeff King @ 2015-02-24 12:06 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git, msysGit On Tue, Feb 24, 2015 at 01:01:17PM +0100, Johannes Schindelin wrote: > After considerable consideration, I am offering to mentor > Windows-related projects (into which I count conversion of scripts > into builtins). Thanks! No rush, as we are not even accepted yet, but you can create a profile at: http://google-melange.com and ask to join the "git" project as a mentor. You may also want to add Windows-specific ideas to the page at: https://github.com/git/git.github.io/blob/master/SoC-2015-Ideas.md Even something high-level like "helping move programs to builtins to help Windows" will let students know that it's a potential direction. -Peff ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Re: [RFH] GSoC 2015 application 2015-02-24 12:06 ` [msysGit] " Jeff King @ 2015-02-24 12:25 ` Johannes Schindelin 2015-02-24 12:28 ` [msysGit] " Jeff King 0 siblings, 1 reply; 74+ messages in thread From: Johannes Schindelin @ 2015-02-24 12:25 UTC (permalink / raw) To: Jeff King; +Cc: git, msysGit Hi Peff, On 2015-02-24 13:06, Jeff King wrote: > On Tue, Feb 24, 2015 at 01:01:17PM +0100, Johannes Schindelin wrote: > >> After considerable consideration, I am offering to mentor >> Windows-related projects (into which I count conversion of scripts >> into builtins). > > Thanks! No rush, as we are not even accepted yet, but you can create a > profile at: > > http://google-melange.com > > and ask to join the "git" project as a mentor. I guess I can only ask that after the org is accepted, I will do so when (and if) that is the case. > You may also want to add Windows-specific ideas to the page at: > > https://github.com/git/git.github.io/blob/master/SoC-2015-Ideas.md > > Even something high-level like "helping move programs to builtins to > help Windows" will let students know that it's a potential direction. Done: https://github.com/git/git.github.io/pull/12 Thank you, Dscho -- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups "msysGit" group. To post to this group, send email to msysgit@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscribe@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "Git for Windows" group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [msysGit] Re: [RFH] GSoC 2015 application 2015-02-24 12:25 ` Johannes Schindelin @ 2015-02-24 12:28 ` Jeff King 2015-02-25 9:25 ` Johannes Schindelin 0 siblings, 1 reply; 74+ messages in thread From: Jeff King @ 2015-02-24 12:28 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git, msysGit On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote: > > Thanks! No rush, as we are not even accepted yet, but you can create a > > profile at: > > > > http://google-melange.com > > > > and ask to join the "git" project as a mentor. > > I guess I can only ask that after the org is accepted, I will do so > when (and if) that is the case. I think you can do it now; I had to create the project profile in order to do the application. But again, no rush. > Done: https://github.com/git/git.github.io/pull/12 Thanks, merged. -Peff ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [msysGit] Re: [RFH] GSoC 2015 application 2015-02-24 12:28 ` [msysGit] " Jeff King @ 2015-02-25 9:25 ` Johannes Schindelin 2015-02-25 9:39 ` Matthieu Moy 2015-02-25 10:25 ` Matthieu Moy 0 siblings, 2 replies; 74+ messages in thread From: Johannes Schindelin @ 2015-02-25 9:25 UTC (permalink / raw) To: Jeff King; +Cc: git, msysGit Hi Peff, On 2015-02-24 13:28, Jeff King wrote: > On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote: > >> > Thanks! No rush, as we are not even accepted yet, but you can create a >> > profile at: >> > >> > http://google-melange.com >> > >> > and ask to join the "git" project as a mentor. >> >> I guess I can only ask that after the org is accepted, I will do so >> when (and if) that is the case. > > I think you can do it now; I had to create the project profile in order > to do the application. But again, no rush. I tried, but there are no orgs listed as of yet when I click "Make connection". >> Done: https://github.com/git/git.github.io/pull/12 > > Thanks, merged. I opened another PR, based on Mathieu's advice. Ciao, Dscho ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Re: [RFH] GSoC 2015 application 2015-02-25 9:25 ` Johannes Schindelin @ 2015-02-25 9:39 ` Matthieu Moy 2015-02-25 10:25 ` Matthieu Moy 1 sibling, 0 replies; 74+ messages in thread From: Matthieu Moy @ 2015-02-25 9:39 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Jeff King, git, msysGit Johannes Schindelin <johannes.schindelin@gmx.de> writes: >>> Done: https://github.com/git/git.github.io/pull/12 >> >> Thanks, merged. > > I opened another PR, based on Mathieu's advice. Thanks, merged. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups "msysGit" group. To post to this group, send email to msysgit@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscribe@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "Git for Windows" group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Re: [RFH] GSoC 2015 application 2015-02-25 9:25 ` Johannes Schindelin 2015-02-25 9:39 ` Matthieu Moy @ 2015-02-25 10:25 ` Matthieu Moy 2015-02-25 12:15 ` Johannes Schindelin 1 sibling, 1 reply; 74+ messages in thread From: Matthieu Moy @ 2015-02-25 10:25 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Jeff King, git, msysGit ----- Original Message ----- > Hi Peff, > > On 2015-02-24 13:28, Jeff King wrote: > > On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote: > > > >> > Thanks! No rush, as we are not even accepted yet, but you can create a > >> > profile at: > >> > > >> > http://google-melange.com > >> > > >> > and ask to join the "git" project as a mentor. > >> > >> I guess I can only ask that after the org is accepted, I will do so > >> when (and if) that is the case. > > > > I think you can do it now; I had to create the project profile in order > > to do the application. But again, no rush. > > I tried, but there are no orgs listed as of yet when I click "Make > connection". Not sure what it's supposed to look like, but I think if you give us your username we can invite you as mentor. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups "msysGit" group. To post to this group, send email to msysgit@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscribe@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "Git for Windows" group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Re: [RFH] GSoC 2015 application 2015-02-25 10:25 ` Matthieu Moy @ 2015-02-25 12:15 ` Johannes Schindelin 0 siblings, 0 replies; 74+ messages in thread From: Johannes Schindelin @ 2015-02-25 12:15 UTC (permalink / raw) To: Matthieu Moy; +Cc: Jeff King, git, msysGit Hi Matthieu, On 2015-02-25 11:25, Matthieu Moy wrote: > ----- Original Message ----- >> On 2015-02-24 13:28, Jeff King wrote: >> > On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote: >> > >> >> > Thanks! No rush, as we are not even accepted yet, but you can create a >> >> > profile at: >> >> > >> >> > http://google-melange.com >> >> > >> >> > and ask to join the "git" project as a mentor. >> >> >> >> I guess I can only ask that after the org is accepted, I will do so >> >> when (and if) that is the case. >> > >> > I think you can do it now; I had to create the project profile in order >> > to do the application. But again, no rush. >> >> I tried, but there are no orgs listed as of yet when I click "Make >> connection". > > Not sure what it's supposed to look like, but I think if you give us > your username we can invite you as mentor. Thanks. My username is – surprise! – 'dscho' ;-) Ciao, Dscho -- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups "msysGit" group. To post to this group, send email to msysgit@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscribe@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "Git for Windows" group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Re: [RFH] GSoC 2015 application 2015-02-24 12:01 ` Johannes Schindelin 2015-02-24 12:06 ` [msysGit] " Jeff King @ 2015-02-24 17:32 ` Matthieu Moy 2015-02-24 18:25 ` Junio C Hamano 1 sibling, 1 reply; 74+ messages in thread From: Matthieu Moy @ 2015-02-24 17:32 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Jeff King, git, msysGit Johannes Schindelin <johannes.schindelin@gmx.de> writes: > After considerable consideration, I am offering to mentor > Windows-related projects (into which I count conversion of scripts > into builtins). Good news! About the proposal: The idea of this project is to dive into the Git source code and convert, say, git-add--interactive.perl and/or git stash into proper C code, making it a so-called "built-in". My advice would be to try converting several small scripts, and avoid targetting a big one. This way, you can have a first patch series reviewed on-list, and merged in pu rather soon. From my experience, an early review is very important to get the student on track, and splitting the GSoC into multiple related projects avoids the situation where you have the feature "95% completed" at the end of the GSoC, but nothing merged. add--interactive and stash are relatively complex beasts, perhaps git-pull.sh would be easier to start with. OTOH, you know which script would be most useful to be converted into a builtin much better than me! -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups "msysGit" group. To post to this group, send email to msysgit@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscribe@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "Git for Windows" group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Re: [RFH] GSoC 2015 application 2015-02-24 17:32 ` Matthieu Moy @ 2015-02-24 18:25 ` Junio C Hamano 2015-02-24 20:33 ` Johannes Schindelin 0 siblings, 1 reply; 74+ messages in thread From: Junio C Hamano @ 2015-02-24 18:25 UTC (permalink / raw) To: Matthieu Moy; +Cc: Johannes Schindelin, Jeff King, Git Mailing List, msysGit On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: > About the proposal: > > The idea of this project is to dive into the Git source code and > convert, say, git-add--interactive.perl and/or git stash into proper C > code, making it a so-called "built-in". > > My advice would be to try converting several small scripts, and avoid > targetting a big one.... > add--interactive and stash are relatively complex beasts, perhaps > git-pull.sh would be easier to start with. Yeah, I think that is a very good suggestion. Also drop "proper" as if scripted Porcelains are second class citizens ;-) -- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups "msysGit" group. To post to this group, send email to msysgit@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscribe@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "Git for Windows" group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Re: [RFH] GSoC 2015 application 2015-02-24 18:25 ` Junio C Hamano @ 2015-02-24 20:33 ` Johannes Schindelin 2015-02-24 21:02 ` Junio C Hamano 2015-02-24 23:56 ` Matthieu Moy 0 siblings, 2 replies; 74+ messages in thread From: Johannes Schindelin @ 2015-02-24 20:33 UTC (permalink / raw) To: Junio C Hamano; +Cc: Matthieu Moy, Jeff King, Git Mailing List, msysGit Hi Junio, On 2015-02-24 19:25, Junio C Hamano wrote: > On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy > <Matthieu.Moy@grenoble-inp.fr> wrote: >> About the proposal: >> >> The idea of this project is to dive into the Git source code and >> convert, say, git-add--interactive.perl and/or git stash into proper C >> code, making it a so-called "built-in". >> >> My advice would be to try converting several small scripts, and avoid >> targetting a big one.... >> add--interactive and stash are relatively complex beasts, perhaps >> git-pull.sh would be easier to start with. > > Yeah, I think that is a very good suggestion. 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. > Also drop "proper" as if scripted Porcelains are second class citizens ;-) If 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. Ciao, Dscho -- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups "msysGit" group. To post to this group, send email to msysgit@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscribe@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "Git for Windows" group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-24 20:33 ` Johannes Schindelin @ 2015-02-24 21:02 ` Junio C Hamano 2015-02-24 23:56 ` Matthieu Moy 1 sibling, 0 replies; 74+ messages in thread From: Junio C Hamano @ 2015-02-24 21:02 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Matthieu Moy, Jeff King, Git Mailing List, msysGit Johannes Schindelin <johannes.schindelin@gmx.de> writes: >> Also drop "proper" as if scripted Porcelains are second class citizens ;-) > > If 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. Perhaps that might be the case. But I am polite enough to refrain from calling that "not a problem on 'proper' platforms". I expect the same courtesy from others ;-). -- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups "msysGit" group. To post to this group, send email to msysgit@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscribe@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "Git for Windows" group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Re: [RFH] GSoC 2015 application 2015-02-24 20:33 ` Johannes Schindelin 2015-02-24 21:02 ` Junio C Hamano @ 2015-02-24 23:56 ` Matthieu Moy 2015-02-25 0:34 ` [msysGit] " Stefan Beller ` (2 more replies) 1 sibling, 3 replies; 74+ messages in thread From: Matthieu Moy @ 2015-02-24 23:56 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, Jeff King, Git Mailing List, msysGit Johannes Schindelin <johannes.schindelin@gmx.de> writes: > Hi Junio, > > On 2015-02-24 19:25, Junio C Hamano wrote: >> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy >> <Matthieu.Moy@grenoble-inp.fr> wrote: >>> About the proposal: >>> >>> The idea of this project is to dive into the Git source code and >>> convert, say, git-add--interactive.perl and/or git stash into proper C >>> code, making it a so-called "built-in". >>> >>> My advice would be to try converting several small scripts, and avoid >>> targetting a big one.... >>> add--interactive and stash are relatively complex beasts, perhaps >>> git-pull.sh would be easier to start with. >> >> Yeah, I think that is a very good suggestion. > > 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. To get an idea, I counted the lines of code written by the student I mentored last year: $ git log --author tanayabh@gmail.com -p | diffstat -s 43 files changed, 1225 insertions(+), 367 deletions(-) I would consider this GSoC as "average" (i.e. not exceptionnally good, but certainly not a bad one either), so you may hope for more, but you should not _expect_ much more IMHO. In comparison: $ wc -l git-add--interactive.perl 1654 git-add--interactive.perl $ wc -l git-stash.sh 617 git-stash.sh I'd expect a rewrite in C to at least double the number of lines of code, so rewriting git-stash would mean writting at least as many lines of code as the GSoC above. git-add--interactive.perl would be rather far above. But my point was not to convert _only_ git-pull.sh, but to have a GSoC starting with this one and plan more. Then, depending on how it goes, you can adjust the target. This all depends on what you intend to do if the student does not finish the job. If you're going to do the rewrite yourself anyway, then having the student do even half of it is good already. If you're not going to finish the job by yourself, then a 95%-done-rewrite means a piece of code posted on the mailing list and never merged (and a lot of time wasted). In any case, these are just advices, certainly not objections or hard requests to change. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups "msysGit" group. To post to this group, send email to msysgit@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscribe@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "Git for Windows" group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [msysGit] Re: [RFH] GSoC 2015 application 2015-02-24 23:56 ` Matthieu Moy @ 2015-02-25 0:34 ` Stefan Beller 2015-02-25 9:25 ` Michael J Gruber 2015-02-25 8:44 ` Johannes Schindelin 2015-02-25 10:02 ` Duy Nguyen 2 siblings, 1 reply; 74+ messages in thread From: Stefan Beller @ 2015-02-25 0:34 UTC (permalink / raw) To: Matthieu Moy Cc: Johannes Schindelin, Junio C Hamano, Jeff King, Git Mailing List, msysGit On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: > Johannes Schindelin <johannes.schindelin@gmx.de> writes: > >> Hi Junio, >> >> On 2015-02-24 19:25, Junio C Hamano wrote: >>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy >>> <Matthieu.Moy@grenoble-inp.fr> wrote: >>>> About the proposal: >>>> >>>> The idea of this project is to dive into the Git source code and >>>> convert, say, git-add--interactive.perl and/or git stash into proper C >>>> code, making it a so-called "built-in". >>>> >>>> My advice would be to try converting several small scripts, and avoid >>>> targetting a big one.... >>>> add--interactive and stash are relatively complex beasts, perhaps >>>> git-pull.sh would be easier to start with. >>> >>> Yeah, I think that is a very good suggestion. >> >> 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. > > To get an idea, I counted the lines of code written by the student I > mentored last year: > > $ git log --author tanayabh@gmail.com -p | diffstat -s > 43 files changed, 1225 insertions(+), 367 deletions(-) > > I would consider this GSoC as "average" (i.e. not exceptionnally good, > but certainly not a bad one either), so you may hope for more, but you > should not _expect_ much more IMHO. > > In comparison: > > $ wc -l git-add--interactive.perl > 1654 git-add--interactive.perl > $ wc -l git-stash.sh > 617 git-stash.sh > > I'd expect a rewrite in C to at least double the number of lines of > code, so rewriting git-stash would mean writting at least as many lines > of code as the GSoC above. git-add--interactive.perl would be rather far > above. > > But my point was not to convert _only_ git-pull.sh, but to have a GSoC > starting with this one and plan more. Then, depending on how it goes, > you can adjust the target. > > This all depends on what you intend to do if the student does not finish > the job. If you're going to do the rewrite yourself anyway, then having > the student do even half of it is good already. If you're not going to > finish the job by yourself, then a 95%-done-rewrite means a piece of > code posted on the mailing list and never merged (and a lot of time > wasted). > > In any case, these are just advices, certainly not objections or hard > requests to change. > Once upon a time (Sep 2013) I rewrote builtin/repack.c which was a shell script before. I did not have much real-coding expertise with the git community before and by today there are 403 lines of code in builtin/repack.c. so going for roughly 3 times (1200 lines of code) change would make a summer, specially if you need to learn how the workflow is in the open source world. There the lines in c doubled nearly exactly. (before 197 shell lines, afterwards 387 c lines). Just last weekend I met people, who were afraid of contributing to open source "because sometimes the internet can be very mean". Git being quite a high profile project, as it is widely used, might not help, but rather fear people away. That said I would not underestimate the initial time a student needs to learn the workflow. Though most of that learning is done in the micro project phase. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [msysGit] Re: [RFH] GSoC 2015 application 2015-02-25 0:34 ` [msysGit] " Stefan Beller @ 2015-02-25 9:25 ` Michael J Gruber 0 siblings, 0 replies; 74+ messages in thread From: Michael J Gruber @ 2015-02-25 9:25 UTC (permalink / raw) To: Stefan Beller, Matthieu Moy Cc: Johannes Schindelin, Junio C Hamano, Jeff King, Git Mailing List, msysGit Stefan Beller venit, vidit, dixit 25.02.2015 01:34: > On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy > <Matthieu.Moy@grenoble-inp.fr> wrote: >> Johannes Schindelin <johannes.schindelin@gmx.de> writes: >> >>> Hi Junio, >>> >>> On 2015-02-24 19:25, Junio C Hamano wrote: >>>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy >>>> <Matthieu.Moy@grenoble-inp.fr> wrote: >>>>> About the proposal: >>>>> >>>>> The idea of this project is to dive into the Git source code and >>>>> convert, say, git-add--interactive.perl and/or git stash into proper C >>>>> code, making it a so-called "built-in". >>>>> >>>>> My advice would be to try converting several small scripts, and avoid >>>>> targetting a big one.... >>>>> add--interactive and stash are relatively complex beasts, perhaps >>>>> git-pull.sh would be easier to start with. >>>> >>>> Yeah, I think that is a very good suggestion. >>> >>> 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. >> >> To get an idea, I counted the lines of code written by the student I >> mentored last year: >> >> $ git log --author tanayabh@gmail.com -p | diffstat -s >> 43 files changed, 1225 insertions(+), 367 deletions(-) >> >> I would consider this GSoC as "average" (i.e. not exceptionnally good, >> but certainly not a bad one either), so you may hope for more, but you >> should not _expect_ much more IMHO. >> >> In comparison: >> >> $ wc -l git-add--interactive.perl >> 1654 git-add--interactive.perl >> $ wc -l git-stash.sh >> 617 git-stash.sh >> >> I'd expect a rewrite in C to at least double the number of lines of >> code, so rewriting git-stash would mean writting at least as many lines >> of code as the GSoC above. git-add--interactive.perl would be rather far >> above. >> >> But my point was not to convert _only_ git-pull.sh, but to have a GSoC >> starting with this one and plan more. Then, depending on how it goes, >> you can adjust the target. >> >> This all depends on what you intend to do if the student does not finish >> the job. If you're going to do the rewrite yourself anyway, then having >> the student do even half of it is good already. If you're not going to >> finish the job by yourself, then a 95%-done-rewrite means a piece of >> code posted on the mailing list and never merged (and a lot of time >> wasted). >> >> In any case, these are just advices, certainly not objections or hard >> requests to change. >> > > > Once upon a time (Sep 2013) I rewrote builtin/repack.c which was a > shell script before. I did not have much real-coding expertise with the > git community before and by today there are 403 lines of code in > builtin/repack.c. so going for roughly 3 times (1200 lines of code) change > would make a summer, specially if you need to learn how the workflow > is in the open source world. There the lines in c doubled nearly exactly. > (before 197 shell lines, afterwards 387 c lines). > > Just last weekend I met people, who were afraid of contributing to open source > "because sometimes the internet can be very mean". Git being quite a high > profile project, as it is widely used, might not help, but rather fear > people away. I guess they've read about the lkml too much :) I consider the gitml to be a relatively civilized place for constructive criticism, without rants, flame wars and ad hominem swear word attacks. I don't know how it's perceived from the outside (but that drew me in back then). Maybe we can attach a photo of our maintainer to the GSOC page? That would prove we're nice and polite :) > That said I would not underestimate the initial time a student needs to learn > the workflow. Though most of that learning is done in the micro project phase. Yes, the technical workflow as well as the "social habits". They should follow the gitml even before, and then the micro projects are a great learning ground. Michael ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Re: [RFH] GSoC 2015 application 2015-02-24 23:56 ` Matthieu Moy 2015-02-25 0:34 ` [msysGit] " Stefan Beller @ 2015-02-25 8:44 ` Johannes Schindelin 2015-02-25 10:04 ` [msysGit] " Christian Couder 2015-02-25 10:02 ` Duy Nguyen 2 siblings, 1 reply; 74+ messages in thread From: Johannes Schindelin @ 2015-02-25 8:44 UTC (permalink / raw) To: Matthieu Moy; +Cc: Junio C Hamano, Jeff King, Git Mailing List, msysGit Hi Matthieu, On 2015-02-25 00:56, Matthieu Moy wrote: > Johannes Schindelin <johannes.schindelin@gmx.de> writes: > >> On 2015-02-24 19:25, Junio C Hamano wrote: >>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy >>> <Matthieu.Moy@grenoble-inp.fr> wrote: >>>> About the proposal: >>>> >>>> The idea of this project is to dive into the Git source code and >>>> convert, say, git-add--interactive.perl and/or git stash into proper C >>>> code, making it a so-called "built-in". >>>> >>>> My advice would be to try converting several small scripts, and avoid >>>> targetting a big one.... >>>> add--interactive and stash are relatively complex beasts, perhaps >>>> git-pull.sh would be easier to start with. >>> >>> Yeah, I think that is a very good suggestion. >> >> 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. > > To get an idea, I counted the lines of code written by the student I > mentored last year: > > $ git log --author tanayabh@gmail.com -p | diffstat -s > 43 files changed, 1225 insertions(+), 367 deletions(-) > > I would consider this GSoC as "average" (i.e. not exceptionnally good, > but certainly not a bad one either), so you may hope for more, but you > should not _expect_ much more IMHO. > > In comparison: > > $ wc -l git-add--interactive.perl > 1654 git-add--interactive.perl > $ wc -l git-stash.sh > 617 git-stash.sh > > I'd expect a rewrite in C to at least double the number of lines of > code, so rewriting git-stash would mean writting at least as many lines > of code as the GSoC above. git-add--interactive.perl would be rather far > above. Sure. You're right, I was thinking too big. > But my point was not to convert _only_ git-pull.sh, but to have a GSoC > starting with this one and plan more. Then, depending on how it goes, > you can adjust the target. That's excellent advice. > This all depends on what you intend to do if the student does not finish > the job. If you're going to do the rewrite yourself anyway, then having > the student do even half of it is good already. If you're not going to > finish the job by yourself, then a 95%-done-rewrite means a piece of > code posted on the mailing list and never merged (and a lot of time > wasted). Well, 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. 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". Ciao, Dscho -- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups "msysGit" group. To post to this group, send email to msysgit@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscribe@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "Git for Windows" group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [msysGit] Re: [RFH] GSoC 2015 application 2015-02-25 8:44 ` Johannes Schindelin @ 2015-02-25 10:04 ` Christian Couder 0 siblings, 0 replies; 74+ messages in thread From: Christian Couder @ 2015-02-25 10:04 UTC (permalink / raw) To: Johannes Schindelin Cc: Matthieu Moy, Junio C Hamano, Jeff King, Git Mailing List, msysGit On Wed, Feb 25, 2015 at 9:44 AM, Johannes Schindelin <johannes.schindelin@gmx.de> wrote: > Hi Matthieu, > > On 2015-02-25 00:56, Matthieu Moy wrote: >> Johannes Schindelin <johannes.schindelin@gmx.de> writes: >> >>> On 2015-02-24 19:25, Junio C Hamano wrote: >>>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy >>>> <Matthieu.Moy@grenoble-inp.fr> wrote: >>>>> About the proposal: >>>>> >>>>> The idea of this project is to dive into the Git source code and >>>>> convert, say, git-add--interactive.perl and/or git stash into proper C >>>>> code, making it a so-called "built-in". >>>>> >>>>> My advice would be to try converting several small scripts, and avoid >>>>> targetting a big one.... >>>>> add--interactive and stash are relatively complex beasts, perhaps >>>>> git-pull.sh would be easier to start with. >>>> >>>> Yeah, I think that is a very good suggestion. >>> >>> 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. >> >> To get an idea, I counted the lines of code written by the student I >> mentored last year: >> >> $ git log --author tanayabh@gmail.com -p | diffstat -s >> 43 files changed, 1225 insertions(+), 367 deletions(-) >> >> I would consider this GSoC as "average" (i.e. not exceptionnally good, >> but certainly not a bad one either), so you may hope for more, but you >> should not _expect_ much more IMHO. >> >> In comparison: >> >> $ wc -l git-add--interactive.perl >> 1654 git-add--interactive.perl >> $ wc -l git-stash.sh >> 617 git-stash.sh There is also: $ wc -l git-bisect.sh 528 git-bisect.sh And there is already builtin/bisect--helper.c that can be used to convert step by step shell code to C. I can mentor or co-mentor this convertion by the way, but that would conflict with the other bisect related GSoC project if a student takes it. >> I'd expect a rewrite in C to at least double the number of lines of >> code, so rewriting git-stash would mean writting at least as many lines >> of code as the GSoC above. git-add--interactive.perl would be rather far >> above. > > Sure. You're right, I was thinking too big. > >> But my point was not to convert _only_ git-pull.sh, but to have a GSoC >> starting with this one and plan more. Then, depending on how it goes, >> you can adjust the target. > > That's excellent advice. Yeah! >> This all depends on what you intend to do if the student does not finish >> the job. If you're going to do the rewrite yourself anyway, then having >> the student do even half of it is good already. If you're not going to >> finish the job by yourself, then a 95%-done-rewrite means a piece of >> code posted on the mailing list and never merged (and a lot of time >> wasted). > > Well, all of this is academic at this point. Yeah, but it's still worth keeping in many parts of our collective mind :-) > Let's see whether we get accepted, and then, if a student finds this project compelling enough. > > 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". Great! Thanks, Christian. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Re: [RFH] GSoC 2015 application 2015-02-24 23:56 ` Matthieu Moy 2015-02-25 0:34 ` [msysGit] " Stefan Beller 2015-02-25 8:44 ` Johannes Schindelin @ 2015-02-25 10:02 ` Duy Nguyen 2015-02-25 12:10 ` Johannes Schindelin 2 siblings, 1 reply; 74+ messages in thread From: Duy Nguyen @ 2015-02-25 10:02 UTC (permalink / raw) To: Matthieu Moy Cc: Johannes Schindelin, Junio C Hamano, Jeff King, Git Mailing List, msysGit On Wed, Feb 25, 2015 at 6:56 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: > To get an idea, I counted the lines of code written by the student I > mentored last year: > > $ git log --author tanayabh@gmail.com -p | diffstat -s > 43 files changed, 1225 insertions(+), 367 deletions(-) > > I would consider this GSoC as "average" (i.e. not exceptionnally good, > but certainly not a bad one either), so you may hope for more, but you > should not _expect_ much more IMHO. > > In comparison: > > $ wc -l git-add--interactive.perl > 1654 git-add--interactive.perl > $ wc -l git-stash.sh > 617 git-stash.sh > > I'd expect a rewrite in C to at least double the number of lines of > code, so rewriting git-stash would mean writting at least as many lines > of code as the GSoC above. git-add--interactive.perl would be rather far > above. > > But my point was not to convert _only_ git-pull.sh, but to have a GSoC > starting with this one and plan more. Then, depending on how it goes, > you can adjust the target. Some data point as I have a half-baked builtin/pull.c in my (forgotten) private branch for 3 years. pull.c has 389 lines (with 24 shell lines left in "#if 0"). git-pull.sh has 340 lines. Let's add 100 C lines to pull.c when it's complete, that's 50% more lines. But in the git-pull case the student could get a good head start by reusing my code, maybe. -- Duy -- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups "msysGit" group. To post to this group, send email to msysgit@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscribe@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "Git for Windows" group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Re: [RFH] GSoC 2015 application 2015-02-25 10:02 ` Duy Nguyen @ 2015-02-25 12:10 ` Johannes Schindelin 0 siblings, 0 replies; 74+ messages in thread From: Johannes Schindelin @ 2015-02-25 12:10 UTC (permalink / raw) To: Duy Nguyen Cc: Matthieu Moy, Junio C Hamano, Jeff King, Git Mailing List, msysGit Hi Duy, On 2015-02-25 11:02, Duy Nguyen wrote: > On Wed, Feb 25, 2015 at 6:56 AM, Matthieu Moy > <Matthieu.Moy@grenoble-inp.fr> wrote: >> To get an idea, I counted the lines of code written by the student I >> mentored last year: >> >> $ git log --author tanayabh@gmail.com -p | diffstat -s >> 43 files changed, 1225 insertions(+), 367 deletions(-) >> >> I would consider this GSoC as "average" (i.e. not exceptionnally good, >> but certainly not a bad one either), so you may hope for more, but you >> should not _expect_ much more IMHO. >> >> In comparison: >> >> $ wc -l git-add--interactive.perl >> 1654 git-add--interactive.perl >> $ wc -l git-stash.sh >> 617 git-stash.sh >> >> I'd expect a rewrite in C to at least double the number of lines of >> code, so rewriting git-stash would mean writting at least as many lines >> of code as the GSoC above. git-add--interactive.perl would be rather far >> above. >> >> But my point was not to convert _only_ git-pull.sh, but to have a GSoC >> starting with this one and plan more. Then, depending on how it goes, >> you can adjust the target. > > Some data point as I have a half-baked builtin/pull.c in my > (forgotten) private branch for 3 years. pull.c has 389 lines (with 24 > shell lines left in "#if 0"). git-pull.sh has 340 lines. Let's add 100 > C lines to pull.c when it's complete, that's 50% more lines. But in > the git-pull case the student could get a good head start by reusing > my code, maybe. Thanks for the pointer, I will keep that in mind! Ciao, Dscho -- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups "msysGit" group. To post to this group, send email to msysgit@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscribe@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups "Git for Windows" group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-18 19:14 [RFH] GSoC 2015 application Jeff King 2015-02-18 19:32 ` Jeff King @ 2015-02-18 21:54 ` Junio C Hamano 2015-02-19 5:49 ` Junio C Hamano 2015-02-19 10:32 ` Matthieu Moy ` (3 subsequent siblings) 5 siblings, 1 reply; 74+ messages in thread From: Junio C Hamano @ 2015-02-18 21:54 UTC (permalink / raw) To: Jeff King; +Cc: git Jeff King <peff@peff.net> writes: > and the list of microprojects: > > http://git.github.io/SoC-2015-Microprojects.html A few for micros. diff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md index b79a89f..f3b2b55 100644 --- a/SoC-2015-Microprojects.md +++ b/SoC-2015-Microprojects.md @@ -107,4 +107,25 @@ suitable. Just remember to keep the change small! It is much better for you to finish a small but complete change than to try something too ambitious and not get it done. -**TODO** add entries +### Make "git -C '' cmd" not to barf. + +Instead, make it just like "cd ''", which is a no-op that silently +succeeds. Cf. $gmane/258109 + +### Allow "-" as a short-hand for "@{-1}" in more places. + +Pick one command that operates on branch names. Teach it the "-" +shorthand that stands for "the branch we were previously on", like we +did for "git merge -" sometime after we introduced "git checkout -". +Cf. $gmane/230828 + +### Make "git diff --no-index $directory $file" DWIM better. + +"git diff --no-index $directory $directory/$file" is obviously what +the user wanted. + +### Forbid "log --graph --no-walk" + +Because --graph is about connected history while --no-walk is about +discrete points. Cf. $gmane/216083 + ^ permalink raw reply related [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-18 21:54 ` Junio C Hamano @ 2015-02-19 5:49 ` Junio C Hamano 0 siblings, 0 replies; 74+ messages in thread From: Junio C Hamano @ 2015-02-19 5:49 UTC (permalink / raw) To: Jeff King; +Cc: Git Mailing List On Wed, Feb 18, 2015 at 1:54 PM, Junio C Hamano <gitster@pobox.com> wrote: > > A few for micros. > > +### Allow "-" as a short-hand for "@{-1}" in more places. > + > +Pick one command that operates on branch names. Teach it the "-" > +shorthand that stands for "the branch we were previously on", like we In the same vein (people may have noticed that "Pick one" is meant to make this into multiple micros ;-) ### Use unsigned integral type for collection of bits. Pick one field of a structure that (1) is of signed integral type and (2) is used as a collection of multiple bits. Discuss if there is a good reason why it has to be a signed integral field and change it to an unsigned type otherwise. Cf. $gmane/263751 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-18 19:14 [RFH] GSoC 2015 application Jeff King 2015-02-18 19:32 ` Jeff King 2015-02-18 21:54 ` Junio C Hamano @ 2015-02-19 10:32 ` Matthieu Moy 2015-02-20 2:00 ` Jeff King 2015-02-20 3:26 ` [RFH] GSoC 2015 application Duy Nguyen ` (2 subsequent siblings) 5 siblings, 1 reply; 74+ messages in thread From: Matthieu Moy @ 2015-02-19 10:32 UTC (permalink / raw) To: Jeff King; +Cc: git Jeff King <peff@peff.net> writes: > I do need somebody to volunteer as backup admin. This doesn't need > to involve any specific commitment, but is mostly about what to do if I > get hit by a bus. If you promise me to try hard not to be hit by a bus and no one else steps in, I can be the backup admin. > Where I really need help now is in the "ideas" page: > > http://git.github.io/SoC-2015-Ideas.html Throwing out a few ideas for discussion, I can write something if people agree. * "git bisect fixed/unfixed", to allow bisecting a fix instead of a regression less painfully. There were already some proposed patches ( https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed ), so it shouldn't be too hard. Perhaps this item can be included in the "git bisect --first-parent" idea (turning it into "git bisect improvements"). * Be nicer to the user on tracked/untracked merge conflicts I've had it on https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#Be_nicer_to_the_user_on_tracked.2Funtracked_merge_conflicts for a while but never got someone to do it. "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: - Accept the situation without conflict when the tracked file has the exact same content as the local untracked file (which would become tracked). No data is lost, nothing can be committed accidentally. - Possibly, for fast-forward merges, if a local files belongs to the index but not to the last commit, attempt a merge between the upstream version and the local one (resulting in the same content as if the file had just been committed, but without introducing an extra commit). Recent versions SVN do something similar: on update, it considers added but not committed files like normal tracked files, and attempts a merge of the upstream version with the local one (which always succeeds when the files have identical content). Attempting a merge for non-fast forward cases would probably not make sense: it would mix changes coming from the merge with other changes that do not come from a commit." This shouldn't be technically too hard, but finding which behavior is right, where should things be customizeable and what the default value for the configuration should be will probably lead to interesting discussions. It contains two steps, which is good (all-or-nothing projects are much harder to deal with). The biggest drawback is that the first item may be simple for a GSoC while the second could be both controversial and hard to implement (depending on which solution is taken). > and the list of microprojects: > > http://git.github.io/SoC-2015-Microprojects.html Here are a few ideas, based on https://git.wiki.kernel.org/index.php/SmallProjectsIdeas -- >8 -- From 513774754872436ea8b7eea63828b804c6a107e7 Mon Sep 17 00:00:00 2001 From: Matthieu Moy <Matthieu.Moy@imag.fr> Date: Thu, 19 Feb 2015 10:48:06 +0100 Subject: [PATCH] 2015 microproject ideas --- SoC-2015-Microprojects.md | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md index 8cb6a8f..1abf595 100644 --- a/SoC-2015-Microprojects.md +++ b/SoC-2015-Microprojects.md @@ -128,3 +128,45 @@ the user wanted. Because --graph is about connected history while --no-walk is about discrete points. Cf. $gmane/216083 + +### Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git + +Most of git dotfiles can be located, at the user's option, in +~/.<file> or in ~/.config/git/<file>, following the [XDG +standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). +~/.git-credentials and ~/.git-credential-cache are still hardcoded as +~/.<file>, and should allow using the XDG directory layout too +(~/.git-credentials could be allowed as ~/.config/git/credential and +~/.git-credential-cache could be allowed as ~/.cache/git/credential, +possibly modified by $XDG_CONFIG_HOME and $XDG_CACHE_HOME). + +Each of these files can be a microproject of its own. The suggested +approach is: + +* See how XDG was implemented for other files (run "git log --grep + XDG" in Git's source code) and read the XDG specification. + +* Implement and test the new behavior, without breaking compatibility + with the old behavior. + +* Update the documentation + +### Add configuration options for some commonly used command-line options + +This includes: + +* git am -3 + +* git am -c + +Some people always run the command with these options, and would +prefer to be able to activate them by default in ~/.gitconfig. + +### Add more builtin patterns for userdiff + +"git diff" shows the function name corresponding to each hunk after +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...), +the way to find the function name is built-in Git's source code as +regular expressions (see userdiff.c). A few languages are common +enough to deserve a built-in driver, but are not yet recognized. For +example, CSS, shell. -- 2.0.2.737.gfb43bde -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply related [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-19 10:32 ` Matthieu Moy @ 2015-02-20 2:00 ` Jeff King 2015-02-20 10:06 ` Matthieu Moy 2015-02-20 10:31 ` [PATCH 1/3] microprojects: tweaks after discussion with Peff Matthieu Moy 0 siblings, 2 replies; 74+ messages in thread From: Jeff King @ 2015-02-20 2:00 UTC (permalink / raw) To: Matthieu Moy; +Cc: git On Thu, Feb 19, 2015 at 11:32:46AM +0100, Matthieu Moy wrote: > > I do need somebody to volunteer as backup admin. This doesn't need > > to involve any specific commitment, but is mostly about what to do if I > > get hit by a bus. > > If you promise me to try hard not to be hit by a bus and no one else > steps in, I can be the backup admin. Thanks. I need you to register and create a profile at: https://www.google-melange.com/gsoc/homepage/google/gsoc2015 and tell me your username (the information from last year does not carry forward automatically). Then I mark you as backup admin and (I think) you have to then accept. > Throwing out a few ideas for discussion, I can write something if people > agree. > > * "git bisect fixed/unfixed", to allow bisecting a fix instead of a > regression less painfully. There were already some proposed patches > ( https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed ), > so it shouldn't be too hard. Perhaps this item can be included in the > "git bisect --first-parent" idea (turning it into "git bisect > improvements"). That seems like a reasonable topic. I was about to say "but it's much more complicated than fix/unfixed..." but it looks like that wiki entry covers the past discussion (and reading and understanding that would be a first step for the student). I agree it's probably smaller than a full-summer project and can get lumped into the other bisect idea. > * Be nicer to the user on tracked/untracked merge conflicts > [...] Sounds OK to me, though I agree the merging of untracked files is a little controversial. There are also a lot of corner cases in merge-recursive, and I think still some documented cases where we can overwrite untracked files. Maybe a more encompassing project would be to organize and dig into some of those corner cases. > SoC-2015-Microprojects.md | 42 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 42 insertions(+) Thanks, applied, although... > +### Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git > + > +Most of git dotfiles can be located, at the user's option, in > +~/.<file> or in ~/.config/git/<file>, following the [XDG > +standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). > +~/.git-credentials and ~/.git-credential-cache are still hardcoded as > +~/.<file>, and should allow using the XDG directory layout too > +(~/.git-credentials could be allowed as ~/.config/git/credential and > +~/.git-credential-cache could be allowed as ~/.cache/git/credential, > +possibly modified by $XDG_CONFIG_HOME and $XDG_CACHE_HOME). > + > +Each of these files can be a microproject of its own. The suggested > +approach is: > + > +* See how XDG was implemented for other files (run "git log --grep > + XDG" in Git's source code) and read the XDG specification. > + > +* Implement and test the new behavior, without breaking compatibility > + with the old behavior. > + > +* Update the documentation I think these might be getting a little larger than "micro". That's OK if the student can handle it, but we may want to mark them as such. I'll leave it for now, though, as we have a bit more breathing room on the microprojects. > +### Add configuration options for some commonly used command-line options > + > +This includes: > + > +* git am -3 > + > +* git am -c > + > +Some people always run the command with these options, and would > +prefer to be able to activate them by default in ~/.gitconfig. The direction here seems reasonable, though I think we have mailinfo.scissors already, so "-c" may not be a good example. > +### Add more builtin patterns for userdiff > + > +"git diff" shows the function name corresponding to each hunk after > +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...), > +the way to find the function name is built-in Git's source code as > +regular expressions (see userdiff.c). A few languages are common > +enough to deserve a built-in driver, but are not yet recognized. For > +example, CSS, shell. I am not sure that understanding the horrible regexes involved in some userdiff counts as "micro", but OK. :) -Peff ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-20 2:00 ` Jeff King @ 2015-02-20 10:06 ` Matthieu Moy 2015-02-20 10:22 ` Dennis Kaarsemaker 2015-02-20 23:06 ` Eric Sunshine 2015-02-20 10:31 ` [PATCH 1/3] microprojects: tweaks after discussion with Peff Matthieu Moy 1 sibling, 2 replies; 74+ messages in thread From: Matthieu Moy @ 2015-02-20 10:06 UTC (permalink / raw) To: Jeff King; +Cc: git Jeff King <peff@peff.net> writes: >> * Be nicer to the user on tracked/untracked merge conflicts >> [...] > > Sounds OK to me, though I agree the merging of untracked files is a > little controversial. Yes. To me, part of the project is to identify cases where this is actually not controversial (OTOH, it's a bit frustrating when I do a trivial pull and Git complains because I already have the file). >> +### Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git >> + >> +Most of git dotfiles can be located, at the user's option, in >> +~/.<file> or in ~/.config/git/<file>, following the [XDG >> +standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). >> +~/.git-credentials and ~/.git-credential-cache are still hardcoded as >> +~/.<file>, and should allow using the XDG directory layout too >> +(~/.git-credentials could be allowed as ~/.config/git/credential and >> +~/.git-credential-cache could be allowed as ~/.cache/git/credential, >> +possibly modified by $XDG_CONFIG_HOME and $XDG_CACHE_HOME). >> + >> +Each of these files can be a microproject of its own. The suggested >> +approach is: >> + >> +* See how XDG was implemented for other files (run "git log --grep >> + XDG" in Git's source code) and read the XDG specification. >> + >> +* Implement and test the new behavior, without breaking compatibility >> + with the old behavior. >> + >> +* Update the documentation > > I think these might be getting a little larger than "micro". The ~/.git-credential-cache may be a bit harder, but the case of ~/.git-credentials should follow the same pattern as files for which this is already done. So, doing it by mimicking existing code shouldn't be too hard. But maybe that's me being optimistic ;-). >> +### Add configuration options for some commonly used command-line options >> + >> +This includes: >> + >> +* git am -3 >> + >> +* git am -c >> + >> +Some people always run the command with these options, and would >> +prefer to be able to activate them by default in ~/.gitconfig. > > The direction here seems reasonable, though I think we have > mailinfo.scissors already, so "-c" may not be a good example. Ah, indeed. The documentation makes it a bit hard to find, but I'll send a patch. >> +### Add more builtin patterns for userdiff >> + >> +"git diff" shows the function name corresponding to each hunk after >> +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...), >> +the way to find the function name is built-in Git's source code as >> +regular expressions (see userdiff.c). A few languages are common >> +enough to deserve a built-in driver, but are not yet recognized. For >> +example, CSS, shell. > > I am not sure that understanding the horrible regexes involved in some > userdiff counts as "micro", but OK. :) I agree the regexes are horrible, but here also the project is not about doing something really new, but reproducing what has already been done for others. At least, students not fluent with regular expressions have a pointer to userdiff.c and can quickly see that the microproject is not meant for them ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-20 10:06 ` Matthieu Moy @ 2015-02-20 10:22 ` Dennis Kaarsemaker 2015-02-20 10:34 ` Matthieu Moy 2015-02-20 23:06 ` Eric Sunshine 1 sibling, 1 reply; 74+ messages in thread From: Dennis Kaarsemaker @ 2015-02-20 10:22 UTC (permalink / raw) To: Matthieu Moy; +Cc: Jeff King, git On vr, 2015-02-20 at 11:06 +0100, Matthieu Moy wrote: > The ~/.git-credential-cache may be a bit harder, but the case of > ~/.git-credentials should follow the same pattern as files for which > this is already done. So, doing it by mimicking existing code > shouldn't > be too hard. > > But maybe that's me being optimistic ;-) Having just copied that logic to one of my tools, I reaclly would have fount if useful to have something that, given a config file name tells you where it should be, maybe in the resident kitchen-sink that is rev-parse: $ git rev-parse --config git /home/dennis/.gitconfig $ git rev-parse --config gitk /home/dennis/.gitk $ git rev-parse --config foobar /home/dennis/.foobar Or, when XDG config files are used: $ git rev-parse --config gitk /home/dennis/.config/git/gitk $ git rev-parse --config git /home/dennis/.config/git/config $ git rev-parse --config foobar /home/dennis/.config/git/foobar So, ~/.$filename or $XDG_CONFIG_HOME/git/filename, with a special case only for git itself, with consistent selection of which to use (currently gitk and git are inconsistent). -- Dennis Kaarsemaker http://www.kaarsemaker.net ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-20 10:22 ` Dennis Kaarsemaker @ 2015-02-20 10:34 ` Matthieu Moy 0 siblings, 0 replies; 74+ messages in thread From: Matthieu Moy @ 2015-02-20 10:34 UTC (permalink / raw) To: Dennis Kaarsemaker; +Cc: Jeff King, git Dennis Kaarsemaker <dennis@kaarsemaker.net> writes: > given a config file name tells > you where it should be, maybe in the resident kitchen-sink that is > rev-parse: It's actually a bit harder than this, since when both XDG and ~/.<file> exist, we read from both but write to one only. So there's not just one answer to the question. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-20 10:06 ` Matthieu Moy 2015-02-20 10:22 ` Dennis Kaarsemaker @ 2015-02-20 23:06 ` Eric Sunshine 1 sibling, 0 replies; 74+ messages in thread From: Eric Sunshine @ 2015-02-20 23:06 UTC (permalink / raw) To: Matthieu Moy; +Cc: Jeff King, Git List, Michael Haggerty On Fri, Feb 20, 2015 at 5:06 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote: > Jeff King <peff@peff.net> writes: >> I think these might be getting a little larger than "micro". > > The ~/.git-credential-cache may be a bit harder, but the case of > ~/.git-credentials should follow the same pattern as files for which > this is already done. So, doing it by mimicking existing code shouldn't > be too hard. > > But maybe that's me being optimistic ;-). As a person who did a significant number of GSoC 2014 micro-project reviews (as well as many actual GSoC reviews), I probably ought to weigh in and say that this may be too optimistic. In fact, most of the GSoC 2015 micro-project suggestions[1] seem far too large and involved. For 2014, most of the GSoC micro-projects were extremely simple, of the form "replace starts_with() with skip_prefix()", yet most applicants still required three or four (or more) attempts to get it right (and some never did), even with extremely detailed hand-holding reviews at each step. (And, such reviews are quite time-consuming. I was allocating six to eight hours each day to those reviews, yet I couldn't keep up with all the submissions.) Although quite simple, many of the 2014 micro-projects[2] (particularly from Michael Haggerty) had a bit of a twist (or trick question) thrown in, requiring a tad more thought and effort than mere mechanical search-and-replace. That was useful because it helped identify potentially acceptable candidates more easily, however, that added twist was probably a good upper limit on difficulty for micro-projects. Another important aspect of 2014's micro-projects was that they could be accomplished with only very localized knowledge: that is, a student could read the logic of the one function being touched and learn enough to be successful. The micro-projects did not require global knowledge of Git internals or hours of research. The attitude in 2014 was that it was important for students to get a taste of what it is like working on the Git project and what would be expected of them as submitters, and for GSoC administrators and mentors to get a feel for the applicants by how they interacted with reviewers. By going through the review process on a project with high engineering standards, it also was hope that students would learn and benefit from the experience even if not selected. Extremely simple micro-projects (possibly with a twist) in the style of 2014's were more than sufficient to satisfy these goals, and were more than enough to consume significant reviewer time. The suggested 2015's micro-projects seem far in excess. [1]: http://git.github.io/SoC-2015-Microprojects.html [2]: http://git.github.io/SoC-2014-Microprojects.html ^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH 1/3] microprojects: tweaks after discussion with Peff 2015-02-20 2:00 ` Jeff King 2015-02-20 10:06 ` Matthieu Moy @ 2015-02-20 10:31 ` Matthieu Moy 2015-02-20 10:31 ` [PATCH 2/3] GSoC ideas: git bisect fixed/unfixed Matthieu Moy 2015-02-20 10:31 ` [PATCH 3/3] idea: Be nicer to the user on tracked/untracked merge conflicts Matthieu Moy 1 sibling, 2 replies; 74+ messages in thread From: Matthieu Moy @ 2015-02-20 10:31 UTC (permalink / raw) To: gitster; +Cc: git, Jeff King, Matthieu Moy Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> --- SoC-2015-Microprojects.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md index e49cb07..c6123bb 100644 --- a/SoC-2015-Microprojects.md +++ b/SoC-2015-Microprojects.md @@ -158,14 +158,16 @@ approach is: * Update the documentation +Even though the amount of code to write is small, these projects +involve a lot of prior work to understand the specification and deal +with all potential corner-cases. + ### Add configuration options for some commonly used command-line options This includes: * git am -3 -* git am -c - Some people always run the command with these options, and would prefer to be able to activate them by default in ~/.gitconfig. @@ -177,3 +179,5 @@ the way to find the function name is built-in Git's source code as regular expressions (see userdiff.c). A few languages are common enough to deserve a built-in driver, but are not yet recognized. For example, CSS, shell. + +This project requires a very good knowledge of regular expressions. -- 2.3.0.157.g79e124b ^ permalink raw reply related [flat|nested] 74+ messages in thread
* [PATCH 2/3] GSoC ideas: git bisect fixed/unfixed 2015-02-20 10:31 ` [PATCH 1/3] microprojects: tweaks after discussion with Peff Matthieu Moy @ 2015-02-20 10:31 ` Matthieu Moy 2015-02-20 10:31 ` [PATCH 3/3] idea: Be nicer to the user on tracked/untracked merge conflicts Matthieu Moy 1 sibling, 0 replies; 74+ messages in thread From: Matthieu Moy @ 2015-02-20 10:31 UTC (permalink / raw) To: gitster; +Cc: git, Jeff King, Matthieu Moy Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> --- SoC-2015-Ideas.md | 45 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 44 insertions(+), 1 deletion(-) diff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md index a3e988e..4641800 100644 --- a/SoC-2015-Ideas.md +++ b/SoC-2015-Ideas.md @@ -34,7 +34,9 @@ should be honored without checking the ownership. Cf. $gmane/243628 Takes eol attributes into account to correct lossage/addition of CR at the end of line, with updates to "am". Cf. $gmane/257445 -### "git bisect --first-parent". +### git bisect improvements + +#### "git bisect --first-parent". When your project is strictly "new features are merged into trunk, never the other way around", it is handy to be able to first find @@ -42,6 +44,47 @@ a merge on the trunk that merged a topic to point fingers at when a bug appears, instead of having to drill down to the individual commit on the faulty side branch. +#### "git bisect fixed/unfixed" + +"git bisect" is initially meant to find regressions (i.e. the new code +is bad, and the old one used to work). The opposite may happen too: +look for the commit which fixed a bug. It is already possible using +"git bisect", but the user has to type "good" to mean "the bug is +there" and "bad" to mean "the bug is fixed", which isn't convenient. + +It would be nice to allow the user to explicitely say "git bisect +fixed" and "git bisect unfixed" instead. It is actually much harder +than defining "fixed"/"unfixed" as aliases for "bad"/"good". + +A patch for this feature was sent to the mailing list in this thread a +few years ago by Dscho: +http://thread.gmane.org/gmane.comp.version-control.git/86063 + +Unfortunately there were some problems with the patch and no one tried +to fix them. So the same problem/suggestion is often reported on the +mailing list, for example: + + http://thread.gmane.org/gmane.comp.version-control.git/165141 + http://thread.gmane.org/gmane.comp.version-control.git/170113 + http://thread.gmane.org/gmane.comp.version-control.git/182398 + +A patch series to let "old/new" be used instead of "good/bad" was +started here: + +http://thread.gmane.org/gmane.comp.version-control.git/199758/focus=199869 + +There is still work to be done to complete it. + +Note than another feature with the name "git bisect fix" was suggested +to do something else: + +http://thread.gmane.org/gmane.comp.version-control.git/169026 + +Since there have already been discussions and patches, the remaining +work is probably less than a GSoC, so this project should be grouped +with another one (like git bisect --first-parent) to make a full GSoC +proposal. + ### Unifying `git branch -l`, `git tag -l`, and `git for-each-ref` These three commands are all about selecting a subset of a repository's -- 2.3.0.157.g79e124b ^ permalink raw reply related [flat|nested] 74+ messages in thread
* [PATCH 3/3] idea: Be nicer to the user on tracked/untracked merge conflicts 2015-02-20 10:31 ` [PATCH 1/3] microprojects: tweaks after discussion with Peff Matthieu Moy 2015-02-20 10:31 ` [PATCH 2/3] GSoC ideas: git bisect fixed/unfixed Matthieu Moy @ 2015-02-20 10:31 ` Matthieu Moy 1 sibling, 0 replies; 74+ messages in thread From: Matthieu Moy @ 2015-02-20 10:31 UTC (permalink / raw) To: gitster; +Cc: git, Jeff King, Matthieu Moy Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> --- SoC-2015-Ideas.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md index 4641800..86de476 100644 --- a/SoC-2015-Ideas.md +++ b/SoC-2015-Ideas.md @@ -117,3 +117,30 @@ Cf. $gmane/213180 $gmane/212950 ### Introduce threading to checkout codepath, possibly helping Windows folks. Cf. $gmane/235874 + +### Be nicer to the user on tracked/untracked merge conflicts + +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: + + - Accept the situation without conflict when the tracked file has the + exact same content as the local untracked file (which would become + tracked). No data is lost, nothing can be committed accidentally. + + - Possibly, for fast-forward merges, if a local files belongs to the + index but not to the last commit, attempt a merge between the + upstream version and the local one (resulting in the same content + as if the file had just been committed, but without introducing an + extra commit). + +Recent versions SVN do something similar: on update, it considers +added but not committed files like normal tracked files, and attempts +a merge of the upstream version with the local one (which always +succeeds when the files have identical content). Attempting a merge +for non-fast forward cases would probably not make sense: it would mix +changes coming from the merge with other changes that do not come from +a commit. + +One difficulty with this project is to identify uncontroversial cases +(where Git should merge without complaining) and all the possible +corner-cases. -- 2.3.0.157.g79e124b ^ permalink raw reply related [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-18 19:14 [RFH] GSoC 2015 application Jeff King ` (2 preceding siblings ...) 2015-02-19 10:32 ` Matthieu Moy @ 2015-02-20 3:26 ` Duy Nguyen 2015-02-20 7:13 ` Jeff King 2015-02-20 5:35 ` [RFH] GSoC 2015 application Michael Haggerty 2015-02-26 13:10 ` [RFH] GSoC 2015 application Duy Nguyen 5 siblings, 1 reply; 74+ messages in thread From: Duy Nguyen @ 2015-02-20 3:26 UTC (permalink / raw) To: Jeff King; +Cc: Git Mailing List On Thu, Feb 19, 2015 at 2:14 AM, Jeff King <peff@peff.net> wrote: > and the list of microprojects: > > http://git.github.io/SoC-2015-Microprojects.html > There is debian bug 777690 [1] that's basically about making tag's version sort aware about -rc, -pre suffixes. I imagine it would touch versioncmp.c and builtin/tag.c (to retrieve the suffixes from config file). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690 -- Duy ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-20 3:26 ` [RFH] GSoC 2015 application Duy Nguyen @ 2015-02-20 7:13 ` Jeff King 2015-02-20 8:26 ` Junio C Hamano 0 siblings, 1 reply; 74+ messages in thread From: Jeff King @ 2015-02-20 7:13 UTC (permalink / raw) To: Duy Nguyen; +Cc: Git Mailing List On Fri, Feb 20, 2015 at 10:26:15AM +0700, Duy Nguyen wrote: > On Thu, Feb 19, 2015 at 2:14 AM, Jeff King <peff@peff.net> wrote: > > and the list of microprojects: > > > > http://git.github.io/SoC-2015-Microprojects.html > > > > There is debian bug 777690 [1] that's basically about making tag's > version sort aware about -rc, -pre suffixes. I imagine it would touch > versioncmp.c and builtin/tag.c (to retrieve the suffixes from config > file). > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690 I think that's a reasonable thing to work on, but it's too big for a microproject and too small for a GSoC. I think this could be an "extra credit" for the project to unify for-each-ref, "tag -l", and "branch -l", though. That will vastly enhance the supporting abilities the latter two (e.g., you could sort by taggerdate). -Peff ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-20 7:13 ` Jeff King @ 2015-02-20 8:26 ` Junio C Hamano 2015-02-21 3:02 ` Support customized reordering in version sort Duy Nguyen 0 siblings, 1 reply; 74+ messages in thread From: Junio C Hamano @ 2015-02-20 8:26 UTC (permalink / raw) To: Jeff King; +Cc: Duy Nguyen, Git Mailing List On Thu, Feb 19, 2015 at 11:13 PM, Jeff King <peff@peff.net> wrote: >> There is debian bug 777690 [1] that's basically about making tag's >> version sort aware about -rc, -pre suffixes. I imagine it would touch >> versioncmp.c and builtin/tag.c (to retrieve the suffixes from config >> file). >> >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690 > > I think that's a reasonable thing to work on, but it's too big for a > microproject and too small for a GSoC. That is certainly too big as a Micro, but I do not think it is too small for GSoC, if it is to be done right (meaning, not just implementing an arbitrary version comparison hardwired, but design how to make it extensible). I have a feeling that I am complaining that student projects are designed to be too grand and getting told that I am overly pessimistic by everybody else every year. Perhaps this year others may prove me wrong, if we can find mentors, that is ;-) ^ permalink raw reply [flat|nested] 74+ messages in thread
* Support customized reordering in version sort 2015-02-20 8:26 ` Junio C Hamano @ 2015-02-21 3:02 ` Duy Nguyen 2015-02-21 3:25 ` Junio C Hamano 0 siblings, 1 reply; 74+ messages in thread From: Duy Nguyen @ 2015-02-21 3:02 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jeff King, Git Mailing List On Fri, Feb 20, 2015 at 12:26:29AM -0800, Junio C Hamano wrote: > On Thu, Feb 19, 2015 at 11:13 PM, Jeff King <peff@peff.net> wrote: > > >> There is debian bug 777690 [1] that's basically about making tag's > >> version sort aware about -rc, -pre suffixes. I imagine it would touch > >> versioncmp.c and builtin/tag.c (to retrieve the suffixes from config > >> file). > >> > >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690 > > > > I think that's a reasonable thing to work on, but it's too big for a > > microproject and too small for a GSoC. > > That is certainly too big as a Micro, but I do not think it is too small > for GSoC, if it is to be done right (meaning, not just implementing an > arbitrary version comparison hardwired, but design how to make it > extensible). I did write "maybe more of mini-size than micro" then looked at the micro list again and somehow decided to delete that. Anyway while I still have my attention on it, might as well do it. My idea is to make it easy for the user to change the sort algorithm. And it's probably intuitive to just substitute a string with something. So if "1-rc1" is put incorrectly before "1.1" and you realize that "1.999" ought to be the last one before "2". You could tell git to internally replace "1-rc1" with "1.999". This patch does that. The user feeds substitution rules via versionsort.substitute config keys, e.g. git config versionsort.substitute "-rc .999" Performance is not a concern because I don't think people would throw 100k tags to it. There are two issues I'm aware of but not addressed: - the order of substitution matters, but right now it's up in the air - case-sensitiveness may surprise users -- 8< -- diff --git a/versioncmp.c b/versioncmp.c index 7511e08..2419e38 100644 --- a/versioncmp.c +++ b/versioncmp.c @@ -1,4 +1,5 @@ #include "cache.h" +#include "strbuf.h" /* * versioncmp(): copied from string/strverscmp.c in glibc commit @@ -20,6 +21,57 @@ #define CMP 2 #define LEN 3 +struct subst_rule +{ + const char *before; + const char *after; +}; +static struct subst_rule *rules; +static int rule_nr, rule_alloc; + +static int versioncmp_config(const char *k, const char *v, void *cb) +{ + char *p, *s; + if (strcmp(k, "versionsort.substitute")) + return 0; + ALLOC_GROW(rules, rule_nr + 1, rule_alloc); + s = xstrdup(v); + p = strchr(s, ' '); + if (!p) + return error("missing space in %s", v); + *p = '\0'; + rules[rule_nr].before = s; + rules[rule_nr].after = p + 1; + rule_nr++; + return 0; +} + +static char *substitute(const unsigned char **strp) +{ + struct strbuf sb = STRBUF_INIT; + const char *str = (const char *)*strp; + int i; + if (!rules) { + rules = xmalloc(sizeof(*rules)); + rule_alloc = 1; + git_config(versioncmp_config, NULL); + } + for (i = 0; i < rule_nr; i++) { + const struct subst_rule *r = rules + i; + const char *p = strstr(str, r->before); + if (!p) + continue; + if (!sb.len) + strbuf_addstr(&sb, str); + strbuf_splice(&sb, p - str, strlen(r->before), + r->after, strlen(r->after)); + str = sb.buf; + } + if ((const unsigned char *)str == *strp) + return NULL; + *strp = (const unsigned char *)sb.buf; + return sb.buf; +} /* * Compare S1 and S2 as strings holding indices/version numbers, @@ -32,6 +84,7 @@ int versioncmp(const char *s1, const char *s2) { const unsigned char *p1 = (const unsigned char *) s1; const unsigned char *p2 = (const unsigned char *) s2; + char *free1, *free2; unsigned char c1, c2; int state, diff; @@ -58,6 +111,8 @@ int versioncmp(const char *s1, const char *s2) if (p1 == p2) return 0; + free1 = substitute(&p1); + free2 = substitute(&p2); c1 = *p1++; c2 = *p2++; @@ -75,6 +130,10 @@ int versioncmp(const char *s1, const char *s2) } state = result_type[state * 3 + (((c2 == '0') + (isdigit (c2) != 0)))]; + if (state != LEN) { + free(free1); + free(free2); + } switch (state) { case CMP: @@ -82,10 +141,16 @@ int versioncmp(const char *s1, const char *s2) case LEN: while (isdigit (*p1++)) - if (!isdigit (*p2++)) + if (!isdigit (*p2++)) { + free(free1); + free(free2); return 1; + } - return isdigit (*p2) ? -1 : diff; + c2 = *p2; + free(free1); + free(free2); + return isdigit (c2) ? -1 : diff; default: return state; -- 8< -- ^ permalink raw reply related [flat|nested] 74+ messages in thread
* Re: Support customized reordering in version sort 2015-02-21 3:02 ` Support customized reordering in version sort Duy Nguyen @ 2015-02-21 3:25 ` Junio C Hamano 2015-02-21 3:33 ` Duy Nguyen 0 siblings, 1 reply; 74+ messages in thread From: Junio C Hamano @ 2015-02-21 3:25 UTC (permalink / raw) To: Duy Nguyen; +Cc: Jeff King, Git Mailing List On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen <pclouds@gmail.com> wrote: > > My idea is to make it easy for the user to change the sort algorithm. > And it's probably intuitive to just substitute a string with > something. So if "1-rc1" is put incorrectly before "1.1" and you > realize that "1.999" ought to be the last one before "2". You could > tell git to internally replace "1-rc1" with "1.999". > > This patch does that. The user feeds substitution rules via > versionsort.substitute config keys, e.g. > > git config versionsort.substitute "-rc .999" I would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then 1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, ... and then 1.1 (aka 1.1-final). If 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does it make 1 come after 1.99911, and 1.1.9992 come before 1.1? I didn't read the patch text and perhaps the explanation above is the only thing faulty about your message, or perhaps my reading is faulty and the above describes a sound idea, but I do not see how the above makes sense. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Support customized reordering in version sort 2015-02-21 3:25 ` Junio C Hamano @ 2015-02-21 3:33 ` Duy Nguyen 2015-02-21 5:12 ` Junio C Hamano 0 siblings, 1 reply; 74+ messages in thread From: Duy Nguyen @ 2015-02-21 3:33 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jeff King, Git Mailing List On Sat, Feb 21, 2015 at 10:25 AM, Junio C Hamano <gitster@pobox.com> wrote: > On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen <pclouds@gmail.com> wrote: >> >> My idea is to make it easy for the user to change the sort algorithm. >> And it's probably intuitive to just substitute a string with >> something. So if "1-rc1" is put incorrectly before "1.1" and you >> realize that "1.999" ought to be the last one before "2". You could >> tell git to internally replace "1-rc1" with "1.999". >> >> This patch does that. The user feeds substitution rules via >> versionsort.substitute config keys, e.g. >> >> git config versionsort.substitute "-rc .999" > > I would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then > 1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, ... > and then 1.1 (aka 1.1-final). > > If 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does > it make 1 come after 1.99911, and 1.1.9992 come before 1.1? > > I didn't read the patch text and perhaps the explanation above is the only > thing faulty about your message, or perhaps my reading is faulty and the > above describes a sound idea, but I do not see how the above makes sense. No, faulty thinking. Back to the whiteboard.. -- Duy ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Support customized reordering in version sort 2015-02-21 3:33 ` Duy Nguyen @ 2015-02-21 5:12 ` Junio C Hamano 2015-02-21 5:37 ` Junio C Hamano 2015-02-26 10:44 ` [PATCH] versionsort: support reorder prerelease suffixes Nguyễn Thái Ngọc Duy 0 siblings, 2 replies; 74+ messages in thread From: Junio C Hamano @ 2015-02-21 5:12 UTC (permalink / raw) To: Duy Nguyen; +Cc: Jeff King, Git Mailing List On Fri, Feb 20, 2015 at 7:33 PM, Duy Nguyen <pclouds@gmail.com> wrote: > On Sat, Feb 21, 2015 at 10:25 AM, Junio C Hamano <gitster@pobox.com> wrote: >> On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen <pclouds@gmail.com> wrote: >>> >>> My idea is to make it easy for the user to change the sort algorithm. >>> And it's probably intuitive to just substitute a string with >>> something. So if "1-rc1" is put incorrectly before "1.1" and you >>> realize that "1.999" ought to be the last one before "2". You could >>> tell git to internally replace "1-rc1" with "1.999". >>> >>> This patch does that. The user feeds substitution rules via >>> versionsort.substitute config keys, e.g. >>> >>> git config versionsort.substitute "-rc .999" >> >> I would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then >> 1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, ... >> and then 1.1 (aka 1.1-final). >> >> If 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does >> it make 1 come after 1.99911, and 1.1.9992 come before 1.1? >> >> I didn't read the patch text and perhaps the explanation above is the only >> thing faulty about your message, or perhaps my reading is faulty and the >> above describes a sound idea, but I do not see how the above makes sense. > > No, faulty thinking. Back to the whiteboard.. One version of vercmp() I read went like this: (1) Chomp the version strings into an alternate runs of digits and non-digits. e.g. 1.2.13 becomes "1", ".", "2", "." and "13" while 1.2.9 becomes "1", ".", "2", "." and "9". (2) Compare corresponding elements with strcmp() for runs of non-digits, and numerically for runs of digits. In the above example, up to the shared "1.2." would compare equal, and the final run of digits, "13" and "9" are compared numerically and we declare that 1.2.13 comes later. I think you can add a twist by introducing "optionally this can appear" substring. When there is such an optional substring defined, you also define if the side that lack the optional substring comes before or after the side that has one. For example, you declare "[-]rc" as "optional substring that makes the owner of such a substring sort before others" (call it "optional negative substring") and comparing 2.0-rc12, 2.0-rc2 and 2.0: - "2.0" becomes "2", ".", "0" and "2.0-rc2" becomes "2", ".", "0", "-rc", "2". Comparing them from left to right, the first difference is "lack of anything (2.0 side runs out tokens)" and "-rc", which is marked as optional negative. Hence 2.0-rc2 sorts before 2.0 - "2.0-rc12" and "2.0-rc2" splits into tokens similarly. The first difference you see will be after you match "-rc" and "-rc", which is "12" vs "2". Comparing them numerically, you know "2.0-rc12" comes later. You can define values to optional negatives and optional positives to express a more elaborate sort order e.g. 1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1 even though "-post" does not have to be declared as optional positive. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Support customized reordering in version sort 2015-02-21 5:12 ` Junio C Hamano @ 2015-02-21 5:37 ` Junio C Hamano 2015-02-26 10:44 ` [PATCH] versionsort: support reorder prerelease suffixes Nguyễn Thái Ngọc Duy 1 sibling, 0 replies; 74+ messages in thread From: Junio C Hamano @ 2015-02-21 5:37 UTC (permalink / raw) To: Duy Nguyen; +Cc: Jeff King, Git Mailing List Junio C Hamano <gitster@pobox.com> writes: > You can define values to optional negatives and optional positives to > express a more > elaborate sort order e.g. > > 1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1 > > even though "-post" does not have to be declared as optional positive. ... that is, you say "-pre" is a more negative optional than "-rc" that is also a negative optional. ^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH] versionsort: support reorder prerelease suffixes 2015-02-21 5:12 ` Junio C Hamano 2015-02-21 5:37 ` Junio C Hamano @ 2015-02-26 10:44 ` Nguyễn Thái Ngọc Duy 2015-02-27 21:37 ` Junio C Hamano 1 sibling, 1 reply; 74+ messages in thread From: Nguyễn Thái Ngọc Duy @ 2015-02-26 10:44 UTC (permalink / raw) To: git; +Cc: Junio C Hamano, Jeff King, Nguyễn Thái Ngọc Duy Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> --- Second round. Looking better. We can do "1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1" too but it relies on config key's loading order, a bit iffy. Documentation/config.txt | 7 +++++++ t/t7004-tag.sh | 28 +++++++++++++++++++++++++++ versioncmp.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 85 insertions(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index 04e2a71..8e078df 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2539,6 +2539,13 @@ user.signingkey:: This option is passed unchanged to gpg's --local-user parameter, so you may specify a key using any method that gpg supports. +versionsort.prereleaseSuffix:: + When version sort is used in linkgit:git-tag[1], prerelease + tags (e.g. "1.0-rc1") may appear after the main release + "1.0". By specifying the suffix "-rc" in this variable, + "1.0-rc1" will appear before "1.0". One variable assignment + per suffix. + web.browser:: Specify a web browser that may be used by some commands. Currently only linkgit:git-instaweb[1] and linkgit:git-help[1] diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh index 35c805a..8bfeef9 100755 --- a/t/t7004-tag.sh +++ b/t/t7004-tag.sh @@ -1459,6 +1459,34 @@ test_expect_success 'invalid sort parameter in configuratoin' ' test_cmp expect actual ' +test_expect_success 'version sort with prerelease reordering' ' + git config --unset tag.sort && + git config versionsort.prereleaseSuffix -rc && + git tag foo1.6-rc1 && + git tag foo1.6-rc2 && + git tag -l --sort=version:refname "foo*" >actual && + cat >expect <<-\EOF && + foo1.3 + foo1.6-rc1 + foo1.6-rc2 + foo1.6 + foo1.10 + EOF + test_cmp expect actual +' + +test_expect_success 'reverse version sort with prerelease reordering' ' + git tag -l --sort=-version:refname "foo*" >actual && + cat >expect <<-\EOF && + foo1.10 + foo1.6 + foo1.6-rc2 + foo1.6-rc1 + foo1.3 + EOF + test_cmp expect actual +' + run_with_limited_stack () { (ulimit -s 128 && "$@") } diff --git a/versioncmp.c b/versioncmp.c index 7511e08..80bfd10 100644 --- a/versioncmp.c +++ b/versioncmp.c @@ -1,4 +1,5 @@ #include "cache.h" +#include "string-list.h" /* * versioncmp(): copied from string/strverscmp.c in glibc commit @@ -20,6 +21,48 @@ #define CMP 2 #define LEN 3 +static const struct string_list *prereleases; +static int initialized; + +/* + * p1 and p2 point to the first different character in two strings. If + * either p1 or p2 starts with a prerelease suffix, it will be forced + * to be on top. + * + * If both p1 and p2 start with (different) suffix, the order is + * determined by config file. + * + * Note that we don't have to deal with the situation when both p1 and + * p2 start with the same suffix because the common part is already + * consumed by the caller. + * + * Return non-zero if *diff contains the return value for versioncmp() + */ +static int swap_prereleases(const void *p1_, + const void *p2_, + int *diff) +{ + const char *p1 = p1_; + const char *p2 = p2_; + int i, i1 = -1, i2 = -1; + + for (i = 0; i < prereleases->nr; i++) { + const char *suffix = prereleases->items[i].string; + if (i1 == -1 && starts_with(p1, suffix)) + i1 = i; + if (i2 == -1 && starts_with(p2, suffix)) + i2 = i; + } + if (i1 == -1 && i2 == -1) + return 0; + if (i1 >= 0 && i2 >= 0) + *diff = i1 - i2; + else if (i1 >= 0) + *diff = -1; + else /* if (i2 >= 0) */ + *diff = 1; + return 1; +} /* * Compare S1 and S2 as strings holding indices/version numbers, @@ -74,6 +117,13 @@ int versioncmp(const char *s1, const char *s2) state += (c1 == '0') + (isdigit (c1) != 0); } + if (!initialized) { + initialized = 1; + prereleases = git_config_get_value_multi("versionsort.prereleasesuffix"); + } + if (prereleases && swap_prereleases(p1 - 1, p2 - 1, &diff)) + return diff; + state = result_type[state * 3 + (((c2 == '0') + (isdigit (c2) != 0)))]; switch (state) { -- 2.3.0.rc1.137.g477eb31 ^ permalink raw reply related [flat|nested] 74+ messages in thread
* Re: [PATCH] versionsort: support reorder prerelease suffixes 2015-02-26 10:44 ` [PATCH] versionsort: support reorder prerelease suffixes Nguyễn Thái Ngọc Duy @ 2015-02-27 21:37 ` Junio C Hamano 2015-03-05 1:28 ` Junio C Hamano 0 siblings, 1 reply; 74+ messages in thread From: Junio C Hamano @ 2015-02-27 21:37 UTC (permalink / raw) To: Nguyễn Thái Ngọc Duy; +Cc: git, Jeff King Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes: > Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> > --- > Second round. Looking better. We can do > "1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1" too but it relies on > config key's loading order, a bit iffy. > > Documentation/config.txt | 7 +++++++ > t/t7004-tag.sh | 28 +++++++++++++++++++++++++++ > versioncmp.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 85 insertions(+) > > diff --git a/Documentation/config.txt b/Documentation/config.txt > index 04e2a71..8e078df 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -2539,6 +2539,13 @@ user.signingkey:: > This option is passed unchanged to gpg's --local-user parameter, > so you may specify a key using any method that gpg supports. > > +versionsort.prereleaseSuffix:: > + When version sort is used in linkgit:git-tag[1], prerelease > + tags (e.g. "1.0-rc1") may appear after the main release > + "1.0". By specifying the suffix "-rc" in this variable, > + "1.0-rc1" will appear before "1.0". One variable assignment > + per suffix. I think the last half-sentence want to mean that [versionsort] prereleaseSuffix = -pre prereleaseSuffix = -rc is the supported way to write, and not [versionsort] prereleaseSuffix = -pre -rc but it probably is unclear unless the reader already knows what it is trying to say. The reader also needs to learn somewhere how the order of the entries affects the result. > + if (i1 == -1 && i2 == -1) > + return 0; > + if (i1 >= 0 && i2 >= 0) > + *diff = i1 - i2; > + else if (i1 >= 0) > + *diff = -1; p1 is a prerelease and p2 is not, so p1 comes before p2. > + else /* if (i2 >= 0) */ > + *diff = 1; and the other way around. The math makes sense, I think. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH] versionsort: support reorder prerelease suffixes 2015-02-27 21:37 ` Junio C Hamano @ 2015-03-05 1:28 ` Junio C Hamano 2015-03-09 1:01 ` Duy Nguyen 2015-03-10 10:16 ` [PATCH] config.txt: update versioncmp.prereleaseSuffix Nguyễn Thái Ngọc Duy 0 siblings, 2 replies; 74+ messages in thread From: Junio C Hamano @ 2015-03-05 1:28 UTC (permalink / raw) To: Nguyễn Thái Ngọc Duy; +Cc: git, Jeff King Junio C Hamano <gitster@pobox.com> writes: >> +versionsort.prereleaseSuffix:: >> + When version sort is used in linkgit:git-tag[1], prerelease >> + tags (e.g. "1.0-rc1") may appear after the main release >> + "1.0". By specifying the suffix "-rc" in this variable, >> + "1.0-rc1" will appear before "1.0". One variable assignment >> + per suffix. > > I think the last half-sentence want to mean that > > [versionsort] > prereleaseSuffix = -pre > prereleaseSuffix = -rc > > is the supported way to write, and not > > [versionsort] > prereleaseSuffix = -pre -rc > > but it probably is unclear unless the reader already knows what it > is trying to say. The reader also needs to learn somewhere how the > order of the entries affects the result. This is already in 'next', so could you fix that half-sentence in the documentation via an incremental update? Thanks. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH] versionsort: support reorder prerelease suffixes 2015-03-05 1:28 ` Junio C Hamano @ 2015-03-09 1:01 ` Duy Nguyen 2015-03-10 7:52 ` Junio C Hamano 2015-03-10 10:16 ` [PATCH] config.txt: update versioncmp.prereleaseSuffix Nguyễn Thái Ngọc Duy 1 sibling, 1 reply; 74+ messages in thread From: Duy Nguyen @ 2015-03-09 1:01 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git Mailing List, Jeff King On Thu, Mar 5, 2015 at 8:28 AM, Junio C Hamano <gitster@pobox.com> wrote: > Junio C Hamano <gitster@pobox.com> writes: > >>> +versionsort.prereleaseSuffix:: >>> + When version sort is used in linkgit:git-tag[1], prerelease >>> + tags (e.g. "1.0-rc1") may appear after the main release >>> + "1.0". By specifying the suffix "-rc" in this variable, >>> + "1.0-rc1" will appear before "1.0". One variable assignment >>> + per suffix. >> >> I think the last half-sentence want to mean that >> >> [versionsort] >> prereleaseSuffix = -pre >> prereleaseSuffix = -rc >> >> is the supported way to write, and not >> >> [versionsort] >> prereleaseSuffix = -pre -rc >> >> but it probably is unclear unless the reader already knows what it >> is trying to say. The reader also needs to learn somewhere how the >> order of the entries affects the result. > > This is already in 'next', so could you fix that half-sentence in > the documentation via an incremental update? How about.. ".. "1.0-rc1" will appear before "1.0". This key can be specified multiple times, one for each suffix. The order of suffixes in the config file determines the sorting order (e.g. if "-pre" appears before "-rc" in the config file then 1.0-preXX is sorted before 1.0-rcXX). The sorting order between different suffixes is undefined if they are in multiple config files" -- Duy ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH] versionsort: support reorder prerelease suffixes 2015-03-09 1:01 ` Duy Nguyen @ 2015-03-10 7:52 ` Junio C Hamano 2015-03-10 8:03 ` Eric Sunshine 0 siblings, 1 reply; 74+ messages in thread From: Junio C Hamano @ 2015-03-10 7:52 UTC (permalink / raw) To: Duy Nguyen; +Cc: Git Mailing List, Jeff King Duy Nguyen <pclouds@gmail.com> writes: > On Thu, Mar 5, 2015 at 8:28 AM, Junio C Hamano <gitster@pobox.com> wrote: >> Junio C Hamano <gitster@pobox.com> writes: >> >>>> +versionsort.prereleaseSuffix:: >>>> + When version sort is used in linkgit:git-tag[1], prerelease >>>> + tags (e.g. "1.0-rc1") may appear after the main release >>>> + "1.0". By specifying the suffix "-rc" in this variable, >>>> + "1.0-rc1" will appear before "1.0". One variable assignment >>>> + per suffix. > ... > How about.. > > ".. "1.0-rc1" will appear before "1.0". This key can be specified > multiple times, one for each suffix. The order of suffixes in the > config file determines the sorting order (e.g. if "-pre" appears > before "-rc" in the config file then 1.0-preXX is sorted before > 1.0-rcXX). The sorting order between different suffixes is undefined > if they are in multiple config files" OK. Later we might resurrect that "How would we spell 'reset this variable' in our configuration file? Is that even a good idea in the first place?" topic and at that time the last sentence may have to change to make it more useful, but because we are not there yet, the above would be a reasonable description. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH] versionsort: support reorder prerelease suffixes 2015-03-10 7:52 ` Junio C Hamano @ 2015-03-10 8:03 ` Eric Sunshine 0 siblings, 0 replies; 74+ messages in thread From: Eric Sunshine @ 2015-03-10 8:03 UTC (permalink / raw) To: Junio C Hamano; +Cc: Duy Nguyen, Git Mailing List, Jeff King On Tue, Mar 10, 2015 at 3:52 AM, Junio C Hamano <gitster@pobox.com> wrote: > Duy Nguyen <pclouds@gmail.com> writes: >> How about.. >> >> ".. "1.0-rc1" will appear before "1.0". This key can be specified >> multiple times, one for each suffix. The order of suffixes in the Minor bike-shedding: s/one for each suffix/once per suffix/ >> config file determines the sorting order (e.g. if "-pre" appears >> before "-rc" in the config file then 1.0-preXX is sorted before >> 1.0-rcXX). The sorting order between different suffixes is undefined >> if they are in multiple config files" > > OK. Later we might resurrect that "How would we spell 'reset this > variable' in our configuration file? Is that even a good idea in > the first place?" topic and at that time the last sentence may have > to change to make it more useful, but because we are not there yet, > the above would be a reasonable description. ^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH] config.txt: update versioncmp.prereleaseSuffix 2015-03-05 1:28 ` Junio C Hamano 2015-03-09 1:01 ` Duy Nguyen @ 2015-03-10 10:16 ` Nguyễn Thái Ngọc Duy 1 sibling, 0 replies; 74+ messages in thread From: Nguyễn Thái Ngọc Duy @ 2015-03-10 10:16 UTC (permalink / raw) To: git Cc: Junio C Hamano, Jeff King, Eric Sunshine, Nguyễn Thái Ngọc Duy Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> --- Documentation/config.txt | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 69a7345..fe8705d 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2527,8 +2527,13 @@ versionsort.prereleaseSuffix:: When version sort is used in linkgit:git-tag[1], prerelease tags (e.g. "1.0-rc1") may appear after the main release "1.0". By specifying the suffix "-rc" in this variable, - "1.0-rc1" will appear before "1.0". One variable assignment - per suffix. + "1.0-rc1" will appear before "1.0". ++ +This variable can be specified multiple times, once per suffix. The +order of suffixes in the config file determines the sorting order +(e.g. if "-pre" appears before "-rc" in the config file then 1.0-preXX +is sorted before 1.0-rcXX). The sorting order between different +suffixes is undefined if they are in multiple config files. web.browser:: Specify a web browser that may be used by some commands. -- 2.3.0.rc1.137.g477eb31 ^ permalink raw reply related [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-18 19:14 [RFH] GSoC 2015 application Jeff King ` (3 preceding siblings ...) 2015-02-20 3:26 ` [RFH] GSoC 2015 application Duy Nguyen @ 2015-02-20 5:35 ` Michael Haggerty 2015-02-20 7:29 ` Jeff King 2015-02-26 13:10 ` [RFH] GSoC 2015 application Duy Nguyen 5 siblings, 1 reply; 74+ messages in thread From: Michael Haggerty @ 2015-02-20 5:35 UTC (permalink / raw) To: Jeff King, git On 02/18/2015 08:14 PM, Jeff King wrote: > The response to my previous email was not overwhelming, but people did > express some interest in Git doing GSoC this year. So I've started on > the application, using last year's version as a template. Regretfully, I can't in good conscience volunteer to be a GSoC mentor this year. I have too many other projects going on and don't see how I can free up enough time to be a good mentor. Michael -- Michael Haggerty mhagger@alum.mit.edu ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-20 5:35 ` [RFH] GSoC 2015 application Michael Haggerty @ 2015-02-20 7:29 ` Jeff King 2015-02-20 8:06 ` Junio C Hamano 2015-02-20 9:39 ` Matthieu Moy 0 siblings, 2 replies; 74+ messages in thread From: Jeff King @ 2015-02-20 7:29 UTC (permalink / raw) To: Michael Haggerty; +Cc: Stefan Beller, Matthieu Moy, Junio C Hamano, git On Fri, Feb 20, 2015 at 06:35:09AM +0100, Michael Haggerty wrote: > On 02/18/2015 08:14 PM, Jeff King wrote: > > The response to my previous email was not overwhelming, but people did > > express some interest in Git doing GSoC this year. So I've started on > > the application, using last year's version as a template. > > Regretfully, I can't in good conscience volunteer to be a GSoC mentor > this year. I have too many other projects going on and don't see how I > can free up enough time to be a good mentor. Thanks for letting us know. I am somewhat in the same boat. I might be able to make time, but the bar that the student/project combo would have to clear would be quite high for me to agree to do so. This brings up an important issue. We cannot do GSoC without mentors. I had hoped that people populating the "ideas" list would volunteer to mentor for their projects. But so far the possibilities are: - Stefan - me, who has already promised to be stingy - Matthieu, who also cited time constraints - Junio, who contributed some project ideas, but who in the past has declined to mentor in order to remain impartial as the maintainer who evaluates student results (which I think is quite reasonable) So...basically 1 mentor and 2 reticent maybes? That doesn't look good. We are not committed to anything until we accept student proposals, of course. But I would not want to waste students' time in applying if it is not realistic for us to accept them. -Peff ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-20 7:29 ` Jeff King @ 2015-02-20 8:06 ` Junio C Hamano 2015-02-20 9:39 ` Matthieu Moy 1 sibling, 0 replies; 74+ messages in thread From: Junio C Hamano @ 2015-02-20 8:06 UTC (permalink / raw) To: Jeff King; +Cc: Michael Haggerty, Stefan Beller, Matthieu Moy, Git Mailing List On Thu, Feb 19, 2015 at 11:29 PM, Jeff King <peff@peff.net> wrote: > > This brings up an important issue. We cannot do GSoC without mentors. I > had hoped that people populating the "ideas" list would volunteer to > mentor for their projects. > > But so far the possibilities are: > > - Stefan > > - me, who has already promised to be stingy > > - Matthieu, who also cited time constraints > > - Junio, who contributed some project ideas, but who in the past has > declined to mentor in order to remain impartial as the maintainer > who evaluates student results (which I think is quite reasonable) > > So...basically 1 mentor and 2 reticent maybes? That doesn't look good. Indeed, the mentor panel looks particularly weak this year, if nobody can afford the time for proper mentoring. Even though I can indirectly help by giving reviews at a more hand-holding level than usual, there is a limit. And I definitely do not foresee acting as a mentor myself. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-20 7:29 ` Jeff King 2015-02-20 8:06 ` Junio C Hamano @ 2015-02-20 9:39 ` Matthieu Moy 2015-02-20 9:48 ` Jeff King 2015-03-04 22:05 ` Philip Oakley 1 sibling, 2 replies; 74+ messages in thread From: Matthieu Moy @ 2015-02-20 9:39 UTC (permalink / raw) To: Jeff King; +Cc: Michael Haggerty, Stefan Beller, Junio C Hamano, git Jeff King <peff@peff.net> writes: > - Matthieu, who also cited time constraints Just to clarify: last year we were co-mentoring with Ram. I ended up having a lot of time and did most of the work (not blaming Ram, and I enjoyed the experience). I'm still motivated to co-mentor, but this time the co-mentoring has to be more balanced (or unballanced to the other mentor ;-) ). > - Junio, who contributed some project ideas, but who in the past has > declined to mentor in order to remain impartial as the maintainer > who evaluates student results (which I think is quite reasonable) Yes, as a mentor I did appreciate having Junio as impartial maintainer/reviewer. And he did for sure contribute even without being a mentor! >From your list, it seems we can target 1 or 2 slots. I'd say it's still worth applying, but if we don't find more mentors then perhaps it would make sense to say so explicitely in http://git.github.io/SoC-2015-Ideas.html so that students looking for organization know that we'll have very few slots. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-20 9:39 ` Matthieu Moy @ 2015-02-20 9:48 ` Jeff King 2015-02-20 11:35 ` Jeff King 2015-03-04 22:05 ` Philip Oakley 1 sibling, 1 reply; 74+ messages in thread From: Jeff King @ 2015-02-20 9:48 UTC (permalink / raw) To: Matthieu Moy; +Cc: Michael Haggerty, Stefan Beller, Junio C Hamano, git On Fri, Feb 20, 2015 at 10:39:42AM +0100, Matthieu Moy wrote: > Jeff King <peff@peff.net> writes: > > > - Matthieu, who also cited time constraints > > Just to clarify: last year we were co-mentoring with Ram. I ended up > having a lot of time and did most of the work (not blaming Ram, and I > enjoyed the experience). I'm still motivated to co-mentor, but this time > the co-mentoring has to be more balanced (or unballanced to the other > mentor ;-) ). Yes, but who is your co-mentor this year? :) > From your list, it seems we can target 1 or 2 slots. I'd say it's still > worth applying, but if we don't find more mentors then perhaps it would > make sense to say so explicitely in > http://git.github.io/SoC-2015-Ideas.html so that students looking for > organization know that we'll have very few slots. I don't mind doing 1 slot if that's what we have resources for. But if we have to say "eh, we do not really have enough mentors to support you", then I wonder if it is worth doing. They do not know how many people have applied, or how tight the competition is. -Peff ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-20 9:48 ` Jeff King @ 2015-02-20 11:35 ` Jeff King 2015-02-23 8:02 ` Matthieu Moy 0 siblings, 1 reply; 74+ messages in thread From: Jeff King @ 2015-02-20 11:35 UTC (permalink / raw) To: Matthieu Moy; +Cc: Michael Haggerty, Stefan Beller, Junio C Hamano, git On Fri, Feb 20, 2015 at 04:48:44AM -0500, Jeff King wrote: > > From your list, it seems we can target 1 or 2 slots. I'd say it's still > > worth applying, but if we don't find more mentors then perhaps it would > > make sense to say so explicitely in > > http://git.github.io/SoC-2015-Ideas.html so that students looking for > > organization know that we'll have very few slots. > > I don't mind doing 1 slot if that's what we have resources for. But if > we have to say "eh, we do not really have enough mentors to support > you", then I wonder if it is worth doing. They do not know how many > people have applied, or how tight the competition is. So that being said, I did complete the application. We can still withdraw if we want before students start applying, or we can put a disclaimer on the ideas page. I tweaked the application text to update it for this year, but nothing too major. The result is at: http://git.github.io/SoC-2015-Org-Application.html That content was cut-and-pasted into Google's application interface. Matthieu, as backup admin you should have access to tweak that if there are typos, etc (and I will probably not be available to apply fixes from now until the deadline, so please do so if you see anything). We can continue to improve the ideas page as time goes on. At some point Google will look at as part of the application, but probably not right at the deadline. :) -Peff ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-20 11:35 ` Jeff King @ 2015-02-23 8:02 ` Matthieu Moy 2015-02-23 15:36 ` Jeff King 0 siblings, 1 reply; 74+ messages in thread From: Matthieu Moy @ 2015-02-23 8:02 UTC (permalink / raw) To: Jeff King; +Cc: Michael Haggerty, Stefan Beller, Junio C Hamano, git Jeff King <peff@peff.net> writes: > So that being said, I did complete the application. We can still > withdraw if we want before students start applying, or we can put a > disclaimer on the ideas page. I'm in favor of the disclaimer, but I won't fight if other people think it's better to just withdraw. > That content was cut-and-pasted into Google's application interface. > Matthieu, as backup admin you should have access to tweak that if there > are typos, etc (and I will probably not be available to apply fixes from > now until the deadline, so please do so if you see anything). I do have access to the text here: http://www.google-melange.com/gsoc/org/survey_response/show/google/gsoc2015/git but I did not find an "edit" button. I can edit http://www.google-melange.com/gsoc/org/profile/edit/google/gsoc2015/git OTOH. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-23 8:02 ` Matthieu Moy @ 2015-02-23 15:36 ` Jeff King 0 siblings, 0 replies; 74+ messages in thread From: Jeff King @ 2015-02-23 15:36 UTC (permalink / raw) To: Matthieu Moy; +Cc: Michael Haggerty, Stefan Beller, Junio C Hamano, git On Mon, Feb 23, 2015 at 09:02:58AM +0100, Matthieu Moy wrote: > > That content was cut-and-pasted into Google's application interface. > > Matthieu, as backup admin you should have access to tweak that if there > > are typos, etc (and I will probably not be available to apply fixes from > > now until the deadline, so please do so if you see anything). > > I do have access to the text here: > > http://www.google-melange.com/gsoc/org/survey_response/show/google/gsoc2015/git > > but I did not find an "edit" button. I can edit > > http://www.google-melange.com/gsoc/org/profile/edit/google/gsoc2015/git > > OTOH. I think it's just because the application period has ended, so our answers to the questions are frozen. -Peff ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-20 9:39 ` Matthieu Moy 2015-02-20 9:48 ` Jeff King @ 2015-03-04 22:05 ` Philip Oakley 2015-03-04 23:55 ` Stefan Beller 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy 1 sibling, 2 replies; 74+ messages in thread From: Philip Oakley @ 2015-03-04 22:05 UTC (permalink / raw) To: Matthieu Moy, Jeff King Cc: Michael Haggerty, Stefan Beller, Junio C Hamano, git From: "Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr> Sent: Friday, February 20, 2015 9:39 AM > Jeff King <peff@peff.net> writes: > >> - Matthieu, who also cited time constraints > > Just to clarify: last year we were co-mentoring with Ram. I ended up > having a lot of time and did most of the work (not blaming Ram, and I > enjoyed the experience). I'm still motivated to co-mentor, but this > time > the co-mentoring has to be more balanced (or unballanced to the other > mentor ;-) ). > >> - Junio, who contributed some project ideas, but who in the past >> has >> declined to mentor in order to remain impartial as the maintainer >> who evaluates student results (which I think is quite reasonable) > > Yes, as a mentor I did appreciate having Junio as impartial > maintainer/reviewer. And he did for sure contribute even without being > a > mentor! > > From your list, it seems we can target 1 or 2 slots. I'd say it's > still > worth applying, but if we don't find more mentors then perhaps it > would > make sense to say so explicitely in > http://git.github.io/SoC-2015-Ideas.html so that students looking for > organization know that we'll have very few slots. > > -- Hi, Given the mention of the GSoC ideas list, I thought it worth writing out one of my little ideas.. A possible idea is to add a date based variant of shallow clone : 'git clone --date <when> ...' in the same vein as the existing depth (shallow) clone. On the wire advertise a 'shallow-date' capability, passing a signed big integer as the unix time for the shallow cut-off point (i.e. future extensible to cover a very wide date range), with optional(?) date+depth hysteresis (clock skew) parameters. Command line interface to use existing date/time formats, (and possibly revision dates?). Extend 'git fetch' to include the --date <when> option. Ensure that 'git push' continues to work with and between shallow/shallow-date clones. Update the documentation in line with the capability. Document any migration plan (if required) Why === This capability would eliminate the existing confusion over the --depth parameter as different branches may require different depths to reach a "common" start point. Extra points for an easy method of '--unshallow-date <new_when>' to remove 'old' commits that the user may no longer need locally. (unshallow may not be the right term...) -- Philip ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-03-04 22:05 ` Philip Oakley @ 2015-03-04 23:55 ` Stefan Beller 2015-03-05 0:17 ` Philip Oakley 2015-03-05 0:26 ` Duy Nguyen 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy 1 sibling, 2 replies; 74+ messages in thread From: Stefan Beller @ 2015-03-04 23:55 UTC (permalink / raw) To: Philip Oakley Cc: Matthieu Moy, Jeff King, Michael Haggerty, Junio C Hamano, git On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley <philipoakley@iee.org> wrote: > A possible idea is to add a date based variant of shallow clone : > > 'git clone --date <when> ...' > > in the same vein as the existing depth (shallow) clone. As food for thought: Maybe broaden this further up to the git-ish way of describing refs, so git clone --since 2.weeks.ago <url> git clone --since v2.10 <url> git clone --since c0ffee^^ <url> would all equally work? I am not sure if that is feasible though, but it would come in handy. (E.g. you are an end user and want to bisect down a bug which you notice in the new version X but not in old version Y, so you start on getting the sources, compiling, bisecting) ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-03-04 23:55 ` Stefan Beller @ 2015-03-05 0:17 ` Philip Oakley 2015-03-05 0:22 ` Junio C Hamano 2015-03-05 0:26 ` Duy Nguyen 1 sibling, 1 reply; 74+ messages in thread From: Philip Oakley @ 2015-03-05 0:17 UTC (permalink / raw) To: Stefan Beller Cc: Matthieu Moy, Jeff King, Michael Haggerty, Junio C Hamano, git From: "Stefan Beller" <sbeller@google.com> > On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley <philipoakley@iee.org> > wrote: > >> A possible idea is to add a date based variant of shallow clone : >> >> 'git clone --date <when> ...' >> >> in the same vein as the existing depth (shallow) clone. > > As food for thought: > Maybe broaden this further up to the git-ish way of describing refs, > so > > git clone --since 2.weeks.ago <url> > git clone --since v2.10 <url> > git clone --since c0ffee^^ <url> > > would all equally work? The use of --since instead of --date would be an equally valid way of spelling the option (coders choice;-) At the clone stage, the local Git can't determine (for the 2nd & 3d option) where such a revison is located, so would have to send the revision string to the server for processing, which could complicate the protocol. Hence my choice of a simple unix time value at the protocol level. An alternate/addition is to use a nominated sha1 (from ls-remote) as a stand in for a date, allowing your option 2 (--since <tag>) to be implemented as an alias or script. It all depends on how complicated we want it to become, but starting simple (though extensible) is important. > > I am not sure if that is feasible though, but it would come in handy. > (E.g. > you are an end user and want to bisect down a bug which you notice in > the > new version X but not in old version Y, so you start on getting the > sources, > compiling, bisecting) > -- Philip ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-03-05 0:17 ` Philip Oakley @ 2015-03-05 0:22 ` Junio C Hamano 2015-03-05 0:32 ` Stefan Beller 0 siblings, 1 reply; 74+ messages in thread From: Junio C Hamano @ 2015-03-05 0:22 UTC (permalink / raw) To: Philip Oakley Cc: Stefan Beller, Matthieu Moy, Jeff King, Michael Haggerty, Git Mailing List On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley <philipoakley@iee.org> wrote: >> >> git clone --since 2.weeks.ago <url> >> git clone --since v2.10 <url> > > The use of --since instead of --date would be an equally valid way of > spelling the option (coders choice;-) I think it is a demonstration of poor taste. Everywhere else, --since is a way to specify the date, not a revision. Why should this one alone should be different? ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-03-05 0:22 ` Junio C Hamano @ 2015-03-05 0:32 ` Stefan Beller 2015-03-05 1:17 ` Junio C Hamano 2015-03-05 6:19 ` Junio C Hamano 0 siblings, 2 replies; 74+ messages in thread From: Stefan Beller @ 2015-03-05 0:32 UTC (permalink / raw) To: Junio C Hamano Cc: Philip Oakley, Matthieu Moy, Jeff King, Michael Haggerty, Git Mailing List On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano <gitster@pobox.com> wrote: > On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley <philipoakley@iee.org> wrote: >>> >>> git clone --since 2.weeks.ago <url> >>> git clone --since v2.10 <url> >> >> The use of --since instead of --date would be an equally valid way of >> spelling the option (coders choice;-) > > I think it is a demonstration of poor taste. Everywhere else, --since > is a way to > specify the date, not a revision. Why should this one alone should be different? I wanted to point out the broader use case than being stylish correct, though from an English grammars point of view `--since` should also be able to describe a point in time ("since 2 weeks ago" is as valid as "since Feb 17th") I cannot remember the usual option off hand to describe the revision instead of a date. Maybe we want to have one option long term to allow any kind of input (revision and date), as this may be easier to remember, especially if it aligns well with the English language. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-03-05 0:32 ` Stefan Beller @ 2015-03-05 1:17 ` Junio C Hamano 2015-03-05 6:19 ` Junio C Hamano 1 sibling, 0 replies; 74+ messages in thread From: Junio C Hamano @ 2015-03-05 1:17 UTC (permalink / raw) To: Stefan Beller Cc: Philip Oakley, Matthieu Moy, Jeff King, Michael Haggerty, Git Mailing List Stefan Beller <sbeller@google.com> writes: > On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano <gitster@pobox.com> wrote: >> On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley <philipoakley@iee.org> wrote: >>>> >>>> git clone --since 2.weeks.ago <url> >>>> git clone --since v2.10 <url> >>> >>> The use of --since instead of --date would be an equally valid way of >>> spelling the option (coders choice;-) >> >> I think it is a demonstration of poor taste. Everywhere else, >> --since is a way to specify the date, not a revision. Why should >> this one alone should be different? > > I wanted to point out the broader use case than being stylish correct, OK. I actually think it is OK to envision that "--since" will be made appliable to non-dates in the longer term. The proposal, when dug into minor detail, may include extending approxidate() to take a revision name, i.e. git log --since=v2.0.0 master would behave as if git log --since=@1401300269 master because that is the timestamp the v2.0.0 tag carries. Note that I do not think it is a good idea to rewrite the above to git log v2.0.0..master at all (hint: think how you would rewrite --until). As to the shallow-boundary capability implementation, I think what has been discussed in the thread is basically sound. Just send the end-user supplied string ("2.weeks.ago", "v2.10", etc.) over the wire without interpreting locally, and have the server end apply (an updated) approxidate() on it, internally compute the exact cut-point just like "git bundle create" does when it computes the prerequisites, and use the resulting commits as the shallow boundary. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-03-05 0:32 ` Stefan Beller 2015-03-05 1:17 ` Junio C Hamano @ 2015-03-05 6:19 ` Junio C Hamano 2015-03-06 11:24 ` Duy Nguyen 1 sibling, 1 reply; 74+ messages in thread From: Junio C Hamano @ 2015-03-05 6:19 UTC (permalink / raw) To: Stefan Beller Cc: Philip Oakley, Matthieu Moy, Jeff King, Michael Haggerty, Git Mailing List Stefan Beller <sbeller@google.com> writes: > I cannot remember the usual option off hand to describe the revision > instead of a date. Because "log --since=<date of v1.0> master" and "log v1.0..master" mean two completely different things, we need some way to specify which one of these two the user wants to "git clone" so that the user can say at what point the user wants the shallow history to begin. I think it is a good idea to use --since for date-based cut-off, in addition to the existing --depth that is depth-based cut-off, and we probably would want another one that gives the topology-based cut-off, so that we can express the range in a similar way to "log v1.0..master". But when we talk about the topology-based cut-off locally, we always use the set syntax A..B, ^A B, etc. and never a command line option with an argument to specify "the bottom of the history". It is not surprising that you don't remember any usual option for that, because there isn't one. The closest thing I can think of that looks somewhat like a command line option is "--not", as in git log A B --not C D E that is equivalent to "A B ^C ^D ^E", but that is not an option that takes an argument. I do not know if it is particularly a good idea to say: git clone --not v2.0 $URL to specify topology-based cut-off. But we would need some way to say a set-based cut-off; I do not think using --since for that purpose is a good idea, though, because that is already taken for date-based cut-off, and mixing them together will introduce confusion. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-03-05 6:19 ` Junio C Hamano @ 2015-03-06 11:24 ` Duy Nguyen 0 siblings, 0 replies; 74+ messages in thread From: Duy Nguyen @ 2015-03-06 11:24 UTC (permalink / raw) To: Junio C Hamano Cc: Stefan Beller, Philip Oakley, Matthieu Moy, Jeff King, Michael Haggerty, Git Mailing List On Wed, Mar 04, 2015 at 10:19:16PM -0800, Junio C Hamano wrote: > But we would need some way to say a set-based cut-off; I do not > think using --since for that purpose is a good idea, though, because > that is already taken for date-based cut-off, and mixing them > together will introduce confusion. I agree. Although I look at this from the implementation perspective: mixing the two would make it really hard to detect which is which. Speaking of implementation.. On Thu, Mar 5, 2015 at 5:28 PM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote: > I do have plenty of topics to finish up. But I wanted to see how this > feature would look like. I needed to write some code for that and for > straightening my thoughts. Totally untested, but I think it looks cool :) > > I think this feature is feasible. The protocol and UI are still up in > the air. Plenty of work for any student who wants to pick this up. I think students are losing the chance to have this fun now. A rough implementation is available at https://github.com/pclouds/git/tree/shallow-since if anybody wants to try out. I don't post it here yet because while it seems to be working in my limited tests, there could be some corner cases to sort out, bugs and style violations. Also tests to be added. Documentation changes below. --not and --since can be mixed. Neither of them can be used with --depth though, but I'd consider it a temporary limitation. diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index b09a783..ec68374 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -13,6 +13,15 @@ to the specified number of commits from the tip of each remote branch history. Tags for the deepened commits are not fetched. +--since=<date>:: + Deepen or shorten the history of a 'shallow' repository to + include all reachable commits that are after <date>. + +--not=<revision>:: + Deepen or shorten the history of a 'shallow' repository to + exclude commits reachable from a specified remote branch or tag. + This option can be specified multiple times. + --unshallow:: If the source repository is complete, convert a shallow repository to a complete one, removing all the limitations diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index f1f2a3f..fc094c6 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -187,6 +187,14 @@ objects from the source repository into a pack in the cloned repository. Create a 'shallow' clone with a history truncated to the specified number of revisions. +--since=<date>:: + Create a 'shallow' clone with a history after the specified time. + +--not=<revision>:: + Create a 'shallow' clone with a history, excluding commits + reachable from a specified remote branch or tag. This option + can be specified multiple times. + --[no-]single-branch:: Clone only the history leading to the tip of a single branch, either specified by the `--branch` option or the primary diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index 4f8a7bf..3649301 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -179,6 +179,24 @@ This capability adds "deepen", "shallow" and "unshallow" commands to the fetch-pack/upload-pack protocol so clients can request shallow clones. +deepen-since +------------ + +This capability adds "deepen-since" command to fetch-pack/upload-pack +protocol so the client can request shallow clones that are cut at a +specific time, instead of depth. Internally it's equivalent of doing +"rev-list --since=<time>" on the server side. "deepen-since" cannot be +used with "deepen". + +deepen-not +---------- + +This capability adds "deepen-not" command to fetch-pack/upload-pack +protocol so the client can request shallow clones that are cut at a +specific revision, instead of depth. Internally it's equivalent of +doing "rev-list --not <rev>" on the server side. "deepen-not" +cannot be used with "deepen", but can be used with "deepen-since". + no-progress ----------- ^ permalink raw reply related [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-03-04 23:55 ` Stefan Beller 2015-03-05 0:17 ` Philip Oakley @ 2015-03-05 0:26 ` Duy Nguyen 1 sibling, 0 replies; 74+ messages in thread From: Duy Nguyen @ 2015-03-05 0:26 UTC (permalink / raw) To: Stefan Beller Cc: Philip Oakley, Matthieu Moy, Jeff King, Michael Haggerty, Junio C Hamano, git On Thu, Mar 5, 2015 at 6:55 AM, Stefan Beller <sbeller@google.com> wrote: > On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley <philipoakley@iee.org> wrote: > >> A possible idea is to add a date based variant of shallow clone : >> >> 'git clone --date <when> ...' >> >> in the same vein as the existing depth (shallow) clone. > > As food for thought: > Maybe broaden this further up to the git-ish way of describing refs, so > > git clone --since 2.weeks.ago <url> > git clone --since v2.10 <url> > git clone --since c0ffee^^ <url> > > would all equally work? Yes, and we could generalize it further: add shallow-rev-list capability and send "shallow-rev-list <rev-list options and _some_ rev>" line to define shallow boundary. The protocol change would be simple enough. The hard part is select a safe subset of rev-list options that can be used in this mode and reject the rest. > I am not sure if that is feasible though, but it would come in handy. (E.g. > you are an end user and want to bisect down a bug which you notice in the > new version X but not in old version Y, so you start on getting the sources, > compiling, bisecting) -- Duy ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-03-04 22:05 ` Philip Oakley 2015-03-04 23:55 ` Stefan Beller @ 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 1/6] upload-pack: move shallow deepen code out of receive_needs() Nguyễn Thái Ngọc Duy ` (5 more replies) 1 sibling, 6 replies; 74+ messages in thread From: Nguyễn Thái Ngọc Duy @ 2015-03-05 10:28 UTC (permalink / raw) To: philipoakley; +Cc: git, Nguyễn Thái Ngọc Duy On Thu, Mar 5, 2015 at 5:05 AM, Philip Oakley <philipoakley@iee.org> wrote: > Given the mention of the GSoC ideas list, I thought it worth writing out one > of my little ideas.. > > > A possible idea is to add a date based variant of shallow clone : > > 'git clone --date <when> ...' > > in the same vein as the existing depth (shallow) clone. I do have plenty of topics to finish up. But I wanted to see how this feature would look like. I needed to write some code for that and for straightening my thoughts. Totally untested, but I think it looks cool :) I think this feature is feasible. The protocol and UI are still up in the air. Plenty of work for any student who wants to pick this up. Nguyễn Thái Ngọc Duy (6): upload-pack: move shallow deepen code out of receive_needs() upload-pack: move "shallow" sending code out of deepen() upload-pack: remove unused variable "backup" upload-pack: move "unshallow" sending code out of deepen() shallow.c: implement a generic shallow boundary finder based on rev-list upload-pack: example code to use get_shallow_commits_by_rev_list commit.h | 2 + shallow.c | 65 +++++++++++++++++++++++++++++ upload-pack.c | 129 +++++++++++++++++++++++++++++++++++++--------------------- 3 files changed, 149 insertions(+), 47 deletions(-) -- 2.3.0.rc1.137.g477eb31 ^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH 1/6] upload-pack: move shallow deepen code out of receive_needs() 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy @ 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 2/6] upload-pack: move "shallow" sending code out of deepen() Nguyễn Thái Ngọc Duy ` (4 subsequent siblings) 5 siblings, 0 replies; 74+ messages in thread From: Nguyễn Thái Ngọc Duy @ 2015-03-05 10:28 UTC (permalink / raw) To: philipoakley; +Cc: git, Nguyễn Thái Ngọc Duy This is a prep step for further refactoring. Besides reindentation and s/shallows\./shallows->/g, no other changes are expected. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> --- upload-pack.c | 99 +++++++++++++++++++++++++++++++---------------------------- 1 file changed, 52 insertions(+), 47 deletions(-) diff --git a/upload-pack.c b/upload-pack.c index b531a32..74f48f9 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -531,6 +531,55 @@ error: } } +static void deepen(int depth, const struct object_array *shallows) +{ + struct commit_list *result = NULL, *backup = NULL; + int i; + if (depth == INFINITE_DEPTH && !is_repository_shallow()) + for (i = 0; i < shallows->nr; i++) { + struct object *object = shallows->objects[i].item; + object->flags |= NOT_SHALLOW; + } + else + backup = result = + get_shallow_commits(&want_obj, depth, + SHALLOW, NOT_SHALLOW); + while (result) { + struct object *object = &result->item->object; + if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) { + packet_write(1, "shallow %s", + sha1_to_hex(object->sha1)); + register_shallow(object->sha1); + shallow_nr++; + } + result = result->next; + } + free_commit_list(backup); + for (i = 0; i < shallows->nr; i++) { + struct object *object = shallows->objects[i].item; + if (object->flags & NOT_SHALLOW) { + struct commit_list *parents; + packet_write(1, "unshallow %s", + sha1_to_hex(object->sha1)); + object->flags &= ~CLIENT_SHALLOW; + /* make sure the real parents are parsed */ + unregister_shallow(object->sha1); + object->parsed = 0; + parse_commit_or_die((struct commit *)object); + parents = ((struct commit *)object)->parents; + while (parents) { + add_object_array(&parents->item->object, + NULL, &want_obj); + parents = parents->next; + } + add_object_array(object, NULL, &extra_edge_obj); + } + /* make sure commit traversal conforms to client */ + register_shallow(object->sha1); + } + packet_flush(1); +} + static void receive_needs(void) { struct object_array shallows = OBJECT_ARRAY_INIT; @@ -623,53 +672,9 @@ static void receive_needs(void) if (depth == 0 && shallows.nr == 0) return; - if (depth > 0) { - struct commit_list *result = NULL, *backup = NULL; - int i; - if (depth == INFINITE_DEPTH && !is_repository_shallow()) - for (i = 0; i < shallows.nr; i++) { - struct object *object = shallows.objects[i].item; - object->flags |= NOT_SHALLOW; - } - else - backup = result = - get_shallow_commits(&want_obj, depth, - SHALLOW, NOT_SHALLOW); - while (result) { - struct object *object = &result->item->object; - if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) { - packet_write(1, "shallow %s", - sha1_to_hex(object->sha1)); - register_shallow(object->sha1); - shallow_nr++; - } - result = result->next; - } - free_commit_list(backup); - for (i = 0; i < shallows.nr; i++) { - struct object *object = shallows.objects[i].item; - if (object->flags & NOT_SHALLOW) { - struct commit_list *parents; - packet_write(1, "unshallow %s", - sha1_to_hex(object->sha1)); - object->flags &= ~CLIENT_SHALLOW; - /* make sure the real parents are parsed */ - unregister_shallow(object->sha1); - object->parsed = 0; - parse_commit_or_die((struct commit *)object); - parents = ((struct commit *)object)->parents; - while (parents) { - add_object_array(&parents->item->object, - NULL, &want_obj); - parents = parents->next; - } - add_object_array(object, NULL, &extra_edge_obj); - } - /* make sure commit traversal conforms to client */ - register_shallow(object->sha1); - } - packet_flush(1); - } else + if (depth > 0) + deepen(depth, &shallows); + else if (shallows.nr > 0) { int i; for (i = 0; i < shallows.nr; i++) -- 2.3.0.rc1.137.g477eb31 ^ permalink raw reply related [flat|nested] 74+ messages in thread
* [PATCH 2/6] upload-pack: move "shallow" sending code out of deepen() 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 1/6] upload-pack: move shallow deepen code out of receive_needs() Nguyễn Thái Ngọc Duy @ 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 3/6] upload-pack: remove unused variable "backup" Nguyễn Thái Ngọc Duy ` (3 subsequent siblings) 5 siblings, 0 replies; 74+ messages in thread From: Nguyễn Thái Ngọc Duy @ 2015-03-05 10:28 UTC (permalink / raw) To: philipoakley; +Cc: git, Nguyễn Thái Ngọc Duy Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> --- upload-pack.c | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/upload-pack.c b/upload-pack.c index 74f48f9..ea030f3 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -531,6 +531,20 @@ error: } } +static void send_shallow(struct commit_list *result) +{ + while (result) { + struct object *object = &result->item->object; + if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) { + packet_write(1, "shallow %s", + sha1_to_hex(object->sha1)); + register_shallow(object->sha1); + shallow_nr++; + } + result = result->next; + } +} + static void deepen(int depth, const struct object_array *shallows) { struct commit_list *result = NULL, *backup = NULL; @@ -544,16 +558,7 @@ static void deepen(int depth, const struct object_array *shallows) backup = result = get_shallow_commits(&want_obj, depth, SHALLOW, NOT_SHALLOW); - while (result) { - struct object *object = &result->item->object; - if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) { - packet_write(1, "shallow %s", - sha1_to_hex(object->sha1)); - register_shallow(object->sha1); - shallow_nr++; - } - result = result->next; - } + send_shallow(result); free_commit_list(backup); for (i = 0; i < shallows->nr; i++) { struct object *object = shallows->objects[i].item; -- 2.3.0.rc1.137.g477eb31 ^ permalink raw reply related [flat|nested] 74+ messages in thread
* [PATCH 3/6] upload-pack: remove unused variable "backup" 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 1/6] upload-pack: move shallow deepen code out of receive_needs() Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 2/6] upload-pack: move "shallow" sending code out of deepen() Nguyễn Thái Ngọc Duy @ 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 4/6] upload-pack: move "unshallow" sending code out of deepen() Nguyễn Thái Ngọc Duy ` (2 subsequent siblings) 5 siblings, 0 replies; 74+ messages in thread From: Nguyễn Thái Ngọc Duy @ 2015-03-05 10:28 UTC (permalink / raw) To: philipoakley; +Cc: git, Nguyễn Thái Ngọc Duy Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> --- upload-pack.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/upload-pack.c b/upload-pack.c index ea030f3..79f5525 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -547,7 +547,7 @@ static void send_shallow(struct commit_list *result) static void deepen(int depth, const struct object_array *shallows) { - struct commit_list *result = NULL, *backup = NULL; + struct commit_list *result = NULL; int i; if (depth == INFINITE_DEPTH && !is_repository_shallow()) for (i = 0; i < shallows->nr; i++) { @@ -555,11 +555,11 @@ static void deepen(int depth, const struct object_array *shallows) object->flags |= NOT_SHALLOW; } else - backup = result = + result = get_shallow_commits(&want_obj, depth, SHALLOW, NOT_SHALLOW); send_shallow(result); - free_commit_list(backup); + free_commit_list(result); for (i = 0; i < shallows->nr; i++) { struct object *object = shallows->objects[i].item; if (object->flags & NOT_SHALLOW) { -- 2.3.0.rc1.137.g477eb31 ^ permalink raw reply related [flat|nested] 74+ messages in thread
* [PATCH 4/6] upload-pack: move "unshallow" sending code out of deepen() 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy ` (2 preceding siblings ...) 2015-03-05 10:28 ` [PATCH 3/6] upload-pack: remove unused variable "backup" Nguyễn Thái Ngọc Duy @ 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 5/6] shallow.c: implement a generic shallow boundary finder based on rev-list Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 6/6] upload-pack: example code to use get_shallow_commits_by_rev_list Nguyễn Thái Ngọc Duy 5 siblings, 0 replies; 74+ messages in thread From: Nguyễn Thái Ngọc Duy @ 2015-03-05 10:28 UTC (permalink / raw) To: philipoakley; +Cc: git, Nguyễn Thái Ngọc Duy Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> --- upload-pack.c | 33 ++++++++++++++++++++------------- 1 file changed, 20 insertions(+), 13 deletions(-) diff --git a/upload-pack.c b/upload-pack.c index 79f5525..69a3828 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -545,21 +545,10 @@ static void send_shallow(struct commit_list *result) } } -static void deepen(int depth, const struct object_array *shallows) +static void send_unshallow(const struct object_array *shallows) { - struct commit_list *result = NULL; int i; - if (depth == INFINITE_DEPTH && !is_repository_shallow()) - for (i = 0; i < shallows->nr; i++) { - struct object *object = shallows->objects[i].item; - object->flags |= NOT_SHALLOW; - } - else - result = - get_shallow_commits(&want_obj, depth, - SHALLOW, NOT_SHALLOW); - send_shallow(result); - free_commit_list(result); + for (i = 0; i < shallows->nr; i++) { struct object *object = shallows->objects[i].item; if (object->flags & NOT_SHALLOW) { @@ -582,6 +571,24 @@ static void deepen(int depth, const struct object_array *shallows) /* make sure commit traversal conforms to client */ register_shallow(object->sha1); } +} + +static void deepen(int depth, const struct object_array *shallows) +{ + struct commit_list *result = NULL; + int i; + if (depth == INFINITE_DEPTH && !is_repository_shallow()) + for (i = 0; i < shallows->nr; i++) { + struct object *object = shallows->objects[i].item; + object->flags |= NOT_SHALLOW; + } + else + result = + get_shallow_commits(&want_obj, depth, + SHALLOW, NOT_SHALLOW); + send_shallow(result); + free_commit_list(result); + send_unshallow(shallows); packet_flush(1); } -- 2.3.0.rc1.137.g477eb31 ^ permalink raw reply related [flat|nested] 74+ messages in thread
* [PATCH 5/6] shallow.c: implement a generic shallow boundary finder based on rev-list 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy ` (3 preceding siblings ...) 2015-03-05 10:28 ` [PATCH 4/6] upload-pack: move "unshallow" sending code out of deepen() Nguyễn Thái Ngọc Duy @ 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 6/6] upload-pack: example code to use get_shallow_commits_by_rev_list Nguyễn Thái Ngọc Duy 5 siblings, 0 replies; 74+ messages in thread From: Nguyễn Thái Ngọc Duy @ 2015-03-05 10:28 UTC (permalink / raw) To: philipoakley; +Cc: git, Nguyễn Thái Ngọc Duy Instead of a custom commit walker like get_shallow_commits(), this new function uses rev-list to mark SHALLOW to all reachable commits. The definition of reachable is to be defined by the protocol later. This makes it more flexible to define shallow boundary. Note: if a commit has one not_shallow parent and one shallow parent, then it's considered the boundary. Which means in the client side, this commit has _no_ parents. This could lead to surprising cuts if we're not careful. Another option is to include more commits and only mark commits whose all parents are not-shallow as boundary. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> --- commit.h | 2 ++ shallow.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 67 insertions(+) diff --git a/commit.h b/commit.h index 9f189cb..5c80eea 100644 --- a/commit.h +++ b/commit.h @@ -254,6 +254,8 @@ extern int for_each_commit_graft(each_commit_graft_fn, void *); extern int is_repository_shallow(void); extern struct commit_list *get_shallow_commits(struct object_array *heads, int depth, int shallow_flag, int not_shallow_flag); +extern struct commit_list *get_shallow_commits_by_rev_list( + int ac, const char **av, int shallow_flag, int not_shallow_flag); extern void set_alternate_shallow_file(const char *path, int override); extern int write_shallow_commits(struct strbuf *out, int use_pack_protocol, const struct sha1_array *extra); diff --git a/shallow.c b/shallow.c index d8bf40a..1db2768 100644 --- a/shallow.c +++ b/shallow.c @@ -10,6 +10,8 @@ #include "revision.h" #include "commit-slab.h" #include "sigchain.h" +#include "revision.h" +#include "list-objects.h" static int is_shallow = -1; static struct stat_validity shallow_stat; @@ -137,6 +139,69 @@ struct commit_list *get_shallow_commits(struct object_array *heads, int depth, return result; } +static void show_commit(struct commit *commit, void *data) +{ + commit->object.flags |= *(int *)data; +} + +struct commit_list *get_shallow_commits_by_rev_list(int ac, const char **av, + int shallow_flag, int not_shallow_flag) +{ + struct commit_list *result = NULL; + struct rev_info revs; + unsigned int i, nr; + + /* + * SHALLOW and NOT_SHALLOW should not be set at this + * point. But better be safe than sorry. + */ + nr = get_max_object_index(); + for (i = 0; i < nr; i++) { + struct object *o = get_indexed_object(i); + o->flags &= ~(shallow_flag | not_shallow_flag); + } + + is_repository_shallow(); /* make sure shallows are read */ + + init_revisions(&revs, NULL); + save_commit_buffer = 0; + setup_revisions(ac, av, &revs, NULL); + + /* mark all reachable commits as SHALLOW */ + if (prepare_revision_walk(&revs)) + die("revision walk setup failed"); + traverse_commit_list(&revs, show_commit, NULL, &shallow_flag); + + nr = get_max_object_index(); + for (i = 0; i < nr; i++) { + struct object *o = get_indexed_object(i); + struct commit *c = (struct commit *)o; + struct commit_list *p; + int parent_is_not_shallow = 0; + + if (o->type != OBJ_COMMIT || !(o->flags & shallow_flag)) + continue; + + if (parse_commit(c)) + die("unable to parse commit %s", + sha1_to_hex(c->object.sha1)); + + for (p = c->parents; p; p = p->next) { + if (p->item->object.flags & shallow_flag) + continue; + parent_is_not_shallow = 1; + if (p->item->object.flags & not_shallow_flag) + continue; + p->item->object.flags |= not_shallow_flag; + commit_list_insert(p->item, &result); + } + + if (parent_is_not_shallow) + commit_list_insert(c, &result); + } + return result; +} + static void check_shallow_file_for_update(void) { if (is_shallow == -1) -- 2.3.0.rc1.137.g477eb31 ^ permalink raw reply related [flat|nested] 74+ messages in thread
* [PATCH 6/6] upload-pack: example code to use get_shallow_commits_by_rev_list 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy ` (4 preceding siblings ...) 2015-03-05 10:28 ` [PATCH 5/6] shallow.c: implement a generic shallow boundary finder based on rev-list Nguyễn Thái Ngọc Duy @ 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy 5 siblings, 0 replies; 74+ messages in thread From: Nguyễn Thái Ngọc Duy @ 2015-03-05 10:28 UTC (permalink / raw) To: philipoakley; +Cc: git, Nguyễn Thái Ngọc Duy Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> --- upload-pack.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/upload-pack.c b/upload-pack.c index 69a3828..e616e19 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -592,6 +592,18 @@ static void deepen(int depth, const struct object_array *shallows) packet_flush(1); } +static void deepen_by_rev_list(int ac, const char **av, + struct object_array *shallows) +{ + struct commit_list *result; + + result = get_shallow_commits_by_rev_list(ac, av, SHALLOW, NOT_SHALLOW); + send_shallow(result); + free_commit_list(result); + send_unshallow(shallows); + packet_flush(1); +} + static void receive_needs(void) { struct object_array shallows = OBJECT_ARRAY_INIT; @@ -686,6 +698,12 @@ static void receive_needs(void) return; if (depth > 0) deepen(depth, &shallows); +#if 0 + else if (since_is_specified) { + /* prepare ac, av */ + deepen_by_rev_list(ac, av, &shallows); + } +#endif else if (shallows.nr > 0) { int i; -- 2.3.0.rc1.137.g477eb31 ^ permalink raw reply related [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-18 19:14 [RFH] GSoC 2015 application Jeff King ` (4 preceding siblings ...) 2015-02-20 5:35 ` [RFH] GSoC 2015 application Michael Haggerty @ 2015-02-26 13:10 ` Duy Nguyen 2015-03-04 10:31 ` Jeff King 5 siblings, 1 reply; 74+ messages in thread From: Duy Nguyen @ 2015-02-26 13:10 UTC (permalink / raw) To: Jeff King; +Cc: Git Mailing List On Thu, Feb 19, 2015 at 2:14 AM, Jeff King <peff@peff.net> wrote: > Where I really need help now is in the "ideas" page: > > http://git.github.io/SoC-2015-Ideas.html Is this too ambitious for a summer? I suspect the answer is yes, but anyway.. Due to http limitations and stateless decision, a lot of data is sent back and forth during have/want negotiation for smart-http. I wonder if we could implement the "long polling" scheme in a CGI program. The program terminates HTTP requests and recreates a full duplex connection for upload-pack to talk to the client. upload-pack falls back to the normal mode, used by git:// and ssh://. An example of this is BOSH [1]. From a quick glance it does not seem to require any special thing, so it's unlikely to cause problems with firewalls, proxies.. If this is implemented as cgi (instead of http server), we'll need to save session infos somewhere. I suppose shm with proper locking is enough. [1] http://xmpp.org/extensions/xep-0124.html -- Duy ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-02-26 13:10 ` [RFH] GSoC 2015 application Duy Nguyen @ 2015-03-04 10:31 ` Jeff King 2015-03-04 11:21 ` Duy Nguyen 0 siblings, 1 reply; 74+ messages in thread From: Jeff King @ 2015-03-04 10:31 UTC (permalink / raw) To: Duy Nguyen; +Cc: Git Mailing List On Thu, Feb 26, 2015 at 08:10:38PM +0700, Duy Nguyen wrote: > On Thu, Feb 19, 2015 at 2:14 AM, Jeff King <peff@peff.net> wrote: > > Where I really need help now is in the "ideas" page: > > > > http://git.github.io/SoC-2015-Ideas.html > > Is this too ambitious for a summer? I suspect the answer is yes, but anyway.. > > Due to http limitations and stateless decision, a lot of data is sent > back and forth during have/want negotiation for smart-http. I wonder > if we could implement the "long polling" scheme in a CGI program. The > program terminates HTTP requests and recreates a full duplex > connection for upload-pack to talk to the client. upload-pack falls > back to the normal mode, used by git:// and ssh://. So basically Git-over-TCP-over-HTTP? :) That would be a nice thing to have, though looking over the BOSH link (which this is my first exposure to), it does look rather complicated. It's not clear to me how easily one could plug in an existing tunneling solution, and just stick git programs at the endpoints (in other words, let that solution manage all of the connection state and just present a socketpair() to git). I'm not sure it is too ambitious in terms of actual implementation time, but I think the design work may exceed what most students are capable of. -Peff ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFH] GSoC 2015 application 2015-03-04 10:31 ` Jeff King @ 2015-03-04 11:21 ` Duy Nguyen 0 siblings, 0 replies; 74+ messages in thread From: Duy Nguyen @ 2015-03-04 11:21 UTC (permalink / raw) To: Jeff King; +Cc: Git Mailing List On Wed, Mar 4, 2015 at 5:31 PM, Jeff King <peff@peff.net> wrote: > On Thu, Feb 26, 2015 at 08:10:38PM +0700, Duy Nguyen wrote: > >> On Thu, Feb 19, 2015 at 2:14 AM, Jeff King <peff@peff.net> wrote: >> > Where I really need help now is in the "ideas" page: >> > >> > http://git.github.io/SoC-2015-Ideas.html >> >> Is this too ambitious for a summer? I suspect the answer is yes, but anyway.. >> >> Due to http limitations and stateless decision, a lot of data is sent >> back and forth during have/want negotiation for smart-http. I wonder >> if we could implement the "long polling" scheme in a CGI program. The >> program terminates HTTP requests and recreates a full duplex >> connection for upload-pack to talk to the client. upload-pack falls >> back to the normal mode, used by git:// and ssh://. > > So basically Git-over-TCP-over-HTTP? :) Yes. The hidden agenda was, if it works well, we might be able to deprecate smart-http one day. That day, if happens, would be in far future though. By that time hopefully we could just use http2 insteadof tcp-over-http1. > I'm not sure it is too ambitious in terms of actual implementation time, > but I think the design work may exceed what most students are capable > of. Not to mention that I think it can be man-in-the-middle attacked if we're not careful (e.g. send to session token in unencrypted). Which makes it less appealing to me. -- Duy ^ permalink raw reply [flat|nested] 74+ messages in thread
end of thread, other threads:[~2015-03-10 10:16 UTC | newest] Thread overview: 74+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-02-18 19:14 [RFH] GSoC 2015 application Jeff King 2015-02-18 19:32 ` Jeff King 2015-02-24 12:01 ` Johannes Schindelin 2015-02-24 12:06 ` [msysGit] " Jeff King 2015-02-24 12:25 ` Johannes Schindelin 2015-02-24 12:28 ` [msysGit] " Jeff King 2015-02-25 9:25 ` Johannes Schindelin 2015-02-25 9:39 ` Matthieu Moy 2015-02-25 10:25 ` Matthieu Moy 2015-02-25 12:15 ` Johannes Schindelin 2015-02-24 17:32 ` Matthieu Moy 2015-02-24 18:25 ` Junio C Hamano 2015-02-24 20:33 ` Johannes Schindelin 2015-02-24 21:02 ` Junio C Hamano 2015-02-24 23:56 ` Matthieu Moy 2015-02-25 0:34 ` [msysGit] " Stefan Beller 2015-02-25 9:25 ` Michael J Gruber 2015-02-25 8:44 ` Johannes Schindelin 2015-02-25 10:04 ` [msysGit] " Christian Couder 2015-02-25 10:02 ` Duy Nguyen 2015-02-25 12:10 ` Johannes Schindelin 2015-02-18 21:54 ` Junio C Hamano 2015-02-19 5:49 ` Junio C Hamano 2015-02-19 10:32 ` Matthieu Moy 2015-02-20 2:00 ` Jeff King 2015-02-20 10:06 ` Matthieu Moy 2015-02-20 10:22 ` Dennis Kaarsemaker 2015-02-20 10:34 ` Matthieu Moy 2015-02-20 23:06 ` Eric Sunshine 2015-02-20 10:31 ` [PATCH 1/3] microprojects: tweaks after discussion with Peff Matthieu Moy 2015-02-20 10:31 ` [PATCH 2/3] GSoC ideas: git bisect fixed/unfixed Matthieu Moy 2015-02-20 10:31 ` [PATCH 3/3] idea: Be nicer to the user on tracked/untracked merge conflicts Matthieu Moy 2015-02-20 3:26 ` [RFH] GSoC 2015 application Duy Nguyen 2015-02-20 7:13 ` Jeff King 2015-02-20 8:26 ` Junio C Hamano 2015-02-21 3:02 ` Support customized reordering in version sort Duy Nguyen 2015-02-21 3:25 ` Junio C Hamano 2015-02-21 3:33 ` Duy Nguyen 2015-02-21 5:12 ` Junio C Hamano 2015-02-21 5:37 ` Junio C Hamano 2015-02-26 10:44 ` [PATCH] versionsort: support reorder prerelease suffixes Nguyễn Thái Ngọc Duy 2015-02-27 21:37 ` Junio C Hamano 2015-03-05 1:28 ` Junio C Hamano 2015-03-09 1:01 ` Duy Nguyen 2015-03-10 7:52 ` Junio C Hamano 2015-03-10 8:03 ` Eric Sunshine 2015-03-10 10:16 ` [PATCH] config.txt: update versioncmp.prereleaseSuffix Nguyễn Thái Ngọc Duy 2015-02-20 5:35 ` [RFH] GSoC 2015 application Michael Haggerty 2015-02-20 7:29 ` Jeff King 2015-02-20 8:06 ` Junio C Hamano 2015-02-20 9:39 ` Matthieu Moy 2015-02-20 9:48 ` Jeff King 2015-02-20 11:35 ` Jeff King 2015-02-23 8:02 ` Matthieu Moy 2015-02-23 15:36 ` Jeff King 2015-03-04 22:05 ` Philip Oakley 2015-03-04 23:55 ` Stefan Beller 2015-03-05 0:17 ` Philip Oakley 2015-03-05 0:22 ` Junio C Hamano 2015-03-05 0:32 ` Stefan Beller 2015-03-05 1:17 ` Junio C Hamano 2015-03-05 6:19 ` Junio C Hamano 2015-03-06 11:24 ` Duy Nguyen 2015-03-05 0:26 ` Duy Nguyen 2015-03-05 10:28 ` Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 1/6] upload-pack: move shallow deepen code out of receive_needs() Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 2/6] upload-pack: move "shallow" sending code out of deepen() Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 3/6] upload-pack: remove unused variable "backup" Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 4/6] upload-pack: move "unshallow" sending code out of deepen() Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 5/6] shallow.c: implement a generic shallow boundary finder based on rev-list Nguyễn Thái Ngọc Duy 2015-03-05 10:28 ` [PATCH 6/6] upload-pack: example code to use get_shallow_commits_by_rev_list Nguyễn Thái Ngọc Duy 2015-02-26 13:10 ` [RFH] GSoC 2015 application Duy Nguyen 2015-03-04 10:31 ` Jeff King 2015-03-04 11:21 ` Duy Nguyen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.