{"thread":{"id":"10792","subject":"Deprecate git-fetch-pack?","startedAt":"2007-11-10T23:11:53Z","lastAt":"2007-11-12T19:16:13Z","messageCount":29,"participants":["Daniel Barkalow","Junio C Hamano","Ask Bjørn Hansen","Mike Hommey","Johannes Schindelin","Theodore Tso","Jakub Narebski","Theodore Ts'o","Ping Yin","Andreas Ericsson","Jon Loeliger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"59251","messageId":"Pine.LNX.4.64.0711101752490.29952@iabervon.org","threadId":"10792","inReplyTo":null,"subject":"Deprecate git-fetch-pack?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-11-10T23:11:53Z","receivedAt":"2007-11-10T23:11:53Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"Now that git-fetch is in C, built in, and doing the fetch-pack in the same \nprocess, the normal usage patterns don't involve actually executing \ngit-fetch-pack. Can we deprecate it at this point, or it is plausibly \nbeing used by scripts? As it is now, I'm not entirely confidant that the \ntests in t5500 won't be fooled by git-fetch working even with \ngit-fetch-pack being broken in various ways, which should be fixed if we \nwant to keep it.\n\nWe also might as well deprecate peek-remote now that it's a synonym for \nls-remote.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"59254","messageId":"7v4pftip42.fsf@gitster.siamese.dyndns.org","threadId":"10792","inReplyTo":"Pine.LNX.4.64.0711101752490.29952@iabervon.org","subject":"Re: Deprecate git-fetch-pack?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-11T00:48:29Z","receivedAt":"2007-11-11T00:48:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> Now that git-fetch is in C, built in, and doing the fetch-pack in the same \n> process, the normal usage patterns don't involve actually executing \n> git-fetch-pack. Can we deprecate it at this point, or it is plausibly \n> being used by scripts? As it is now, I'm not entirely confidant that the \n> tests in t5500 won't be fooled by git-fetch working even with \n> git-fetch-pack being broken in various ways, which should be fixed if we \n> want to keep it.\n>\n> We also might as well deprecate peek-remote now that it's a synonym for \n> ls-remote.\n\nEspecially because git-fetch is no longer as hackable as it used\nto be, and because people may still find special needs that can\nbe hacked up with direct access to low level transports from the\nscript more easily than going down to the C level, I'd rather\nwait and see for a cycle or two to decide. There is no strong\nreason to drop it, is there?\n\nAs to peek-remote, ls-remote over the native transport is a\nsynonym so I do not think anybody doing the scripting would have\nproblem doing s/peek-/ls-/ to their script, but again I do not\nsee a heavy maintenance burden to keep the synonym, yet.\n"},{"id":"59257","messageId":"74415967-7F49-426C-8BF5-1A0210C337AB@develooper.com","threadId":"10792","inReplyTo":"7v4pftip42.fsf@gitster.siamese.dyndns.org","subject":"Re: Deprecate git-fetch-pack?","fromName":"Ask Bjørn Hansen","fromEmail":"ask@develooper.com","sentAt":"2007-11-11T03:09:28Z","receivedAt":"2007-11-11T03:09:28Z","isPatch":false,"sender":{"key":"ask@develooper.com","avatar":"https://gravatar.com/avatar/05ce68433216df7d04bb0d82b7d93b11957e2137e6ed23c4b5bc061d78635f2f?d=mp&s=160"},"body":"\nOn Nov 10, 2007, at 4:48 PM, Junio C Hamano wrote:\n\n> As to peek-remote, ls-remote over the native transport is a\n> synonym so I do not think anybody doing the scripting would have\n> problem doing s/peek-/ls-/ to their script, but again I do not\n> see a heavy maintenance burden to keep the synonym, yet.\n\nFor new users the superfluous programs are a burden making it harder \nto learn how everything works.\n\n\"What does this thing do? How is it different from that other similar \nprogram? How do they interact? Oh, this one isn't really used. Grrh.\"\n\nAt least a note in the documentation that it's superseded by \n$other_program would be helpful for us newcomers. :-)\n\n\n - ask\n\n-- \nhttp://develooper.com/ - http://askask.com/\n"},{"id":"59291","messageId":"20071111083257.GB14474@glandium.org","threadId":"10792","inReplyTo":"7v4pftip42.fsf@gitster.siamese.dyndns.org","subject":"Re: Deprecate git-fetch-pack?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-11T08:32:57Z","receivedAt":"2007-11-11T08:32:57Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sat, Nov 10, 2007 at 04:48:29PM -0800, Junio C Hamano wrote:\n> Daniel Barkalow writes:\n> \n> > Now that git-fetch is in C, built in, and doing the fetch-pack in the same \n> > process, the normal usage patterns don't involve actually executing \n> > git-fetch-pack. Can we deprecate it at this point, or it is plausibly \n> > being used by scripts? As it is now, I'm not entirely confidant that the \n> > tests in t5500 won't be fooled by git-fetch working even with \n> > git-fetch-pack being broken in various ways, which should be fixed if we \n> > want to keep it.\n> >\n> > We also might as well deprecate peek-remote now that it's a synonym for \n> > ls-remote.\n> \n> Especially because git-fetch is no longer as hackable as it used\n> to be, and because people may still find special needs that can\n> be hacked up with direct access to low level transports from the\n> script more easily than going down to the C level, I'd rather\n> wait and see for a cycle or two to decide. There is no strong\n> reason to drop it, is there?\n\nStill, if the functionality is needed, i think it would be better if it\nwere provided by git-fetch --pack. The list of programs is already long\nenough, it should be time to shrink it.\n\nMike\n"},{"id":"59309","messageId":"Pine.LNX.4.64.0711111103240.4362@racer.site","threadId":"10792","inReplyTo":"74415967-7F49-426C-8BF5-1A0210C337AB@develooper.com","subject":"Re: Deprecate git-fetch-pack?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-11T11:05:34Z","receivedAt":"2007-11-11T11:05:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 10 Nov 2007, Ask Bj?rn Hansen wrote:\n\n> For new users the superfluous programs are a burden making it harder to \n> learn how everything works.\n\nThis should be a non-issue. We really should start deprecating \n\"git-\" in favour of \"git \" for real.\n\nNew users should not even be told that this is correct usage.\n\nMy reason? We have plumbing, and we will always have plumbing, as \ncommands. A regular git user does not _want_ to see that. Without said \ndeprecation she _will_, however.\n\nCiao,\nDscho\n"},{"id":"59378","messageId":"7vd4ugcwkm.fsf@gitster.siamese.dyndns.org","threadId":"10792","inReplyTo":"Pine.LNX.4.64.0711111103240.4362@racer.site","subject":"Re: Deprecate git-fetch-pack?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-11T21:16:09Z","receivedAt":"2007-11-11T21:16:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Sat, 10 Nov 2007, Ask Bj?rn Hansen wrote:\n>\n>> For new users the superfluous programs are a burden making it harder to \n>> learn how everything works.\n>\n> This should be a non-issue. We really should start deprecating \n> \"git-\" in favour of \"git \" for real.\n>\n> New users should not even be told that this is correct usage.\n>\n> My reason? We have plumbing, and we will always have plumbing, as \n> commands. A regular git user does not _want_ to see that. Without said \n> deprecation she _will_, however.\n\nIf you can write \"git-commit\" and \"git commit\" interchangeably\nwhile you cannot say \"git-cat-file\" and are forced to say \"git\ncat-file\", I suspect that would lead to a great confusion and\nunhappy users.\n\nI wonder if making the distinction between plumbing and\nporcelain in the git(7) page even more cleaner would help.\n"},{"id":"59390","messageId":"20071111222117.GA7392@thunk.org","threadId":"10792","inReplyTo":"7vd4ugcwkm.fsf@gitster.siamese.dyndns.org","subject":"Re: Deprecate git-fetch-pack?","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-11-11T22:21:17Z","receivedAt":"2007-11-11T22:21:17Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Nov 11, 2007 at 01:16:09PM -0800, Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> > This should be a non-issue. We really should start deprecating \n> > \"git-\" in favour of \"git \" for real.\n> >\n> > New users should not even be told that this is correct usage.\n> >\n> \n> If you can write \"git-commit\" and \"git commit\" interchangeably\n> while you cannot say \"git-cat-file\" and are forced to say \"git\n> cat-file\", I suspect that would lead to a great confusion and\n> unhappy users.\n\nOne of the reasons why I use git-diff and git-commit and in particular\n\"git-rebase --interactive master\" very often is that it allows my\nshell's bang completion to work. (i.e., \"!git-rebase\"). If we tell\npeople they can not use \"git-rebase\", and must instead use \"git\nrebase\" instead, I would consider that pretty annoying/obnoxious.\n\n\t\t\t\t\t- Ted\n"},{"id":"59394","messageId":"7vabpkbebj.fsf@gitster.siamese.dyndns.org","threadId":"10792","inReplyTo":"20071111222117.GA7392@thunk.org","subject":"Re: Deprecate git-fetch-pack?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-11T22:35:44Z","receivedAt":"2007-11-11T22:35:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso writes:\n\n> On Sun, Nov 11, 2007 at 01:16:09PM -0800, Junio C Hamano wrote:\n>> Johannes Schindelin writes:\n>> > This should be a non-issue. We really should start deprecating \n>> > \"git-\" in favour of \"git \" for real.\n>> >\n>> > New users should not even be told that this is correct usage.\n>> \n>> If you can write \"git-commit\" and \"git commit\" interchangeably\n>> while you cannot say \"git-cat-file\" and are forced to say \"git\n>> cat-file\", I suspect that would lead to a great confusion and\n>> unhappy users.\n>\n> One of the reasons why I use git-diff and git-commit and in particular\n> \"git-rebase --interactive master\" very often is that it allows my\n> shell's bang completion to work. (i.e., \"!git-rebase\"). If we tell\n> people they can not use \"git-rebase\", and must instead use \"git\n> rebase\" instead, I would consider that pretty annoying/obnoxious.\n\nOh, of course.\n\nBut my impression was that Johannes was talking about\ndeprecating git- form only for plumbing, so that the users\nwill only see git- for the Porcelain. That would not break\nyour bang completion for the porcelain commands.\n\nIf Johannes was talking about deprecating all git- form,\nthen that would indeed break your bang completion, but it has\nconceptually a much bigger problem. The topic was about fixing\n\"a new user sees too many git commands and gets scared\" problem.\nDeprecaing all git- form just replaces the problem with \"a\nnew user sees too many git subcommands and gets scared\" problem,\nwithout solving anything.\n"},{"id":"59397","messageId":"Pine.LNX.4.64.0711112247350.4362@racer.site","threadId":"10792","inReplyTo":"7vabpkbebj.fsf@gitster.siamese.dyndns.org","subject":"Re: Deprecate git-fetch-pack?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-11T22:50:26Z","receivedAt":"2007-11-11T22:50:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 11 Nov 2007, Junio C Hamano wrote:\n\n> Theodore Tso writes:\n> \n> > On Sun, Nov 11, 2007 at 01:16:09PM -0800, Junio C Hamano wrote:\n> >> Johannes Schindelin writes:\n> >> > This should be a non-issue. We really should start deprecating \n> >> > \"git-\" in favour of \"git \" for real.\n> >> >\n> >> > New users should not even be told that this is correct usage.\n> >> \n> >> If you can write \"git-commit\" and \"git commit\" interchangeably\n> >> while you cannot say \"git-cat-file\" and are forced to say \"git\n> >> cat-file\", I suspect that would lead to a great confusion and\n> >> unhappy users.\n> >\n> > One of the reasons why I use git-diff and git-commit and in particular\n> > \"git-rebase --interactive master\" very often is that it allows my\n> > shell's bang completion to work. (i.e., \"!git-rebase\"). If we tell\n> > people they can not use \"git-rebase\", and must instead use \"git\n> > rebase\" instead, I would consider that pretty annoying/obnoxious.\n> \n> Oh, of course.\n> \n> But my impression was that Johannes was talking about\n> deprecating git- form only for plumbing, so that the users\n> will only see git- for the Porcelain. That would not break\n> your bang completion for the porcelain commands.\n> \n> If Johannes was talking about deprecating all git- form,\n> then that would indeed break your bang completion, but it has\n> conceptually a much bigger problem. The topic was about fixing\n> \"a new user sees too many git commands and gets scared\" problem.\n> Deprecaing all git- form just replaces the problem with \"a\n> new user sees too many git subcommands and gets scared\" problem,\n> without solving anything.\n\nI beg to differ. The biggest problem with a new user seeing all those \ncompletions is that this user is scared.\n\nJust taking away that first shock would be helping very much. I mean, we \n_still_ have the reputation of being more complex than other SCMs, but I \ndo not think that this reputation is completely deserved.\n\nHowever, reputations are formed by first time impressions. It is _hard_ \nto get rid of a bad first time impression.\n\nBut yes, I was only proposing to deprecate all usage of git- in the \ndocumentation.\n\nMaybe I'm wrong. Wouldn't be the first time.\n\nCiao,\nDscho\n"},{"id":"59401","messageId":"20071111235819.GB7392@thunk.org","threadId":"10792","inReplyTo":"Pine.LNX.4.64.0711112247350.4362@racer.site","subject":"Re: Deprecate git-fetch-pack?","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-11-11T23:58:19Z","receivedAt":"2007-11-11T23:58:19Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Nov 11, 2007 at 10:50:26PM +0000, Johannes Schindelin wrote:\n> I beg to differ. The biggest problem with a new user seeing all those \n> completions is that this user is scared.\n\nWell, if we introduce the new user only to \"git subcomand\", and the\ndocumentation is relatively gentle, I would suspect would solve most\nof the problem. Note BTW, that if your thesis is true, \"git help -a\"\n(which is recommended in the last line of output by \"git help\") should\ncause the typical new user to faint dead away. :-)\n\nSome other areas that would be worth fixing, in terms of user usability.\n\n1) The references to the tutorial, everyday git, etc., don't actually\nhave working references in the git man page. (i.e., what you see when\nyou run the command \"man git\"). It would be nice if that were fixed.\n\n2) The command which are displayed by \"git help\" should use some\nserious rethinking. Ideally, it would be nice if the output fit in a\nsingle 24-line terminal window. Some candidates for removal:\n\n a) prune: \"git prune\" definitely doesn't deserve to be on the\n front and center as displayed by \"git help\". Maybe replace it\n with \"gc\", but now that we have gc.auto, I'm not sure it's\n worth it at all.\n\n b) revert: Is that really that common of a command?\n\n c) show-branch: The output is terrifying without explanation\n\nThere are other commands I'm not so sure about, but it is worth\nflagging them. One way that might be helpful is to group the commands\ninto subcommands, much like gdb does, so you could do something like\n\"git help other-repos\" (where all commands that involve interacting\nwith other repositories are summarized), and so on.\n\n> But yes, I was only proposing to deprecate all usage of git- in the \n> documentation.\n\nI agree that de-emphasizing git- isn't a bad thing. But I think\nwe need to look at the big picture here, since \"git help\" is often one\nof the first things a new user might try (and obviously very few git\ndevelopers look at it, or \"prune\" probably would have been removed\nfrom git help a long time ago :-), and the last thing that git help\nsuggests (and so therefore it will very visible to the newbie user),\nis \"git help -a\" --- and that displays every single git command under\ncreation, porcelain or plumbing, in one gigantic sorted list. \n\nOops, so much for first impressions. :-)\n\n\t \t \t \t \t\t - Ted\n"},{"id":"59402","messageId":"fh8609$umn$1@ger.gmane.org","threadId":"10792","inReplyTo":"20071111235819.GB7392@thunk.org","subject":"Re: Deprecate git-fetch-pack?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-12T00:16:13Z","receivedAt":"2007-11-12T00:16:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Theodore Tso wrote:\n\n> 2) The command which are displayed by \"git help\" should use some\n> serious rethinking.  Ideally, it would be nice if the output fit in a\n> single 24-line terminal window.   Some candidates for removal:\n> \n>        a) prune: \"git prune\" definitely doesn't deserve to be on the\n>        front and center as displayed by \"git help\".  Maybe replace it\n>        with \"gc\", but now that we have gc.auto, I'm not sure it's\n>        worth it at all.\n\nI would replace it by \"git gc\" (you have to run 'git gc --prune' by hand\non quiescent repository), or remove it altogether.\n\n>        b) revert:  Is that really that common of a command?\n\nIt is useful command, perhaps short description should be improved.\nBTW. if we have cherry-pick, then we should have revert.\n\n>        c) show-branch: The output is terrifying without explanation\n\nI agree. I would replace it by gitk, or gui (git-gui / \"git gui\").\n\n> There are other commands I'm not so sure about, but it is worth\n> flagging them.  One way that might be helpful is to group the commands\n> into subcommands, much like gdb does, so you could do something like\n> \"git help other-repos\" (where all commands that involve interacting\n> with other repositories are summarized), and so on.\n\nI think that \"git-rm\" could be removed, because \"rm ; git commit ...\"\nworks just fine.\n\nSee also discussion about results of Git User's Survey 2007, somewhere\naround\n http://thread.gmane.org/gmane.comp.version-control.git/59935/focus=62205\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"59410","messageId":"1194829077-14320-1-git-send-email-tytso@mit.edu","threadId":"10792","inReplyTo":"20071111235819.GB7392@thunk.org","subject":"[PATCH,RFC 1/2] Make the list of common commands more exclusive","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2007-11-12T00:57:56Z","receivedAt":"2007-11-12T00:57:56Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"Remove apply, archive, cherry-pick, prune, revert, and show-branch, so\n\"git help\" is less intimidating.\n\nSigned-off-by: \"Theodore Ts'o\" \n---\n generate-cmdlist.sh | 6 ------\n 1 files changed, 0 insertions(+), 6 deletions(-)\n\ndiff --git a/generate-cmdlist.sh b/generate-cmdlist.sh\nindex 17df47b..1ba27ec 100755\n--- a/generate-cmdlist.sh\n+++ b/generate-cmdlist.sh\n@@ -11,12 +11,9 @@ static struct cmdname_help common_cmds[] = {\"\n \n sort <<\\EOF |\n add\n-apply\n-archive\n bisect\n branch\n checkout\n-cherry-pick\n clone\n commit\n diff\n@@ -26,15 +23,12 @@ init\n log\n merge\n mv\n-prune\n pull\n push\n rebase\n reset\n-revert\n rm\n show\n-show-branch\n status\n tag\n EOF\n-- \n1.5.3.5.623.g91546-dirty\n"},{"id":"59409","messageId":"1194829077-14320-2-git-send-email-tytso@mit.edu","threadId":"10792","inReplyTo":"1194829077-14320-1-git-send-email-tytso@mit.edu","subject":"[PATCH,RFC 2/2] Remove hint to use \"git help -a\"","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2007-11-12T00:57:57Z","receivedAt":"2007-11-12T00:57:57Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"The newbie user will run away screaming when they see all possible\ncommands. The expert user will already know about the -a option from\nreading the git man page.\n\nSigned-off-by: \"Theodore Ts'o\" \n---\n help.c | 1 -\n 1 files changed, 0 insertions(+), 1 deletions(-)\n\ndiff --git a/help.c b/help.c\nindex 1cd33ec..f539b80 100644\n--- a/help.c\n+++ b/help.c\n@@ -162,7 +162,6 @@ static void list_common_cmds_help(void)\n \t\tmput_char(' ', longest - strlen(common_cmds[i].name));\n \t\tputs(common_cmds[i].help);\n \t}\n-\tputs(\"(use 'git help -a' to get a list of all installed git commands)\");\n }\n \n static void show_man_page(const char *git_cmd)\n-- \n1.5.3.5.623.g91546-dirty\n"},{"id":"59412","messageId":"62679E54-6913-46E9-8EC5-D86A7DE2C236@develooper.com","threadId":"10792","inReplyTo":"Pine.LNX.4.64.0711112247350.4362@racer.site","subject":"Re: Deprecate git-fetch-pack?","fromName":"Ask Bjørn Hansen","fromEmail":"ask@develooper.com","sentAt":"2007-11-12T01:10:53Z","receivedAt":"2007-11-12T01:10:53Z","isPatch":false,"sender":{"key":"ask@develooper.com","avatar":"https://gravatar.com/avatar/05ce68433216df7d04bb0d82b7d93b11957e2137e6ed23c4b5bc061d78635f2f?d=mp&s=160"},"body":"\nOn Nov 11, 2007, at 2:50 PM, Johannes Schindelin wrote:\n\n> I beg to differ. The biggest problem with a new user seeing all those\n> completions is that this user is scared.\n\n\nHow about moving the plumbing commands to libexec/ or some such? (Or \nlibexec/git/ - then you can put it back in your PATH if you really \nwant easy access to run them directly).\n\nMaybe I'm being pedantic, but it's not about \"scaring the user\" -- \nit's simply that the \"visible commands\" is part of the UI and having \nit unnecessarily complex (many more commands than the user needs to \nlearn) makes it much harder to get started using git. It's a very \npractical thing.\n\nI strongly second Theodore's suggestions for cleaning up some of the \nhelp texts, too.\n\n\n - ask\n\n-- \nhttp://develooper.com/ - http://askask.com/\n"},{"id":"59415","messageId":"7vzlxk8apz.fsf@gitster.siamese.dyndns.org","threadId":"10792","inReplyTo":"1194829077-14320-1-git-send-email-tytso@mit.edu","subject":"Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-12T02:21:44Z","receivedAt":"2007-11-12T02:21:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Ts'o writes:\n\n> Remove apply, archive, cherry-pick, prune, revert, and show-branch, so\n> \"git help\" is less intimidating.\n>\n> Signed-off-by: \"Theodore Ts'o\" \n>\n> -apply\n> -archive\n> -prune\n> -revert\n> -show-branch\n\nI am fine with this list, perhaps except apply.\n\nOn the other hand, if you are shooting *really* for the absolute\nminimum set for the beginners, I would kill rm and possibly mv)\nin addition to your list:\n\n - git-rm is always easier to do with \"rm -fr file-or-dir\",\n followed by \"git commit -a\". Of course \"git rm --cached\" and\n partial commits that contain removal cannot be emulated\n easily this way, but this is an alternative suggestion to aim\n for *real* beginners who do not use the index.\n\n - git-mv is on my list for the same reason as \"rm\", but it is a\n bit more cumbersome if you want to move a directory, because\n \"mv old new && git add new\" would not work for people without\n a correctly set-up .gitignore (and if we are talking about\n beginners, we should expect user's .gitignore is borked).\n\nI have a bit of reservation about revert, but I'd imagine we\ncould kill it, and also fetch, pull and push, if you are\nshooting for *real* beginners who work alone. I think the only\nvalid justification to drop \"revert\" from the list is to assume\nthat the audience do not interact with the outside world, and\ndropping fetch/pull/push from the list is in line with that.\n"},{"id":"59426","messageId":"46dff0320711112148u59d01ff4v4fea7168c9822799@mail.gmail.com","threadId":"10792","inReplyTo":"7vzlxk8apz.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2007-11-12T05:48:33Z","receivedAt":"2007-11-12T05:48:33Z","isPatch":true,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"> I have a bit of reservation about revert, but I'd imagine we\n> could kill it, and also fetch, pull and push, if you are\n> shooting for *real* beginners who work alone. I think the only\n> valid justification to drop \"revert\" from the list is to assume\n> that the audience do not interact with the outside world, and\n> dropping fetch/pull/push from the list is in line with that.\nmany \"real\" beginners are users of CVS/svn, so the very first thing\nthey want to do is simulating the cvs/svn operation, so IMHO pull\n(update) and push(commit) should be kept.\n>\n>\n>\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>\n\n\n\n-- \nPing Yin\n"},{"id":"59428","messageId":"20071112062222.GA17462@thunk.org","threadId":"10792","inReplyTo":"7vzlxk8apz.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-11-12T06:22:22Z","receivedAt":"2007-11-12T06:22:22Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Nov 11, 2007 at 06:21:44PM -0800, Junio C Hamano wrote:\n> Theodore Ts'o writes:\n> \n> > Remove apply, archive, cherry-pick, prune, revert, and show-branch, so\n> > \"git help\" is less intimidating.\n> >\n> > Signed-off-by: \"Theodore Ts'o\" \n> >\n> > -apply\n> > -archive\n> > -prune\n> > -revert\n> > -show-branch\n> \n> I am fine with this list, perhaps except apply.\n\nI was borderline on apply, but given that people are familiar with\npatch -p1, the only real advantage git-apply has is that automatically\ndeals with new files (which \"git commit -a\" or \"git add -u\" won't\nautomatically get).\n\nWhat did you think about cherry-pick? Was that omitted by accident?\n\n> On the other hand, if you are shooting *really* for the absolute\n> minimum set for the beginners, I would kill rm and possibly mv)\n> in addition to your list:\n\nThose did cross my mind as well. :-)\n\n> I have a bit of reservation about revert, but I'd imagine we\n> could kill it, and also fetch, pull and push, if you are\n> shooting for *real* beginners who work alone. I think the only\n> valid justification to drop \"revert\" from the list is to assume\n> that the audience do not interact with the outside world, and\n> dropping fetch/pull/push from the list is in line with that.\n\nMy mental model for git newbies is that they would probably be pulling\nfrom upstream repositories (so I was tempted to remove git-init from\nthe common commands list), but they would rarely be cherry-picking or\nreverting other people's changes.\n\nThey probably would be submitting changes back upstream using e-mail\nbefore they learn how to publish their own repository, so commands I'd\nbe tempted to add would include git-format-patch, git-send-email, and\ngit-cherry. But these commands are pretty complicated for beginners....\n\n\t \t \t\t \t - Ted\n"},{"id":"59432","messageId":"7vhcjr53hp.fsf@gitster.siamese.dyndns.org","threadId":"10792","inReplyTo":"20071112062222.GA17462@thunk.org","subject":"Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-12T07:26:10Z","receivedAt":"2007-11-12T07:26:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso writes:\n\n> On Sun, Nov 11, 2007 at 06:21:44PM -0800, Junio C Hamano wrote:\n> ...\n>> I am fine with this list, perhaps except apply.\n>\n> I was borderline on apply, but given that people are familiar with\n> patch -p1, the only real advantage git-apply has is that automatically\n> deals with new files (which \"git commit -a\" or \"git add -u\" won't\n> automatically get).\n\nAlthough more importantly git-apply is much more strict and\nsafer than patch by default, that distinction will probably not\nregister with total newbies; not much would be lost if we do not\nlist git-apply, I'd guess.\n\n> What did you think about cherry-pick? Was that omitted by accident?\n\nAs \"git show | git apply --index\" would be good enough for\nsimple projects, omission of git-cherry-pick is not as serious\ncompared to ommission of git-revert, whose alternatives would be\n\"commit --amend\" and \"rebase\" which are not suitable for\npublished history.\n\n> My mental model for git newbies is that they would probably be pulling\n> from upstream repositories (so I was tempted to remove git-init from\n> the common commands list), but they would rarely be cherry-picking or\n> reverting other people's changes.\n\nI'd agree with that, but reverting and cherry-picking would also\nbe done on the commits the user builds on top of other people's\nchanges.\n\n> They probably would be submitting changes back upstream using e-mail\n> before they learn how to publish their own repository, so commands I'd\n> be tempted to add would include git-format-patch, git-send-email, and\n> git-cherry. But these commands are pretty complicated for beginners....\n\nI'd half agree with that. People coming from CVS workflow will\nbe pushing and pulling from their central repositories, without\nformat-patch and send-email. For them revert would matter more\ntogether with fetch, rebase and push.\n"},{"id":"59435","messageId":"F88B2A1B-94E6-4577-BFB8-C3985D35FD55@develooper.com","threadId":"10792","inReplyTo":"20071112062222.GA17462@thunk.org","subject":"Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive","fromName":"Ask Bjørn Hansen","fromEmail":"ask@develooper.com","sentAt":"2007-11-12T07:57:52Z","receivedAt":"2007-11-12T07:57:52Z","isPatch":true,"sender":{"key":"ask@develooper.com","avatar":"https://gravatar.com/avatar/05ce68433216df7d04bb0d82b7d93b11957e2137e6ed23c4b5bc061d78635f2f?d=mp&s=160"},"body":"\nOn Nov 11, 2007, at 10:22 PM, Theodore Tso wrote:\n\n> They probably would be submitting changes back upstream using e-mail\n> before they learn how to publish their own repository, so commands I'd\n> be tempted to add would include git-format-patch, git-send-email, and\n> git-cherry. But these commands are pretty complicated for \n> beginners....\n\nMaybe split it into sections? I'm all for making it appear simpler, \nbut not for hiding the power features of git too much. :-)\n\n\"These are basic local commands\"\n\n\"This is what you need to interact with a remote repository\"\n\n\"This is what you need for branching and merging\"\n\n\"This is what you need to make, manage and apply patches\"\n\n\n - ask\n\n-- \nhttp://develooper.com/ - http://askask.com/\n"},{"id":"59456","messageId":"473827D5.2070908@op5.se","threadId":"10792","inReplyTo":"20071111235819.GB7392@thunk.org","subject":"Re: Deprecate git-fetch-pack?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-12T10:15:49Z","receivedAt":"2007-11-12T10:15:49Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Theodore Tso wrote:\n> On Sun, Nov 11, 2007 at 10:50:26PM +0000, Johannes Schindelin wrote:\n>> I beg to differ. The biggest problem with a new user seeing all those \n>> completions is that this user is scared.\n> \n> Well, if we introduce the new user only to \"git subcomand\", and the\n> documentation is relatively gentle, I would suspect would solve most\n> of the problem. Note BTW, that if your thesis is true, \"git help -a\"\n> (which is recommended in the last line of output by \"git help\") should\n> cause the typical new user to faint dead away. :-)\n> \n> Some other areas that would be worth fixing, in terms of user usability.\n> \n> 1) The references to the tutorial, everyday git, etc., don't actually\n> have working references in the git man page. (i.e., what you see when\n> you run the command \"man git\"). It would be nice if that were fixed.\n> \n> 2) The command which are displayed by \"git help\" should use some\n> serious rethinking. Ideally, it would be nice if the output fit in a\n> single 24-line terminal window. Some candidates for removal:\n> \n> a) prune: \"git prune\" definitely doesn't deserve to be on the\n> front and center as displayed by \"git help\". Maybe replace it\n> with \"gc\", but now that we have gc.auto, I'm not sure it's\n> worth it at all.\n> \n\nprune is definitely scary, and users don't need to know about it until\nthey've worked with git for quite some time.\n\n> b) revert: Is that really that common of a command?\n> \n\nI think I've used it once ;-)\n\n> c) show-branch: The output is terrifying without explanation\n> \n\nIndeed. I still don't grok it fully. I tend to use gitk/qgit and some\nbrainpower to obtain the same result.\n\n\n> There are other commands I'm not so sure about, but it is worth\n> flagging them. One way that might be helpful is to group the commands\n> into subcommands, much like gdb does, so you could do something like\n> \"git help other-repos\" (where all commands that involve interacting\n> with other repositories are summarized), and so on.\n> \n\nAck on that. I suggested it a while back and it appears many liked the\nidea. I'm really bad at writing docs though, so it's one of those things\nI've been putting off for \"some other day\".\n\n\n>> But yes, I was only proposing to deprecate all usage of git- in the \n>> documentation.\n> \n> I agree that de-emphasizing git- isn't a bad thing. But I think\n> we need to look at the big picture here, since \"git help\" is often one\n> of the first things a new user might try (and obviously very few git\n> developers look at it, or \"prune\" probably would have been removed\n> from git help a long time ago :-), and the last thing that git help\n> suggests (and so therefore it will very visible to the newbie user),\n> is \"git help -a\" --- and that displays every single git command under\n> creation, porcelain or plumbing, in one gigantic sorted list. \n> \n> Oops, so much for first impressions. :-)\n> \n\nI agree. Culling the list output by \"git help -a\" to only show the\nporcelain commands would definitely be worthwhile. I'm not sure if it's\nworth having a way of showing every installed git command at all (I\nknow I've never used it anyway).\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"59457","messageId":"4738292E.2020103@op5.se","threadId":"10792","inReplyTo":"20071112062222.GA17462@thunk.org","subject":"Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-12T10:21:34Z","receivedAt":"2007-11-12T10:21:34Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Theodore Tso wrote:\n> \n> They probably would be submitting changes back upstream using e-mail\n> before they learn how to publish their own repository, so commands I'd\n> be tempted to add would include git-format-patch, git-send-email, and\n> git-cherry. But these commands are pretty complicated for beginners....\n> \n\ngit format-patch could probably go in, but skip the others. I've never\nused git cherry in my entire life and it's not, strictly speaking,\nnecessary for users to have it. There are other and easier ways to\nfind the same information.\n\nI'd keep cherry-pick though. It's incredibly useful, and especially\nwhen a commit ends up on the wrong branch which is something newbies\nare likely to do when they start trying out the topic-branch workflow.\nI still do it sometimes, but hardly ever stop thinking about it since\nit's so easy to fix thanks to cherry-pick.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"59458","messageId":"20071112102412.GA24803@glandium.org","threadId":"10792","inReplyTo":"7vhcjr53hp.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-12T10:24:12Z","receivedAt":"2007-11-12T10:24:12Z","isPatch":true,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sun, Nov 11, 2007 at 11:26:10PM -0800, Junio C Hamano wrote:\n> > My mental model for git newbies is that they would probably be pulling\n> > from upstream repositories (so I was tempted to remove git-init from\n> > the common commands list), but they would rarely be cherry-picking or\n> > reverting other people's changes.\n> \n> I'd agree with that, but reverting and cherry-picking would also\n> be done on the commits the user builds on top of other people's\n> changes.\n\nOn the other hand, cherry-picking and reverting are just the same thing,\nexcept one applies a reversed patch. Wouldn't it make sense to merge these\ntwo in one command ?\n\nMike\n"},{"id":"59473","messageId":"Pine.LNX.4.64.0711121222310.4362@racer.site","threadId":"10792","inReplyTo":"20071112102412.GA24803@glandium.org","subject":"Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T12:23:38Z","receivedAt":"2007-11-12T12:23:38Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 Nov 2007, Mike Hommey wrote:\n\n> On Sun, Nov 11, 2007 at 11:26:10PM -0800, Junio C Hamano wrote:\n> > > My mental model for git newbies is that they would probably be pulling\n> > > from upstream repositories (so I was tempted to remove git-init from\n> > > the common commands list), but they would rarely be cherry-picking or\n> > > reverting other people's changes.\n> > \n> > I'd agree with that, but reverting and cherry-picking would also\n> > be done on the commits the user builds on top of other people's\n> > changes.\n> \n> On the other hand, cherry-picking and reverting are just the same thing, \n> except one applies a reversed patch. Wouldn't it make sense to merge \n> these two in one command ?\n\nTechnically, they are. That's why both of them live in builtin-revert.c. \nBut conceptually, they are not. At least _I_ found it hard at first, to \naccept that reverting a patch really was a reverse cherry-picking.\n\nCiao,\nDscho\n"},{"id":"59499","messageId":"20071112152018.GA20772@thunk.org","threadId":"10792","inReplyTo":"4738292E.2020103@op5.se","subject":"Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-11-12T15:20:18Z","receivedAt":"2007-11-12T15:20:18Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Nov 12, 2007 at 11:21:34AM +0100, Andreas Ericsson wrote:\n>\n> git format-patch could probably go in, but skip the others. I've never\n> used git cherry in my entire life and it's not, strictly speaking,\n> necessary for users to have it. There are other and easier ways to\n> find the same information.\n\nHow useful it is depends on the project, definitely. The Linux kernel\ndoesn't have the \"what's cooking\" emails, and is very fast-moving, so\na day after you submit your patch set via e-mail, and then you do a\npull, and several hundred commits come spilling down from upstream,\ngit-cherry is incredibly useful to see what was accepted and what\nwasn't. :-)\n\n> I'd keep cherry-pick though. It's incredibly useful, and especially\n> when a commit ends up on the wrong branch which is something newbies\n> are likely to do when they start trying out the topic-branch workflow.\n> I still do it sometimes, but hardly ever stop thinking about it since\n> it's so easy to fix thanks to cherry-pick.\n\nHow often cherry-pick is useful is probably also very project\nspecific, and depends on how branchy a project happens to be, and how\naggressively patches get merged into the master development line. For\na project that is extremely linear, with few branches, cherry-pick is\nless useful; I didn't have any occasion to use it for quite a while,\nand certainly not while I was a git beginner.\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"59534","messageId":"1194888565.1335.1.camel@ld0161-tx32","threadId":"10792","inReplyTo":"fh8609$umn$1@ger.gmane.org","subject":"Re: Deprecate git-fetch-pack?","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2007-11-12T17:29:25Z","receivedAt":"2007-11-12T17:29:25Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Sun, 2007-11-11 at 18:16, Jakub Narebski wrote:\n\n> > c) show-branch: The output is terrifying without explanation\n> \n> I agree. I would replace it by gitk, or gui (git-gui / \"git gui\").\n\nI disagree; we should keep it. It is a very useful command,\nand usable on systems where GUI isn't an option.\n\nThanks,\njdl\n"},{"id":"59537","messageId":"Pine.LNX.4.64.0711121732000.4362@racer.site","threadId":"10792","inReplyTo":"1194888565.1335.1.camel@ld0161-tx32","subject":"Re: Deprecate git-fetch-pack?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T17:33:04Z","receivedAt":"2007-11-12T17:33:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 Nov 2007, Jon Loeliger wrote:\n\n> On Sun, 2007-11-11 at 18:16, Jakub Narebski wrote:\n> \n> > > c) show-branch: The output is terrifying without explanation\n> > \n> > I agree. I would replace it by gitk, or gui (git-gui / \"git gui\").\n> \n> I disagree; we should keep it.\n\nWe keep it. We just don't advertise it. The whole thread was not about \nremoving commands, but removing them from the output of \"git help\".\n\n> It is a very useful command, and usable on systems where GUI isn't an \n> option.\n\nYes, and those systems are the majority nowadays. Oh, wait...\n\nCiao,\nDscho\n"},{"id":"59550","messageId":"1194893799.1335.4.camel@ld0161-tx32","threadId":"10792","inReplyTo":"Pine.LNX.4.64.0711121732000.4362@racer.site","subject":"Re: Deprecate git-fetch-pack?","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2007-11-12T18:56:39Z","receivedAt":"2007-11-12T18:56:39Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Mon, 2007-11-12 at 11:33, Johannes Schindelin wrote:\n\n> > I disagree; we should keep it.\n> \n> We keep it. We just don't advertise it. The whole thread was not about \n> removing commands, but removing them from the output of \"git help\".\n\nYes, I can read an understand English; I know the context.\n\n> > It is a very useful command, and usable on systems where GUI isn't an \n> > option.\n> \n> Yes, and those systems are the majority nowadays. Oh, wait...\n\nI remotely log into my server machines frequently.\n\nAgain, though, that is just my opinion.\n\njdl\n"},{"id":"59551","messageId":"Pine.LNX.4.64.0711121905300.4362@racer.site","threadId":"10792","inReplyTo":"1194893799.1335.4.camel@ld0161-tx32","subject":"Re: Deprecate git-fetch-pack?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T19:08:51Z","receivedAt":"2007-11-12T19:08:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 Nov 2007, Jon Loeliger wrote:\n\n> On Mon, 2007-11-12 at 11:33, Johannes Schindelin wrote:\n> \n> > Jon wrote:\n> >\n> > > It [git show-branch] is a very useful command, and usable on systems \n> > > where GUI isn't an option.\n> > \n> > Yes, and those systems are the majority nowadays. Oh, wait...\n> \n> I remotely log into my server machines frequently.\n\nOkay, sorry. I was in a bad mood (you know why, I guess), and I was a \nlittle tongue-in-cheek here. I apologise.\n\nThe thing is, show-branch might be mighty useful for you, but I agree with \nanother poster that its output is not for the faint of heart, if it goes \nwithout an explanation.\n\nSo I vote for keeping relatively quiet about it in the output of \"git \nhelp\" which is -- according to some people -- the first thing new git \nusers see.\n\nPower users, such as yourself, will read in the user manual or in the FAQ \nabout the existence of this nice tool, and do not need to be reminded of \nit by git-help.\n\nFair enough?\nDscho\n"},{"id":"59552","messageId":"1194894972.1335.7.camel@ld0161-tx32","threadId":"10792","inReplyTo":"Pine.LNX.4.64.0711121905300.4362@racer.site","subject":"Re: Deprecate git-fetch-pack?","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2007-11-12T19:16:13Z","receivedAt":"2007-11-12T19:16:13Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Mon, 2007-11-12 at 13:08, Johannes Schindelin wrote:\n\n> Okay, sorry. I was in a bad mood (you know why, I guess), and I was a \n> little tongue-in-cheek here. I apologise.\n\nAnd accepted.\n\n> Fair enough?\n\nYes.\n\n> Dscho\n\nThanks,\njdl\n"}]}