Re: [RFH] GSoC 2015 application
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 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=:: + Deepen or shorten the history of a 'shallow' repository to + include all reachable commits that are after . + +--not=:: + 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=:: + Create a 'shallow' clone with a history after the specified time. + +--not=:: + 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=" 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 " on the server side. "deepen-not" +cannot be used with "deepen", but can be used with "deepen-since". + no-progress --- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
On Thu, Mar 5, 2015 at 5:05 AM, Philip Oakley 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 ...' > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
Stefan Beller writes: > I cannot remember the usual option off hand to describe the revision > instead of a date. Because "log --since= 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
Stefan Beller writes: > On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano wrote: >> On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley wrote: git clone --since 2.weeks.ago git clone --since v2.10 >>> >>> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano wrote: > On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley wrote: >>> >>>git clone --since 2.weeks.ago >>>git clone --since v2.10 >> >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
On Thu, Mar 5, 2015 at 6:55 AM, Stefan Beller wrote: > On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley wrote: > >> A possible idea is to add a date based variant of shallow clone : >> >> 'git clone --date ...' >> >> 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 > git clone --since v2.10 > git clone --since c0ffee^^ > > would all equally work? Yes, and we could generalize it further: add shallow-rev-list capability and send "shallow-rev-list " 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley wrote: >> >>git clone --since 2.weeks.ago >>git clone --since v2.10 > > 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
From: "Stefan Beller" On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley wrote: A possible idea is to add a date based variant of shallow clone : 'git clone --date ...' 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 git clone --since v2.10 git clone --since c0ffee^^ 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 ) 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley wrote: > A possible idea is to add a date based variant of shallow clone : > > 'git clone --date ...' > > 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 git clone --since v2.10 git clone --since c0ffee^^ 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) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
From: "Matthieu Moy" Sent: Friday, February 20, 2015 9:39 AM Jeff King 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 ...' 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 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 ' to remove 'old' commits that the user may no longer need locally. (unshallow may not be the right term...) -- Philip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
On Wed, Mar 4, 2015 at 5:31 PM, Jeff King 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 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
On Thu, Feb 26, 2015 at 08:10:38PM +0700, Duy Nguyen wrote: > On Thu, Feb 19, 2015 at 2:14 AM, Jeff King 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
On Thu, Feb 19, 2015 at 2:14 AM, Jeff King 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Hi Duy, On 2015-02-25 11:02, Duy Nguyen wrote: > On Wed, Feb 25, 2015 at 6:56 AM, Matthieu Moy > wrote: >> To get an idea, I counted the lines of code written by the student I >> mentored last year: >> >> $ git log --author tanay...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
- 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
On Wed, Feb 25, 2015 at 9:44 AM, Johannes Schindelin wrote: > Hi Matthieu, > > On 2015-02-25 00:56, Matthieu Moy wrote: >> Johannes Schindelin writes: >> >>> On 2015-02-24 19:25, Junio C Hamano wrote: On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy 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 tanay...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
On Wed, Feb 25, 2015 at 6:56 AM, Matthieu Moy wrote: > To get an idea, I counted the lines of code written by the student I > mentored last year: > > $ git log --author tanay...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Johannes Schindelin 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Stefan Beller venit, vidit, dixit 25.02.2015 01:34: > On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy > wrote: >> Johannes Schindelin writes: >> >>> Hi Junio, >>> >>> On 2015-02-24 19:25, Junio C Hamano wrote: On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy 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 tanay...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Hi Matthieu, On 2015-02-25 00:56, Matthieu Moy wrote: > Johannes Schindelin writes: > >> On 2015-02-24 19:25, Junio C Hamano wrote: >>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy >>> 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 tanay...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy wrote: > Johannes Schindelin writes: > >> Hi Junio, >> >> On 2015-02-24 19:25, Junio C Hamano wrote: >>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy >>> 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 tanay...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Johannes Schindelin writes: > Hi Junio, > > On 2015-02-24 19:25, Junio C Hamano wrote: >> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy >> 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 tanay...@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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
Johannes Schindelin 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 ;-). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Hi Junio, On 2015-02-24 19:25, Junio C Hamano wrote: > On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy 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 ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
Johannes Schindelin 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [RFH] GSoC 2015 application
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
Jeff King 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
On Fri, Feb 20, 2015 at 5:06 AM, Matthieu Moy wrote: > Jeff King 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
Dennis Kaarsemaker 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 ~/. 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
Jeff King 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 >> +~/. or in ~/.config/git/, following the [XDG >> +standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). >> +~/.git-credentials and ~/.git-credential-cache are still hardcoded as >> +~/., 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
On Fri, Feb 20, 2015 at 10:39:42AM +0100, Matthieu Moy wrote: > Jeff King 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
Jeff King 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
On Thu, Feb 19, 2015 at 11:13 PM, Jeff King 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 ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
On Thu, Feb 19, 2015 at 11:29 PM, Jeff King 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
On Fri, Feb 20, 2015 at 10:26:15AM +0700, Duy Nguyen wrote: > On Thu, Feb 19, 2015 at 2:14 AM, Jeff King 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
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 mhag...@alum.mit.edu -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
On Thu, Feb 19, 2015 at 2:14 AM, Jeff King 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
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 > +~/. or in ~/.config/git/, following the [XDG > +standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). > +~/.git-credentials and ~/.git-credential-cache are still hardcoded as > +~/., 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
Jeff King 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 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 +~/. or in ~/.config/git/, following the [XDG +standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html). +~/.git-credentials and ~/.git-credential-cache are still hardcoded as +~/., 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 expressio
Re: [RFH] GSoC 2015 application
On Wed, Feb 18, 2015 at 1:54 PM, Junio C Hamano 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
Jeff King 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 + -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] GSoC 2015 application
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html