{"thread":{"id":"35808","subject":"[RFH] hackday and GSoC topic suggestions","startedAt":"2014-02-05T22:57:02Z","lastAt":"2014-02-16T15:29:41Z","messageCount":15,"participants":["Jeff King","Christian Couder","Matthieu Moy","Thomas Rast","Junio C Hamano","David Kastrup","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"234345","messageId":"20140205225702.GA12589@sigill.intra.peff.net","threadId":"35808","inReplyTo":null,"subject":"[RFH] hackday and GSoC topic suggestions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-05T22:57:02Z","receivedAt":"2014-02-05T22:57:02Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"This Saturday I'm going to be attending a Git hackday held by Bloomberg\nin New York. The participants will be eager C coders who have experience\nusing git, but not contributing to it. As somebody who has read The\nMythical Man Month, I don't expect huge productivity, but I'm hoping to\ndo some bug triage and fixes, and maybe get some people involved who\nmight join the community. I'm hoping some of the folks will have\nfeatures _they_ want to work on, and I can help get them started. But\nI'd like to have a list of potential projects to direct people towards\nas a backup.\n\nOn a similar note, the GSoC application deadline is Feb 14th. I am\nhappy to be admin again and put together the application, but we will\nneed an idea page. I'll set up a page to collect them, but in the\nmeantime, please dump any ideas/discussion in this thread.\n\nBelow is a list of features / bugs that I am taking to the hackday. The\nbug list was collected by grepping the mailing list for items without\nresponses. They haven't been triaged at all, so I'm sure some of them\nare \"not a bug\" or \"won't fix\".  But the triage process is part of what\nwe'll be doing on Saturday.\n\nI don't think the list below and the potential GSoC list really have any\noverlap, as the project scales are completely different. But I'd be\nhappy to take suggestions for either.\n\n---\nfeatures:\n\n - negative refspecs\n   http://thread.gmane.org/gmane.comp.version-control.git/240997/focus=241019\n\n - optionally remove tempfiles on failed pack-objects (especially when\n   we get ENOSPC)\n   http://article.gmane.org/gmane.comp.version-control.git/241466\n\n - previewing \"git pull\"\n   http://article.gmane.org/gmane.comp.version-control.git/236732\n\nbugs:\n\n - branch.*.merge interpreted too strictly by tracking logic\n   http://article.gmane.org/gmane.comp.version-control.git/241582\n\n - relative core.worktree is resolved from symlink and not its target\n   http://article.gmane.org/gmane.comp.version-control.git/241519\n\n - Branch rename breaks local downstream branches\n   http://article.gmane.org/gmane.comp.version-control.git/241228\n\n - git clone on out-of-space device causes incorrect errors\n   http://article.gmane.org/gmane.comp.version-control.git/241206\n\n - commit-msg hook and merges\n   http://article.gmane.org/gmane.comp.version-control.git/241203\n\n - inconsistent include behaviour for core.sharedRepository\n   http://article.gmane.org/gmane.comp.version-control.git/241277\n\n - Rebase options '--whitespace=fix' and '--keep-empty' are incompatible\n   http://article.gmane.org/gmane.comp.version-control.git/238055\n\n - git stash doesn't use --index as default\n   http://article.gmane.org/gmane.comp.version-control.git/235892\n\n - git describe --contains --abbrev=0 <sha1> doesn't work as expected\n   http://article.gmane.org/gmane.comp.version-control.git/236707\n\n - using git commit-tree with \"-F -\" adds trailing newlines\n   http://article.gmane.org/gmane.comp.version-control.git/236583\n\n - Pull and fetch don't honor `--progress` flag\n   http://thread.gmane.org/gmane.comp.version-control.git/236257/focus=236262\n\n - Unexpected outputs of git pull on stdout v.s. stderr\n   http://article.gmane.org/gmane.comp.version-control.git/235716\n\n - MERGE_HEAD lost with git checkout master\n   http://article.gmane.org/gmane.comp.version-control.git/233806\n\n - git stash doesn't always save work dir as-is: bug?\n   http://article.gmane.org/gmane.comp.version-control.git/234153\n\n - Well-past commit dates unsupported\n   http://article.gmane.org/gmane.comp.version-control.git/236827\n\n - we do not handle integer overflow in commit/author timestamps\n   [no reference, but something I have noticed; we should probably\n   return a sentinel \"0\" rather than a random overflow value, and\n   we should probably detect and warn in git-fsck]\n\n - git stash does not work when directory is replaced by a symlink to itself\n   http://article.gmane.org/gmane.comp.version-control.git/236798\n\n - rebase not recovering gracefully from repack error\n   http://article.gmane.org/gmane.comp.version-control.git/234261\n\n - (broken ?) output of \"git diff --color-word\"\n   http://article.gmane.org/gmane.comp.version-control.git/237370\n\n - git filter-branch does not make tree replacements permanent\n   http://article.gmane.org/gmane.comp.version-control.git/220931\n\n - 'git show' gives duplicate errors for ambiguous args\n   http://article.gmane.org/gmane.comp.version-control.git/205023\n\n - (git commit --patch --message $MESSAGE) disallows hunk editing\n   http://article.gmane.org/gmane.comp.version-control.git/208213\n\n - filter-branch --parent-filter in bare repository\n   http://article.gmane.org/gmane.comp.version-control.git/203619\n\ninsanely hard bugs:\n\n - shallow clones over http\n   http://article.gmane.org/gmane.comp.version-control.git/223682\n"},{"id":"234357","messageId":"CAP8UFD1B+108EyyhFQh6RnVVpOUCLiK+oNPONrNJqkNftLFYLA@mail.gmail.com","threadId":"35808","inReplyTo":"20140205225702.GA12589@sigill.intra.peff.net","subject":"Re: [RFH] hackday and GSoC topic suggestions","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2014-02-06T09:10:05Z","receivedAt":"2014-02-06T09:10:05Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wed, Feb 5, 2014 at 11:57 PM, Jeff King <peff@peff.net> wrote:\n>\n> On a similar note, the GSoC application deadline is Feb 14th. I am\n> happy to be admin again and put together the application, but we will\n> need an idea page. I'll set up a page to collect them, but in the\n> meantime, please dump any ideas/discussion in this thread.\n\nMatthieu Moy created this nice page some time ago in the wiki:\n\nhttps://git.wiki.kernel.org/index.php/SmallProjectsIdeas\n\nand I think there is good stuff in it.\n\nI would be interested in mentoring a GSoC student working on the \"git\nbisect fix/unfixed\" feature.\nSome of Matthieu's students worked on it a few years ago but didn't finish.\n\nThanks,\nChristian.\n"},{"id":"234358","messageId":"vpqr47gin5x.fsf@anie.imag.fr","threadId":"35808","inReplyTo":"CAP8UFD1B+108EyyhFQh6RnVVpOUCLiK+oNPONrNJqkNftLFYLA@mail.gmail.com","subject":"Re: [RFH] hackday and GSoC topic suggestions","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-02-06T09:51:54Z","receivedAt":"2014-02-06T09:51:54Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Christian Couder <christian.couder@gmail.com> writes:\n\n> I would be interested in mentoring a GSoC student working on the \"git\n> bisect fix/unfixed\" feature.\n\nInterestingly, I used the feature in real-life last week, and had to\nthink upside-down to type the right \"good\"/\"bad\" keywords ;-).\n\n> Some of Matthieu's students worked on it a few years ago but didn't finish.\n\nRight. There was still quite some work to do, but this is most likely\ntoo small for a GSoC project. But that could be a part of it. I'm not\nsure how google welcomes GSoC projects made of multiple small tasks, but\nmy experience with students is that it's much better than a single (too)\nbig task, and I think that was the general feeling on this list when we\ndiscussed it last year.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"234512","messageId":"8738jtmomb.fsf@thomasrast.ch","threadId":"35808","inReplyTo":"20140205225702.GA12589@sigill.intra.peff.net","subject":"Re: [RFH] hackday and GSoC topic suggestions","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2014-02-08T18:43:40Z","receivedAt":"2014-02-08T18:43:40Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On a similar note, the GSoC application deadline is Feb 14th. I am\n> happy to be admin again and put together the application, but we will\n> need an idea page. I'll set up a page to collect them, but in the\n> meantime, please dump any ideas/discussion in this thread.\n\nSorry for being so procrastinative :-(\n\nI suggest we make it a rule that old projects cannot be proposed from\nyear to year.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"234513","messageId":"20140208185519.GA26306@sigill.intra.peff.net","threadId":"35808","inReplyTo":"8738jtmomb.fsf@thomasrast.ch","subject":"Re: [RFH] hackday and GSoC topic suggestions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-08T18:55:20Z","receivedAt":"2014-02-08T18:55:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Feb 08, 2014 at 07:43:40PM +0100, Thomas Rast wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > On a similar note, the GSoC application deadline is Feb 14th. I am\n> > happy to be admin again and put together the application, but we will\n> > need an idea page. I'll set up a page to collect them, but in the\n> > meantime, please dump any ideas/discussion in this thread.\n> \n> Sorry for being so procrastinative :-(\n> \n> I suggest we make it a rule that old projects cannot be proposed from\n> year to year.\n\nI would very much agree with that. There are projects that I have posted\nmultiple years, and nobody ever selects them. I should take that as a\nhint that they are not appealing to students for whatever reason, and\nare probably just clogging up the ideas list.\n\nI'd make an exception for somebody who wants to substantially rework the\nproposal in an attempt to make it more appealing, or who has a reason\nwhy it is being re-proposed (e.g., we had student interest, but we ended\nup not selecting it due to running out of slots or something). But those\nshould be the exception.\n\n-Peff\n"},{"id":"234515","messageId":"87mwi1l95l.fsf@thomasrast.ch","threadId":"35808","inReplyTo":"20140205225702.GA12589@sigill.intra.peff.net","subject":"Re: [RFH] hackday and GSoC topic suggestions","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2014-02-08T19:03:02Z","receivedAt":"2014-02-08T19:03:02Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Below is a list of features / bugs that I am taking to the hackday.\n\nI have the list below at\n\n  https://github.com/trast/git/wiki/Todo-items\n\n(started at git-merge last year).  I did a quick triage, but don't take\nmy word for it.  Perhaps it's not too late for your hackathon yet ;-)\n\nSome items may have been fixed by other people when I wasn't looking, so\nfirst check if the problem still exists.  The ones I knew are done I\nmoved to the bottom.\n\n\nEasy:\n\n* Add -p 'e' when it fails to apply should offer an obvious way of\n  starting from the original hunk (not the broken one) or both\n\n* filter-branch should apply {tree,index}-filter to HEAD and complain if\n  it's not invariant (cf. BFG)\n\n* git-config should follow symlinks when rewriting the file, so as to\n  avoid replacing a symlink at ~/.gitconfig with the actual contents\n\n* git-send-email should complain when given an option --cc= (i.e., --cc\n  with empty argument) instead of silently not using any address\n  there. It's easy to accidentally cause this in combination with\n  $()-expanding a script that searches for the address by name when\n  there are no matches. Note that the cccmd feature should not error if\n  it doesn't come up with anything!\n\n\nMedium difficulty:  \n  \n* LC_CTYPE=C to work around an old issue in glibc that has since been\n  fixed (ask jrn). We should autodetect if we still need the fix, and\n  otherwise avoid it; it causes trouble with localized messages\n\n* rebase -i --exec should be able to work elsewhere so you can continue\n  doing useful work\n\n* git-send-email could build smarter reference lists if it had\n  strategies to fetch the in-reply-to email. One obvious, and very\n  useful for git and linux, strategy to do so would be to append the\n  References header of the mail obtained from\n  http://mid.gmane.org/$in_reply_to (follow the 403 and then append /raw\n  to get the headers).\n\n* git-svn should have a diff subcommand, to match svn's output for\n  feeding into tools that need the precise format with 'Index:' lines\n\n* Resurrect the move of config var descriptions onto the separate pages\n  for commands\n\n  \nHard or unknown difficulty:\n \n* Add -p 's' followed by 'e' fails to apply even a no-op edit if the\n  context is small\n\n* git-bisect appears to test a linear number of merge bases, thus\n  ruining its usually log(n) complexity, in cases involving 'git bisect\n  good origin/next', 'git bisect bad origin/pu', in git.git\n\n* I have a script git-pie which runs 'perl -i -pe' as follows:\n\n        #!/bin/sh\n        \n        cmd=$1\n        shift\n        \n        git ls-files -z \"$@\" |\n        xargs -0 perl -i -pe \"$cmd\"\n\n  The prompt display (__git_ps1) in the prompt immediately after using\n  'git pie ...' always shows that there are no uncommitted changes, even\n  if that is not correct. Hitting RET again yields a correct status.\n\n\nAlready underway or done (only here so people don't say \"but you dropped\nthis from the wiki list\"):\n\n* In-core merge: a clean merge should be able to work fully in memory,\n  esp. without any worktree\n\n* For the issue of \"what did the evil merge do\", should try to flatten\n  out the conflicted merge (i.e. mechanically re-merge, and scrap the\n  conflicted state in favor of conflict hunks in stage 0) and diff that\n  against the merge result. if that works out, store the tree as a note\n  somewhere for caching; git-notes should be able to handle that\n\n  * For the last point: need a way of storing trees as\n    notes. Technically the notes infrastructure does not require things\n    to be blobs, but in practice all the frontends we have error out, or\n    do worse things, when handed a tree as a note.\n\n* ./t0000-foo.sh --valgrind should be able to: a) run only a single\n  specific test under valgrind, using the normal git for the rest; and\n  b) parallelize over (a) so as to speed up a complete ./t0000-foo.sh\n  --valgrind run\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"234621","messageId":"xmqq1tz9qxyl.fsf@gitster.dls.corp.google.com","threadId":"35808","inReplyTo":"20140205225702.GA12589@sigill.intra.peff.net","subject":"Re: [RFH] hackday and GSoC topic suggestions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-11T18:57:22Z","receivedAt":"2014-02-11T18:57:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>  - Branch rename breaks local downstream branches\n>    http://article.gmane.org/gmane.comp.version-control.git/241228\n\nIf you have a branch B that builds on A, if you are renaming A to C,\nyou may want B to automatically set to build on C in some cases, and\nin other cases your renaming A is done explicitly in order to severe\nthe tie between A and B and setting the latter to build on C can be\na bad thing---after all, the user's intention may be to create a\nbranch A starting at some commit immediately after this rename so\nthat B will keep building on that updated A.\n\nSo I am not sure if this is a bug.\n\n>  - git stash doesn't use --index as default\n>    http://article.gmane.org/gmane.comp.version-control.git/235892\n\nI tend to think \"git stash\" was designed to work this way from day\none.\n\n>  - using git commit-tree with \"-F -\" adds trailing newlines\n>    http://article.gmane.org/gmane.comp.version-control.git/236583\n\nAccording to the initial commit that introduced this option, it\ndeliberately calls strbuf_complete_line() to make sure we do not\nleave an incomplete line at the end.\n\n\nMany of the other items in your \"bugs\" section seem to be worth\nfixing.\n\nThanks.\n"},{"id":"234625","messageId":"xmqqeh39phi6.fsf@gitster.dls.corp.google.com","threadId":"35808","inReplyTo":"xmqq1tz9qxyl.fsf@gitster.dls.corp.google.com","subject":"Re: [RFH] hackday and GSoC topic suggestions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-11T19:38:09Z","receivedAt":"2014-02-11T19:38:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Jeff King <peff@peff.net> writes:\n>\n>>  - Branch rename breaks local downstream branches\n>>    http://article.gmane.org/gmane.comp.version-control.git/241228\n>\n> If you have a branch B that builds on A, if you are renaming A to C,\n> you may want B to automatically set to build on C in some cases, and\n> in other cases your renaming A is done explicitly in order to severe\n> the tie between A and B and setting the latter to build on C can be\n> a bad thing---after all, the user's intention may be to create a\n> branch A starting at some commit immediately after this rename so\n> that B will keep building on that updated A.\n>\n> So I am not sure if this is a bug.\n\nHaving said that, the current behaviour of leaving B half-configured\nto build on a missing branch is undesirable. If we were to change\nthis so that any branch B that used to build on branch A being\nrenamed to build on the branch under the new name C, the user may\nhave to do an extra \"--set-upstream-to A\" on B after recreating A if\nthis was done to save away the current state of A to C and then keep\nbuilding B on an updated A, so we may have to give _some_ clue what\nwe are doing behind their back when we rename, e.g.\n\n\t$ git branch -m A C\n        warning: branch B is set to build on C now.\n\nor something.\n"},{"id":"234714","messageId":"20140213083755.GA28679@sigill.intra.peff.net","threadId":"35808","inReplyTo":"xmqqeh39phi6.fsf@gitster.dls.corp.google.com","subject":"Re: [RFH] hackday and GSoC topic suggestions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-13T08:37:55Z","receivedAt":"2014-02-13T08:37:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 11, 2014 at 11:38:09AM -0800, Junio C Hamano wrote:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n> > Jeff King <peff@peff.net> writes:\n> >\n> >>  - Branch rename breaks local downstream branches\n> >>    http://article.gmane.org/gmane.comp.version-control.git/241228\n> >\n> > If you have a branch B that builds on A, if you are renaming A to C,\n> > you may want B to automatically set to build on C in some cases, and\n> > in other cases your renaming A is done explicitly in order to severe\n> > the tie between A and B and setting the latter to build on C can be\n> > a bad thing---after all, the user's intention may be to create a\n> > branch A starting at some commit immediately after this rename so\n> > that B will keep building on that updated A.\n> >\n> > So I am not sure if this is a bug.\n> \n> Having said that, the current behaviour of leaving B half-configured\n> to build on a missing branch is undesirable. If we were to change\n> this so that any branch B that used to build on branch A being\n> renamed to build on the branch under the new name C, the user may\n> have to do an extra \"--set-upstream-to A\" on B after recreating A if\n> this was done to save away the current state of A to C and then keep\n> building B on an updated A, so we may have to give _some_ clue what\n> we are doing behind their back when we rename, e.g.\n> \n> \t$ git branch -m A C\n>         warning: branch B is set to build on C now.\n> \n> or something.\n\nYeah, I agree. I think most of the time people would want the dependency\nto move with the branch, and the key is being clear about it so the user\ncan override. I don't think there is a problem with overriding with\n`--set-upstream-to` after the fact, rather than giving a special option\nto the move operation.\n\nThere was a team working on this at the hackday, and they seemed to make\nreasonable progress, but I haven't seen the final output yet. Most teams\ndid not finish their projects, or if they did, I didn't get a chance to\ncoach them through the patch submission process. I'll hopefully be\nrevisiting those in the next week or two as they finish them up offline.\n\nMy goal is to get them all posting to the list themselves, but I fear I\nmay have to pick up the pieces in some cases.\n\n-Peff\n"},{"id":"234716","messageId":"20140213084138.GB28679@sigill.intra.peff.net","threadId":"35808","inReplyTo":"xmqq1tz9qxyl.fsf@gitster.dls.corp.google.com","subject":"Re: [RFH] hackday and GSoC topic suggestions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-13T08:41:38Z","receivedAt":"2014-02-13T08:41:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 11, 2014 at 10:57:22AM -0800, Junio C Hamano wrote:\n\n> >  - git stash doesn't use --index as default\n> >    http://article.gmane.org/gmane.comp.version-control.git/235892\n> \n> I tend to think \"git stash\" was designed to work this way from day\n> one.\n\nRight. The thing that bothers me is the data loss of:\n\n  echo 1 >foo\n  git add foo\n  echo 2 >foo\n  git stash\n  git stash pop\n\nThe content in \"1\" is stashed, but gets lost on the apply, and our pop\ndrops the stash.\n\n> >  - using git commit-tree with \"-F -\" adds trailing newlines\n> >    http://article.gmane.org/gmane.comp.version-control.git/236583\n> \n> According to the initial commit that introduced this option, it\n> deliberately calls strbuf_complete_line() to make sure we do not\n> leave an incomplete line at the end.\n\nYeah, I think this one is a non-bug. I hadn't read it carefully but the\n\"trailing newlines\" made me think it was adding multiple extra blank\nlines. But it looks like it is just the normal strbuf_complete_line, and\nthat is the right thing to be doing (it has _never_ been encouraged to\nhave a commit message that does not have a newline at all, and\nI think stripspace has enforced that from day one).\n\n> Many of the other items in your \"bugs\" section seem to be worth\n> fixing.\n\nAs I mentioned elsewhere, I've yet to see the full results of the\nhackday. Hopefully soon. :)\n\n-Peff\n"},{"id":"234718","messageId":"20140213085039.GA29152@sigill.intra.peff.net","threadId":"35808","inReplyTo":"vpqr47gin5x.fsf@anie.imag.fr","subject":"Re: [RFH] hackday and GSoC topic suggestions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-13T08:50:39Z","receivedAt":"2014-02-13T08:50:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 06, 2014 at 10:51:54AM +0100, Matthieu Moy wrote:\n\n> > Some of Matthieu's students worked on it a few years ago but didn't finish.\n> \n> Right. There was still quite some work to do, but this is most likely\n> too small for a GSoC project. But that could be a part of it. I'm not\n> sure how google welcomes GSoC projects made of multiple small tasks, but\n> my experience with students is that it's much better than a single (too)\n> big task, and I think that was the general feeling on this list when we\n> discussed it last year.\n\nI think Google leaves it up to us to decide. I'd be OK with a project\nmade of multiple small tasks, as I think it would be an interesting\nexperiment.  I'd rather not do all of them like that, though. And bonus\npoints if they are on a theme that will let the student use the ramp-up\ntime from one for another.\n\n-Peff\n"},{"id":"234721","messageId":"CAP8UFD3pqW119xjY0Wci7bJ6UL4ZLsT_vYZJ=zMsnK_7C8-_KQ@mail.gmail.com","threadId":"35808","inReplyTo":"20140213085039.GA29152@sigill.intra.peff.net","subject":"Re: [RFH] hackday and GSoC topic suggestions","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2014-02-13T09:28:02Z","receivedAt":"2014-02-13T09:28:02Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Feb 13, 2014 at 9:50 AM, Jeff King <peff@peff.net> wrote:\n> On Thu, Feb 06, 2014 at 10:51:54AM +0100, Matthieu Moy wrote:\n>\n>> > Some of Matthieu's students worked on it a few years ago but didn't finish.\n>>\n>> Right. There was still quite some work to do, but this is most likely\n>> too small for a GSoC project. But that could be a part of it. I'm not\n>> sure how google welcomes GSoC projects made of multiple small tasks, but\n>> my experience with students is that it's much better than a single (too)\n>> big task, and I think that was the general feeling on this list when we\n>> discussed it last year.\n>\n> I think Google leaves it up to us to decide. I'd be OK with a project\n> made of multiple small tasks, as I think it would be an interesting\n> experiment.  I'd rather not do all of them like that, though. And bonus\n> points if they are on a theme that will let the student use the ramp-up\n> time from one for another.\n\nYeah, a student working on the \"git bisect fix/unfixed\" feature, could\nfix git bisect testing too many merge bases, and if there is still\ntime work on moving more code from shell to C.\n"},{"id":"234724","messageId":"87sirn72w9.fsf@fencepost.gnu.org","threadId":"35808","inReplyTo":"CAP8UFD3pqW119xjY0Wci7bJ6UL4ZLsT_vYZJ=zMsnK_7C8-_KQ@mail.gmail.com","subject":"Re: [RFH] hackday and GSoC topic suggestions","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-02-13T09:55:34Z","receivedAt":"2014-02-13T09:55:34Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Christian Couder <christian.couder@gmail.com> writes:\n\n> On Thu, Feb 13, 2014 at 9:50 AM, Jeff King <peff@peff.net> wrote:\n>\n>> I think Google leaves it up to us to decide. I'd be OK with a project\n>> made of multiple small tasks, as I think it would be an interesting\n>> experiment.  I'd rather not do all of them like that, though. And\n>> bonus points if they are on a theme that will let the student use the\n>> ramp-up time from one for another.\n>\n> Yeah, a student working on the \"git bisect fix/unfixed\" feature, could\n> fix git bisect testing too many merge bases, and if there is still\n> time work on moving more code from shell to C.\n\nIn the context of programming tasks, \"if there is still time\" is a prime\ncandidate for the successful application of branch prediction.\n\n-- \nDavid Kastrup\n"},{"id":"234888","messageId":"CACsJy8DMtJBiFX1Jr76QGGk=e=RhDTCge5rabA5ZZrNC5jstVQ@mail.gmail.com","threadId":"35808","inReplyTo":"87mwi1l95l.fsf@thomasrast.ch","subject":"Re: [RFH] hackday and GSoC topic suggestions","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-02-16T14:42:30Z","receivedAt":"2014-02-16T14:42:30Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sun, Feb 9, 2014 at 2:03 AM, Thomas Rast <tr@thomasrast.ch> wrote:\n> Easy:\n>\n> * Add -p 'e' when it fails to apply should offer an obvious way of\n>   starting from the original hunk (not the broken one) or both\n\nIf it's too easy, you can add a command to change diff display\nsettings (--color-words, context size...)\n-- \nDuy\n"},{"id":"234889","messageId":"8761of3wka.fsf@thomasrast.ch","threadId":"35808","inReplyTo":"CACsJy8DMtJBiFX1Jr76QGGk=e=RhDTCge5rabA5ZZrNC5jstVQ@mail.gmail.com","subject":"Re: [RFH] hackday and GSoC topic suggestions","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2014-02-16T15:29:41Z","receivedAt":"2014-02-16T15:29:41Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Duy Nguyen <pclouds@gmail.com> writes:\n\n> On Sun, Feb 9, 2014 at 2:03 AM, Thomas Rast <tr@thomasrast.ch> wrote:\n>> Easy:\n>>\n>> * Add -p 'e' when it fails to apply should offer an obvious way of\n>>   starting from the original hunk (not the broken one) or both\n>\n> If it's too easy, you can add a command to change diff display\n> settings (--color-words, context size...)\n\nIf you mean for GSoC, that violates the \"previously suggested\" rule -- I\nhad it as a project proposal for at least two years and nobody was ever\ninterested.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"}]}