{"thread":{"id":"38704","subject":"Interest in contributing to the Git for GSOC 2015","startedAt":"2015-03-05T00:19:11Z","lastAt":"2015-03-06T21:53:03Z","messageCount":2,"participants":["Amate Yolande","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"257039","messageId":"CAFAMDXYJAaunegAXFoCK8N-CAaoUXpv-WObhnDC5Wdgy_U99OQ@mail.gmail.com","threadId":"38704","inReplyTo":null,"subject":"Interest in contributing to the Git for GSOC 2015","fromName":"Amate Yolande","fromEmail":"yolandeamate@gmail.com","sentAt":"2015-03-05T00:19:11Z","receivedAt":"2015-03-05T00:19:11Z","isPatch":false,"sender":{"key":"yolandeamate@gmail.com","avatar":null},"body":"Hello\n\n        My name is Amate Yolande a first year computer science student\nfrom Cameroon. I would like to participate in the google summer fo\ncode 2015 with the Git community. I have done one of the micro project\nand I hope it gets reviewed soon so I could update it. I would like to\nwork on the Unifying git branch -l, git tag -l, and git for-each-ref\nproject for GSOC 2015 and I hope I can get more directives on how to\nmove on with this project.\n\nThanks\nYolande\n"},{"id":"257201","messageId":"xmqqh9txyerk.fsf@gitster.dls.corp.google.com","threadId":"38704","inReplyTo":"CAFAMDXYJAaunegAXFoCK8N-CAaoUXpv-WObhnDC5Wdgy_U99OQ@mail.gmail.com","subject":"Re: Interest in contributing to the Git for GSOC 2015","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-06T21:53:03Z","receivedAt":"2015-03-06T21:53:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Amate Yolande <yolandeamate@gmail.com> writes:\n\n> .... I would like to\n> work on the Unifying git branch -l, git tag -l, and git for-each-ref\n> project for GSOC 2015 and I hope I can get more directives on how to\n> move on with this project.\n\nHmm, the description on the ideas page looks somewhat sketchy.\n\n    These three commands are all about selecting a subset of a\n    repository's refs, and then printing the result. However, the\n    implementations are not shared. Some commands know selection\n    options the others do not (e.g., --contains, --merged), and\n    others know formatting options the others do not (e.g.,\n    for-each-ref's --format).\n\nSo, if I were a student to tackle this project, I'd start from:\n\n - Reading these three commands to understand how they currently\n   work.\n\n   For example, when I say \"git branch -r --no-merged origin/pu\",\n   what happens, and how exactly does the codepath that is called by\n   cmd_branch() in builtin/branch.c choose which branch to show by\n   computing what?  Can a user customize how they are shown?  How\n   does the customization specified by the user and what code\n   actually allows the output to be customized?\n\n   Do the same for other options \"git branch\" takes.\n\n   What about \"git tag\"?  \"git tag --contains origin/maint\" may be a\n   good starting point to think about, for example.\n\n - After doing the above, it would become clear to you that the\n   three have different ways to specify what are chosen to be shown,\n   and they have different ways to show their results.  What are the\n   overlaps in them?  What is missing from what others that might be\n   beneficial?\n\n   Do we want \"git for-each-ref --contains maint refs/heads/\" to\n   work, making \"for-each-ref\" borrow from \"tag\", for example?\n\n   Do we want \"git branch --format='%(refname:short) %(subject)'\"\n   to work, making \"branch\" borrow from \"for-each-ref\", for example?\n\n   Once we have \"git branch --format=...\" support, can we express\n   existing \"branch -v\" and \"branch -v -v\" output formats in terms\n   of the new facility?  What, if anything, needs to be added to the\n   format specifier you can give to the --format option as an\n   argument?\n\n - Then write out the design based on the above preliminary study.\n\n   How you want your new versions of commands to behave can be\n   described by updating their documentation and also by adding\n   tests (that would fail until you actually implement them) that\n   expects the desired behaviour.\n\n - And then have fun time to code your design ;-)\n\nThe second paragraph on the ideas page reads like this:\n\n    There have been experimental patches to unify the selection\n    process, and some discussion on unifying the formatting. Based\n    on this previous work, factor out a common library which can\n    cleanly handle both selection and formatting, and use it\n    consistently in the three commands.\n\nI do not have pointers to these \"experimental patches\" offhand.  You\nwould want to dig the list archive and/or ask around to find them,\nwhich would help doing the second step (i.e. after understanding the\ncurrent state of these commands, start designing what the unified\nresult should look like).\n\nHave fun.\n"}]}