{"thread":{"id":"33510","subject":"Ensimag students projects, version 2013","startedAt":"2013-04-14T20:04:53Z","lastAt":"2013-04-16T20:41:51Z","messageCount":21,"participants":["Matthieu Moy","Ping Yin","Thomas Rast","John Keeping","Duy Nguyen","Jeff King","Junio C Hamano","Ramkumar Ramachandra","Phil Hord"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"214231","messageId":"vpqobdg515m.fsf@grenoble-inp.fr","threadId":"33510","inReplyTo":null,"subject":"Ensimag students projects, version 2013","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-04-14T20:04:53Z","receivedAt":"2013-04-14T20:04:53Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Hi,\n\nLike the years before, I'm going to offer my students a 1 month project\n(end of May -> end of June) where they can contribute to a free\nsoftware, in particular Git.\n\nStudents are free to pick the feature they want, but I maintain a list\nof small project ideas on the wiki to help them:\n\n https://git.wiki.kernel.org/index.php/SmallProjectsIdeas\n\nfell free to edit and comment. Students will anyway have to discuss here\nbefore starting to code anything non-trivial.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"214254","messageId":"CACSwcnTsEiV7ehanPAxJm-SGP+P16FgvWYpEXtF9NK8fG2aNHA@mail.gmail.com","threadId":"33510","inReplyTo":"vpqobdg515m.fsf@grenoble-inp.fr","subject":"Re: Ensimag students projects, version 2013","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2013-04-15T02:04:40Z","receivedAt":"2013-04-15T02:04:40Z","isPatch":false,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"> 15 git rebase --stash, git pull --rebase --stash\n\nIt seems that Ramkumar Ramachandra is working on this in his \"[PATCH\nv2 0/3] Introduce pull.autostash\" series\nPing Yin\n\n\nOn Mon, Apr 15, 2013 at 4:04 AM, Matthieu Moy\n wrote:\n> Hi,\n>\n> Like the years before, I'm going to offer my students a 1 month project\n> (end of May -> end of June) where they can contribute to a free\n> software, in particular Git.\n>\n> Students are free to pick the feature they want, but I maintain a list\n> of small project ideas on the wiki to help them:\n>\n> https://git.wiki.kernel.org/index.php/SmallProjectsIdeas\n>\n> fell free to edit and comment. Students will anyway have to discuss here\n> before starting to code anything non-trivial.\n>\n> --\n> Matthieu Moy\n> http://www-verimag.imag.fr/~moy/\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"214270","messageId":"vpqr4ic2pid.fsf@grenoble-inp.fr","threadId":"33510","inReplyTo":"CACSwcnTsEiV7ehanPAxJm-SGP+P16FgvWYpEXtF9NK8fG2aNHA@mail.gmail.com","subject":"Re: Ensimag students projects, version 2013","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-04-15T07:59:22Z","receivedAt":"2013-04-15T07:59:22Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ping Yin writes:\n\n>> 15 git rebase --stash, git pull --rebase --stash\n>\n> It seems that Ramkumar Ramachandra is working on this in his \"[PATCH\n> v2 0/3] Introduce pull.autostash\" series\n> Ping Yin\n\nAh, cool! Added a note to the wiki, thanks,\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"214277","messageId":"87r4iccgdw.fsf@linux-k42r.v.cablecom.net","threadId":"33510","inReplyTo":"vpqobdg515m.fsf@grenoble-inp.fr","subject":"Re: Ensimag students projects, version 2013","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-04-15T09:06:19Z","receivedAt":"2013-04-15T09:06:19Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Matthieu Moy writes:\n\n> https://git.wiki.kernel.org/index.php/SmallProjectsIdeas\n\nMy $0.02:\n\n* Allow \"git add -p\" to use \"git diff --color-words\" to show hunks \n\n Check if you can use the existing --word-diff=porcelain output somehow\n to get it done in pure perl. Alternatively, try to hack a word-diff\n mode where it spews out both the line-diff (for later application) and\n the word-diff (for display) in some clever format, so that the perl\n code can easily match them up. If neither one is possible my feeling\n is that it's one of the hardest tasks on the list. (Not to\n discourcage anyone from trying, but still.)\n\n* git pull --set-upstream\n\n This is vaguely related to another itch that nobody has bothered to\n fix: 'git fetch origin foo' should really update origin/foo. This has\n been discussed on the list a few times already:\n\n http://thread.gmane.org/gmane.comp.version-control.git/192252\n http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758\n\n which by the way would be a *great* thing to fix, hint hint ;-) and\n since Peff already posted a POC patch in the first thread, it's\n probably not that hard. (Peff?)\n\n* Allow git send-email --cc 'foo@example.com, bar@example.com' instead\n of git send-email --cc foo@example.com --cc bar@example.com\n\n That would be really nice. Bonus points if it handles continuation\n lines etc. correctly, so that it's even easier to paste.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"214279","messageId":"vpqvc7oqh8a.fsf@grenoble-inp.fr","threadId":"33510","inReplyTo":"87r4iccgdw.fsf@linux-k42r.v.cablecom.net","subject":"Re: Ensimag students projects, version 2013","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-04-15T09:24:21Z","receivedAt":"2013-04-15T09:24:21Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Thomas Rast writes:\n\n> My $0.02:\n\n(BTW, feel free to edit the wiki. I've added a few bits from your\nmessage there already).\n\n> * Allow \"git add -p\" to use \"git diff --color-words\" to show hunks \n[...]\n> If neither one is possible my feeling is that it's one of the\n> hardest tasks on the list. (Not to discourcage anyone from trying,\n> but still.)\n\nYes, this was already inferable from the \"See also the GSoC proposal\"\nstatement and our discussions on GSoCs on this list ;-). It's not funny\nif all projects are easy, but it's not a coincidence if this idea has\nbeen there for a while without being implemented.\n\n> * git pull --set-upstream\n>\n> This is vaguely related to another itch that nobody has bothered to\n> fix: 'git fetch origin foo' should really update origin/foo. This has\n> been discussed on the list a few times already:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/192252\n> http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758\n>\n> which by the way would be a *great* thing to fix, hint hint ;-) and\n> since Peff already posted a POC patch in the first thread, it's\n> probably not that hard. (Peff?)\n\nMy understanding is that this would be technically easy to fix, but a\nmigration plan is needed, which isn't easy for a one-shot, one-month\ncontribution.\n\nI've added it to the wiki.\n\n> * Allow git send-email --cc 'foo@example.com, bar@example.com' instead\n> of git send-email --cc foo@example.com --cc bar@example.com\n>\n> That would be really nice. Bonus points if it handles continuation\n> lines etc. correctly, so that it's even easier to paste.\n\nAdded to the wiki too.\n\nThanks,\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"214283","messageId":"20130415094113.GC2278@serenity.lan","threadId":"33510","inReplyTo":"vpqvc7oqh8a.fsf@grenoble-inp.fr","subject":"Re: Ensimag students projects, version 2013","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-04-15T09:41:13Z","receivedAt":"2013-04-15T09:41:13Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Mon, Apr 15, 2013 at 11:24:21AM +0200, Matthieu Moy wrote:\n> Thomas Rast writes:\n> > * Allow git send-email --cc 'foo@example.com, bar@example.com' instead\n> > of git send-email --cc foo@example.com --cc bar@example.com\n> >\n> > That would be really nice. Bonus points if it handles continuation\n> > lines etc. correctly, so that it's even easier to paste.\n> \n> Added to the wiki too.\n\nAs an extension to this, it would be really nice if I could say \"git\nsend-email --reply-to \", feeding it an existing message. This\nwould set \"To\" and \"Cc\" appropriately but also quote the existing\nmessage for me to reply to, either into the cover letter or after the\n\"---\" in the patch (it's probably an error if there's no cover letter\nand more than one patch in this mode).\n"},{"id":"214295","messageId":"CACsJy8COdjm2WvY_QB=QSJqGk9PvrDpExN4Xs3UgoKoB7QVtJg@mail.gmail.com","threadId":"33510","inReplyTo":"87r4iccgdw.fsf@linux-k42r.v.cablecom.net","subject":"Re: Ensimag students projects, version 2013","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-04-15T11:36:12Z","receivedAt":"2013-04-15T11:36:12Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Apr 15, 2013 at 7:06 PM, Thomas Rast wrote:\n> Matthieu Moy writes:\n>\n>> https://git.wiki.kernel.org/index.php/SmallProjectsIdeas\n>\n> My $0.02:\n>\n> * Allow \"git add -p\" to use \"git diff --color-words\" to show hunks\n>\n> Check if you can use the existing --word-diff=porcelain output somehow\n> to get it done in pure perl. Alternatively, try to hack a word-diff\n> mode where it spews out both the line-diff (for later application) and\n> the word-diff (for display) in some clever format, so that the perl\n> code can easily match them up. If neither one is possible my feeling\n> is that it's one of the hardest tasks on the list. (Not to\n> discourcage anyone from trying, but still.)\n\nYes, please.. Also in some case, I'd like to pass the pattern to\n--color-words (usually just --color-words=.). Something for the\nstudent to think about when designing the interface.\n\n> * Allow git send-email --cc 'foo@example.com, bar@example.com' instead\n> of git send-email --cc foo@example.com --cc bar@example.com\n>\n> That would be really nice. Bonus points if it handles continuation\n> lines etc. correctly, so that it's even easier to paste.\n\n* Color the header lines in git send-email. Bonus point if it could\nhighlight possible typos like foo@example.co.\n--\nDuy\n"},{"id":"214304","messageId":"20130415140513.GA16154@sigill.intra.peff.net","threadId":"33510","inReplyTo":"vpqvc7oqh8a.fsf@grenoble-inp.fr","subject":"Re: Ensimag students projects, version 2013","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-15T14:05:13Z","receivedAt":"2013-04-15T14:05:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 15, 2013 at 11:24:21AM +0200, Matthieu Moy wrote:\n\n> > * git pull --set-upstream\n> >\n> > This is vaguely related to another itch that nobody has bothered to\n> > fix: 'git fetch origin foo' should really update origin/foo. This has\n> > been discussed on the list a few times already:\n> >\n> > http://thread.gmane.org/gmane.comp.version-control.git/192252\n> > http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758\n> >\n> > which by the way would be a *great* thing to fix, hint hint ;-) and\n> > since Peff already posted a POC patch in the first thread, it's\n> > probably not that hard. (Peff?)\n> \n> My understanding is that this would be technically easy to fix, but a\n> migration plan is needed, which isn't easy for a one-shot, one-month\n> contribution.\n\nYes. The concept isn't that hard, but the question was one of whether it\nwould break some obscure workflows. But I don't remember all of the\ndetails; I think I gave some examples in past threads.\n\n-Peff\n"},{"id":"214306","messageId":"7v1uab26bn.fsf@alter.siamese.dyndns.org","threadId":"33510","inReplyTo":"20130415140513.GA16154@sigill.intra.peff.net","subject":"Re: Ensimag students projects, version 2013","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-15T14:53:48Z","receivedAt":"2013-04-15T14:53:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Apr 15, 2013 at 11:24:21AM +0200, Matthieu Moy wrote:\n>\n>> > * git pull --set-upstream\n>> >\n>> > This is vaguely related to another itch that nobody has bothered to\n>> > fix: 'git fetch origin foo' should really update origin/foo. This has\n>> > been discussed on the list a few times already:\n>> >\n>> > http://thread.gmane.org/gmane.comp.version-control.git/192252\n>> > http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758\n>> >\n>> > which by the way would be a *great* thing to fix, hint hint ;-) and\n>> > since Peff already posted a POC patch in the first thread, it's\n>> > probably not that hard. (Peff?)\n>> \n>> My understanding is that this would be technically easy to fix, but a\n>> migration plan is needed, which isn't easy for a one-shot, one-month\n>> contribution.\n>\n> Yes. The concept isn't that hard, but the question was one of whether it\n> would break some obscure workflows. But I don't remember all of the\n> details; I think I gave some examples in past threads.\n\nI think the one Thomas lists in $gmane/165758 is the one.\n\nIt has been the way for users to make sure that origin/master stays\nput to explicitly tell Git not to update the remote tracking branch\nusing a refspec without colon, so that they can do\n\n\tgit fetch origin master\n\tgit log origin/master..FETCH_HEAD\n\n(or its three-dot variant) to gauge the progress of the other side\nsince the last time the user observed.\n\nPersonally I doubt this trick is so relevant these days, not just\nbecause we can look at reflog of origin/master. The user could just\ndo\n\n\told=$(git rev-parse origin/master)\n git fetch origin master\n git log $old..FETCH_HEAD\n\neven with a modified Git that updates the remote tracking branches\nwithout a storing refspec.\n\nThe primary reason why I do not think this is relevant these days is\nbecause the original premise \"remote tracking branches keep what the\nlast 'git fetch' observed\" has already been broken for a long time.\nThe users are better off thinking that the remote tracking branches\ncan be updated any time (not just the last 'git fetch') when Git\nobserves (or could observe) the state of the remote without being\ntold explicitly with today's \"pretend as if we fetched immediately\nafter we push\" behaviour.\n"},{"id":"214310","messageId":"CALkWK0nFB1dzmp6yC9XS4ADmWf9tfQYtsSH0K1u0dtBWT0CRNw@mail.gmail.com","threadId":"33510","inReplyTo":"vpqobdg515m.fsf@grenoble-inp.fr","subject":"Re: Ensimag students projects, version 2013","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-15T15:18:37Z","receivedAt":"2013-04-15T15:18:37Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"A few small personal itches off the top of my head:\n\n- Make git status -s show \"state status\" as well: this essentially\nrequires writing an equivalent of wt_status_print_state() for use in\nwt_shortstatus_print().\n\n- Make the -s and -b switches in git status configuration variables.\nI currently have status aliased to status -sb, and this is less than\nideal.\n\n- Make the -3 and -c switches in git am configuration variables. I\nhave an alias.\n\n- Create an advice.ui (like color.ui) to turn off all advice. I don't\nneed advice.\n"},{"id":"214313","messageId":"7vk3o3zt6e.fsf@alter.siamese.dyndns.org","threadId":"33510","inReplyTo":"CALkWK0nFB1dzmp6yC9XS4ADmWf9tfQYtsSH0K1u0dtBWT0CRNw@mail.gmail.com","subject":"Re: Ensimag students projects, version 2013","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-15T15:53:45Z","receivedAt":"2013-04-15T15:53:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> - Make the -3 and -c switches in git am configuration variables. I\n> have an alias.\n\n - Make failed \"git am --3way\" due to \"unusable index\" a bit more\n helpful. Right now, the information on which hunk failed to apply\n is lost, and there is no \"git am --no-3way\" (the user needs to\n know the trick \">.git/rebase-apply/threeway\").\n"},{"id":"214321","messageId":"vpqzjwzkb4e.fsf@grenoble-inp.fr","threadId":"33510","inReplyTo":"CALkWK0nFB1dzmp6yC9XS4ADmWf9tfQYtsSH0K1u0dtBWT0CRNw@mail.gmail.com","subject":"Re: Ensimag students projects, version 2013","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-04-15T16:32:49Z","receivedAt":"2013-04-15T16:32:49Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ramkumar Ramachandra writes:\n\n> A few small personal itches off the top of my head:\n>\n> - Make git status -s show \"state status\" as well: this essentially\n> requires writing an equivalent of wt_status_print_state() for use in\n> wt_shortstatus_print().\n\nDo you mean, showing it in a natural language form, or machine-parsable?\n\nIf the later, there was a patch series doing essentially this:\n\n http://thread.gmane.org/gmane.comp.version-control.git/209240\n\nIt doesn't seem to have been merged. Phil, what happened to it?\n\n> - Make the -s and -b switches in git status configuration variables.\n> I currently have status aliased to status -sb, and this is less than\n> ideal.\n>\n> - Make the -3 and -c switches in git am configuration variables. I\n> have an alias.\n\nSeems reasonable. Should be good technical warm-ups if people agree this\nis a good idea.\n\n> - Create an advice.ui (like color.ui) to turn off all advice. I don't\n> need advice.\n\nI tend to agree with you, but the idea has explicitly been rejected in\nthe past. The problem with an option like this is that it would also\ndisable the advices that may be added in the future. By letting people\ndisable the advices one by one, people see new advices as they arrive.\nYou may think of it like \"do not show this message again\" tickboxes in\nsome graphical user interfaces.\n\nToo controversial area for newcommers I guess ;-).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"214411","messageId":"20130416005836.GC14995@sigill.intra.peff.net","threadId":"33510","inReplyTo":"vpqzjwzkb4e.fsf@grenoble-inp.fr","subject":"Re: Ensimag students projects, version 2013","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-16T00:58:37Z","receivedAt":"2013-04-16T00:58:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 15, 2013 at 06:32:49PM +0200, Matthieu Moy wrote:\n\n> > - Create an advice.ui (like color.ui) to turn off all advice. I don't\n> > need advice.\n> \n> I tend to agree with you, but the idea has explicitly been rejected in\n> the past. The problem with an option like this is that it would also\n> disable the advices that may be added in the future. By letting people\n> disable the advices one by one, people see new advices as they arrive.\n> You may think of it like \"do not show this message again\" tickboxes in\n> some graphical user interfaces.\n\nFWIW, I do not think it was so much rejected as that I had initially\nplanned to implement it, then decided against it. Mostly because I\nwanted to actually get annoyed with each piece of advice before\ndisabling it. Because sometimes the right answer is actually \"make the\nadvice better\".\n\nBut I do not mind somebody adding it if it is a burning desire.\n\n-Peff\n"},{"id":"214427","messageId":"CABURp0rd1owLCwTudQ7WkX7JzmnNOT2ZKvNDv9aqqWOpVOn-mQ@mail.gmail.com","threadId":"33510","inReplyTo":"CALkWK0nFB1dzmp6yC9XS4ADmWf9tfQYtsSH0K1u0dtBWT0CRNw@mail.gmail.com","subject":"Re: Ensimag students projects, version 2013","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-04-16T03:38:58Z","receivedAt":"2013-04-16T03:38:58Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Mon, Apr 15, 2013 at 11:18 AM, Ramkumar Ramachandra\n wrote:\n> A few small personal itches off the top of my head:\n>\n> - Make git status -s show \"state status\" as well: this essentially\n> requires writing an equivalent of wt_status_print_state() for use in\n> wt_shortstatus_print().\n\nI actually submitted a patch for this last fall. I was going to\nreprise it and give it another run after your wt_status changes died\ndown (and I found some free time).\n\nhttp://comments.gmane.org/gmane.comp.version-control.git/208209\n\nPhil\n"},{"id":"214430","messageId":"7vwqs3nm88.fsf@alter.siamese.dyndns.org","threadId":"33510","inReplyTo":"20130416005836.GC14995@sigill.intra.peff.net","subject":"Re: Ensimag students projects, version 2013","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-16T04:16:55Z","receivedAt":"2013-04-16T04:16:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> FWIW, I do not think it was so much rejected as that I had initially\n> planned to implement it, then decided against it. Mostly because I\n> wanted to actually get annoyed with each piece of advice before\n> disabling it. Because sometimes the right answer is actually \"make the\n> advice better\".\n\nI am pretty much aligned with this position. \"Make the advice\nbetter\" not only refers to what we say (i.e. the message) but when\nwe say it, and keeping the advice variables enabled is the only way\nto notice when we are being excessive.\n\nI'd hate to see any Git developers running with advice turned off\nfor this exact reason.\n"},{"id":"214432","messageId":"20130416042310.GA15676@sigill.intra.peff.net","threadId":"33510","inReplyTo":"7v1uab26bn.fsf@alter.siamese.dyndns.org","subject":"Re: Ensimag students projects, version 2013","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-04-16T04:23:10Z","receivedAt":"2013-04-16T04:23:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 15, 2013 at 07:53:48AM -0700, Junio C Hamano wrote:\n\n> > Yes. The concept isn't that hard, but the question was one of whether it\n> > would break some obscure workflows. But I don't remember all of the\n> > details; I think I gave some examples in past threads.\n> \n> I think the one Thomas lists in $gmane/165758 is the one.\n\nThe one I was thinking of is:\n\n http://article.gmane.org/gmane.comp.version-control.git/127215\n\n> The primary reason why I do not think this is relevant these days is\n> because the original premise \"remote tracking branches keep what the\n> last 'git fetch' observed\" has already been broken for a long time.\n> The users are better off thinking that the remote tracking branches\n> can be updated any time (not just the last 'git fetch') when Git\n> observes (or could observe) the state of the remote without being\n> told explicitly with today's \"pretend as if we fetched immediately\n> after we push\" behaviour.\n\nYeah, that is certainly my mental model, and how \"git push\" works (and\nhow the patch I linked to above works). I actually don't care that much\neither way, which is why I haven't polished up that patch. I'd be happy\nif somebody worked on it, but I don't know if it is all that interesting\na student project. It is not much development, and mostly about digging\nin the history of what tracking branches mean, and convincing everybody\nit's a good change. Which is hard for any newcomer to the community to\ndo as a first project.\n\n-Peff\n"},{"id":"214443","messageId":"CALkWK0m=ZFK_+Za=_JabO4fiGTQ4K-Bxpr1hiZTrL_T4XuZKog@mail.gmail.com","threadId":"33510","inReplyTo":"vpqzjwzkb4e.fsf@grenoble-inp.fr","subject":"Re: Ensimag students projects, version 2013","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-16T07:24:19Z","receivedAt":"2013-04-16T07:24:19Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Matthieu Moy wrote:\n> I tend to agree with you, but the idea has explicitly been rejected in\n> the past. The problem with an option like this is that it would also\n> disable the advices that may be added in the future. By letting people\n> disable the advices one by one, people see new advices as they arrive.\n> You may think of it like \"do not show this message again\" tickboxes in\n> some graphical user interfaces.\n>\n> Too controversial area for newcommers I guess ;-).\n\nThis is the kind of nonsense that I absolutely won't stand for. Am I\na less important customer than a newcomer? Hell, if anything, I'm the\n_more_ important customer because I spend time improving git while a\nnewcomer makes no contribution whatsoever. In my opinion, the most\nimportant customers of git are (in this order of precedence):\n\n1. Developers who hack on git to make it better. This means that the\nimplementation must have a pleasing consistency, and end-user\nexpectations of UI are secondary. For some reason, Junio seems to\ndisagree with this.\n\n2. Advanced users hacking on projects that demand effective use of git\nlike linux.git and git.git, as opposed to some little project on\nGitHub that just accepts pull requests.\n\n3. Newcomers.\n\nI don't develop git for newcomers. I develop git for myself, and\nscratch my personal itches. The most important customer to me is\nmyself, and everyone else is secondary.\n\nThat said, I don't feel strongly about this particular advice.ui\nissue, and Jeff/ Junio have presented a reasonably cogent argument.\n"},{"id":"214445","messageId":"CALkWK0=FozUTS5EFMXdhU50M1WjgGD9DsAVF8AcqPVLMaPz_HA@mail.gmail.com","threadId":"33510","inReplyTo":"7vwqs3nm88.fsf@alter.siamese.dyndns.org","subject":"Re: Ensimag students projects, version 2013","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-16T07:37:29Z","receivedAt":"2013-04-16T07:37:29Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> I'd hate to see any Git developers running with advice turned off\n> for this exact reason.\n\nImproving advice is your itch, but it is certainly not my itch. I\ndon't want to see messages like \"Commit your changes or stash them\",\nor \"try --continue | --skip | --abort\" cluttering up my valuable\nterminal output when I know what to do. I don't care how they can be\nmade \"better\", because I don't want to see them in the first place.\n\nYou should have nothing against me for running with all advice turned\noff. It's not your job to dictate how a software should be used, but\nrather design it so that intended usage is the most intuitive.\n"},{"id":"214512","messageId":"7v4nf6mjcw.fsf@alter.siamese.dyndns.org","threadId":"33510","inReplyTo":"CALkWK0m=ZFK_+Za=_JabO4fiGTQ4K-Bxpr1hiZTrL_T4XuZKog@mail.gmail.com","subject":"Re: Ensimag students projects, version 2013","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-16T18:16:31Z","receivedAt":"2013-04-16T18:16:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Matthieu Moy wrote:\n>> I tend to agree with you, but the idea has explicitly been rejected in\n>> the past. The problem with an option like this is that it would also\n>> disable the advices that may be added in the future. By letting people\n>> disable the advices one by one, people see new advices as they arrive.\n>> You may think of it like \"do not show this message again\" tickboxes in\n>> some graphical user interfaces.\n>>\n>> Too controversial area for newcommers I guess ;-).\n>\n> This is the kind of nonsense that I absolutely won't stand for. Am I\n> a less important customer than a newcomer?\n\nWho said anything about a customer?\n\nA newcomer to a community (i.e. Matthieu's student) needs not just\nto show technical excellence with patches, but needs to make a good\nargument on a larger design decision; old timers already tried to\nachieve a concensus on it, and did not manage to do so the last time\nwe tried.\n\nIt is a tough topic for a newcomer developer to tackle.\n"},{"id":"214522","messageId":"CALkWK0nLQaZmAud9oBmxosWqdN_bVKxV9rHhkEzfnt_WzQjSMA@mail.gmail.com","threadId":"33510","inReplyTo":"7v4nf6mjcw.fsf@alter.siamese.dyndns.org","subject":"Re: Ensimag students projects, version 2013","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-16T19:15:23Z","receivedAt":"2013-04-16T19:15:23Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> It is a tough topic for a newcomer developer to tackle.\n\nAgreed. We should give these students tasks that are relatively\nstraightforward, and not controversial.\n"},{"id":"214535","messageId":"CALkWK0n0w9gB-1=SA4gVBA+coYrXThQrTE28uWpMD=yeB1ph4A@mail.gmail.com","threadId":"33510","inReplyTo":"7v4nf6mjcw.fsf@alter.siamese.dyndns.org","subject":"Re: Ensimag students projects, version 2013","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-16T20:41:51Z","receivedAt":"2013-04-16T20:41:51Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Who said anything about a customer?\n>\n> A newcomer to a community (i.e. Matthieu's student) needs not just\n> to show technical excellence with patches, but needs to make a good\n> argument on a larger design decision; old timers already tried to\n> achieve a concensus on it, and did not manage to do so the last time\n> we tried.\n\nAnd sorry about the huge misunderstanding. I thought Matthieu was\nsaying that the proposed configuration variable would be harmful to\nnewcomers, and we should therefore not add it.\n\nI feel very silly about having written such a long response to\nsomething I misunderstood.\n"}]}