{"thread":{"id":"16093","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","startedAt":"2008-10-30T03:48:05Z","lastAt":"2008-11-03T13:47:22Z","messageCount":49,"participants":["Stefan Karpinski","Pierre Habouzit","Nicolas Pitre","Theodore Tso","Shawn O. Pearce","Mike Hommey","Andreas Ericsson","Matthieu Moy","Julian Phillips","Sam Vilain","Yann Dirson","Jakub Narebski","Jeff King","Johannes Schindelin","Elijah Newren","Junio C Hamano","Kyle Moffett"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"298983","messageId":"1225338485-11046-1-git-send-email-sam@vilain.net","threadId":"16093","inReplyTo":null,"subject":"[PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-10-30T03:48:05Z","receivedAt":"2008-10-30T03:48:05Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"From: Sam Vilain \n\nFor cross-command CLI changes to be effective, they need to be\ncohesively planned. Add a planning document for this next set of\nchanges.\n\nSigned-off-by: Sam Vilain \n---\n Some suggestions, which have been briefly scanned over by some of the\n (remaining @4pm) GitTogether attendees.\n\n Please keep it constructive! :)\n\n Documentation/cli-revamp.txt | 135 ++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 135 insertions(+), 0 deletions(-)\n create mode 100644 Documentation/cli-revamp.txt\n\ndiff --git a/Documentation/cli-revamp.txt b/Documentation/cli-revamp.txt\nnew file mode 100644\nindex 0000000..980ea07\n--- /dev/null\n+++ b/Documentation/cli-revamp.txt\n@@ -0,0 +1,135 @@\n+GIT command line revamp\n+=======================\n+\n+This design document is designed for review and critique over planned\n+direction for changing the command set used by git, rather than\n+reviewing and critiquing individual changes.\n+\n+In general, old commands will be grandfathered for a year or longer,\n+and all plumbing commands will still work as originally designed.\n+\n+Please bear in mind when critiquing that each of these changes might\n+themselves have a progressive implementation, for instance the new\n+behaviour being optional initially.\n+\n+Please try to be positive with your comments; let's try to come up\n+with solutions and not argue about the details of the solutions\n+presented until those details are submitted. In particular, critical\n+comments that do not acknowledge the presence of a problem are\n+worthless at this stage.\n+\n+Add/rm/reset/checkout/revert\n+----------------------------\n+\n+Many find these confusing.\n+\n+ * 'git stage' would do what 'git add' does now.\n+\n+ * 'git unstage' would do what 'git reset --' does now\n+\n+ * 'git status' would encourage the user to use\n+ 'git diff --staged' to see staged changes as a patch\n+\n+ * 'git commit' with no changes should give useful information about\n+ using 'git stage', 'git commit -a' or 'git commit filename ...'\n+\n+ * 'git add' and 'git rm': no change\n+\n+ * 'git update-index' considered plumbing, not changed\n+\n+ * 'git revert' deprecated in favour of 'git cherry-pick --revert'\n+\n+ * 'git undo' would do what 'git checkout HEAD --' does now\n+\n+ * 'git checkout branch' would, if there is a remote branch called\n+ 'branch' on exactly one remote, do what\n+ 'git checkout -b branch thatremote/branch' does now. If it is\n+ ambiguous, it would be an error, forcing the explicit notation.\n+\n+ * 'git branch --switch' : alternative to checkout\n+\n+\n+Push/pull\n+---------\n+\n+These commands are asymmetric, and this seems mostly historical.\n+\n+ * 'git push --matching' does what 'git push' does today (without\n+ explicit configuration)\n+\n+ * 'git push' with no ref args and no 'push =' configuration does\n+ what:\n+ 'git push origin $(git symbolic-ref HEAD | sed \"s!refs/heads/!!\")'\n+ does today. ie, it only pushes the current branch.\n+ If a branch was defined in branch..push, push to that ref\n+ instead of the matching one. If there is no matching ref, and\n+ there is a branch..merge, push back there.\n+\n+ * 'git pull' behaviour unchanged\n+\n+ * 'git push' to checked out branch of non-bare repository not\n+ allowed without special configuration. Configuration available\n+ that allows working directory to be updated, known caveats\n+ notwithstanding. Ideally, it would refuse only in situations\n+ where a broken working copy would be left (because you couldn't\n+ fix it), and work when it can be known to be safe.\n+\n+\n+Informational\n+-------------\n+\n+ * 'git branch' should default to '--color=auto -v'\n+\n+ * 'git tag -l' should show more information\n+\n+\n+Working with patches\n+--------------------\n+\n+ * 'git send-email' should prompt for all SMTP-related information\n+ about sending e-mail when it is running with no configuration.\n+ Because these days /usr/lib/sendmail is rarely configured\n+ correctly.\n+\n+ * other git send-email functionality which has bitten people -\n+ particularly building the recipient list - should prompt for\n+ confirmation until configured to be automatic.\n+\n+ * 'git am -3' the default; with global option to make it not the\n+ default for those that prefer the speed of -2\n+\n+\n+Submodules\n+----------\n+\n+ * submodules should be able to refer to symbolic ref names, svn\n+ style - in the .gitmodules file. The actual commit used is still\n+ recorded in the index.\n+\n+ * when switching branches, if the checked out revision of a submodule\n+ changes, then it should be switched as well\n+\n+ * 'git submodule update' should be able to be triggered when\n+ switching branches (but not be the default behaviour)\n+\n+\n+Others\n+------\n+\n+ * 'git export' command that does what\n+ 'git archive --format=tar --prefix=dir | tar x' does now\n+\n+ * conflicted merges should point the user immediately to\n+ 'git mergetool' and mention you need to use 'git stage' to mark\n+ resolved files and 'git commit' when done.\n+\n+ * 'git init --server' (or similar) should do everything required for\n+ exporting::\n+----\n+chmod -R a+rX\n+touch git-daemon-export-ok\n+git gc\n+git update-server-info\n+chmod u+x .git/hooks/post-update\n+git config core.sharedrepository=1\n+----\n-- \ndebian.1.5.6.1\n\n"},{"id":"94273","messageId":"d4bc1a2a0810300355q42b35a35p2ba0e778691a0ab6@mail.gmail.com","threadId":"16093","inReplyTo":"1225338485-11046-1-git-send-email-sam@vilain.net","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Stefan Karpinski","fromEmail":"stefan.karpinski@gmail.com","sentAt":"2008-10-30T10:55:28Z","receivedAt":"2008-10-30T10:55:28Z","isPatch":true,"sender":{"key":"stefan.karpinski@gmail.com","avatar":"https://gravatar.com/avatar/780cfb8dd7d7dc749d7276a4ca2ec24e7f0482cfce509717c5ddd165fd2cc9d9?d=mp&s=160"},"body":"These proposed changes look great.\n\nOn Wed, Oct 29, 2008 at 8:48 PM, Sam Vilain wrote:\n\n> + * 'git unstage' would do what 'git reset --' does now\n\nWould it make sense to deprecate using \"git reset --\" for this then?\nIt's always seemed confusing to me to have such disparate\nfunctionality in the reset command.\n\n> + * 'git export' command that does what\n> + 'git archive --format=tar --prefix=dir | tar x' does now\n\nIt would be nice if the \"git export\" command could \"checkout\" a\nnon-repo copy of a remote repo at a specific version. This would be as\nsimple as calling archive on the remote size and then unarchiving it\nlocally. But would of course take care of all the plumbing.\n\n(Sorry for the resend, Sam.)\n"},{"id":"94283","messageId":"20081030132453.GB24098@artemis.corp","threadId":"16093","inReplyTo":"1225338485-11046-1-git-send-email-sam@vilain.net","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-10-30T13:24:53Z","receivedAt":"2008-10-30T13:24:53Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Thu, Oct 30, 2008 at 03:48:05AM +0000, Sam Vilain wrote:\n> +Add/rm/reset/checkout/revert\n> +----------------------------\n> +\n> +Many find these confusing.\n> +\n> + * 'git stage' would do what 'git add' does now.\n\n -> git stage -i/-p shall do what git add -i/-p does.\n\n> +\n> + * 'git unstage' would do what 'git reset --' does now\n\n -> likely we need a git unstage -i/-p to interactively unstage some\n bits.\n\n* 'git track' would do what git add -N does now.\n\n* 'git untrack' would do what 'git rm --cached' does now.\n\n> + * 'git undo' would do what 'git checkout HEAD --' does now\n\nI'm not really a fan of this one. Undo is too unspecific (I know at\nleast 2 people using that for git reset --hard HEAD~1 and 1 other for an\nalias to git reset --hard HEAD@{1}).\n\nI have no constructive proposal to replace it though, but I believe git\nundo would cause lots of harm. Would it be for another command, it\nwouldn't be a problem, but git undo *LOSES* information by design (the\nlocal changes on a file), and it would override aliases that people\ncould have done on it. Choosing it has consequences.\n\n\n> +Working with patches\n> +--------------------\n> +\n> + * 'git send-email' should prompt for all SMTP-related information\n> + about sending e-mail when it is running with no configuration.\n> + Because these days /usr/lib/sendmail is rarely configured\n> + correctly.\n\nAnd when the user answer them, it should set them (a bit like zsh does\nwhen it's run from the first time e.g.)\n\n> +\n> + * other git send-email functionality which has bitten people -\n> + particularly building the recipient list - should prompt for\n> + confirmation until configured to be automatic.\n> +\n\n * git-send-email should be either more interactive, or less: either\n just use the damn configuration, or propose a mode where it spawns\n an editor for each patch so that you can add further comments.\n\n * git-send-email should be able to format-patches by himself (IOW\n accept most of format-patch arguments and deal with the patch list\n by himself, which is usable if the previous point is implemented).\n\n> + * 'git am -3' the default; with global option to make it not the\n> + default for those that prefer the speed of -2\n> +\n> +\n> +Submodules\n> +----------\n> +\n> + * submodules should be able to refer to symbolic ref names, svn\n> + style - in the .gitmodules file. The actual commit used is still\n> + recorded in the index.\n> +\n> + * when switching branches, if the checked out revision of a submodule\n> + changes, then it should be switched as well\n> +\n> + * 'git submodule update' should be able to be triggered when\n> + switching branches (but not be the default behaviour)\n\nActually on this one, I'd say that a submodule is either non initialized\n(in which case we don't care) or it is. If it is, switching branches\nshould probably trigger a submodule update if the switch isn't possible\n(because the dereferenced sha1 doesn't exists). Or alternatively it\nshould make the whole branch switch fail.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"94288","messageId":"alpine.LFD.2.00.0810301024300.13034@xanadu.home","threadId":"16093","inReplyTo":"1225338485-11046-1-git-send-email-sam@vilain.net","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-10-30T14:34:43Z","receivedAt":"2008-10-30T14:34:43Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 29 Oct 2008, Sam Vilain wrote:\n\n> From: Sam Vilain \n> \n> For cross-command CLI changes to be effective, they need to be\n> cohesively planned. Add a planning document for this next set of\n> changes.\n> \n> Signed-off-by: Sam Vilain \n[...]\n\n> + * 'git checkout branch' would, if there is a remote branch called\n> + 'branch' on exactly one remote, do what\n> + 'git checkout -b branch thatremote/branch' does now. If it is\n> + ambiguous, it would be an error, forcing the explicit notation.\n\nI can't do otherwise but disagree with this. Currently, when a remote \nbranch is checked out, the commit corresponding to that remote branch is \nput on a detached head which is IMHO completely sane and coherent. It \neven tells you how to create a local branch from there if that's what \nyou wanted to do. So if it is still too confusing at that point then \nmore explanations are needed and not the removal of a perfectly fine \nfeature. Please don't change that behavior.\n\n\nNicolas\n"},{"id":"94289","messageId":"20081030143918.GB14744@mit.edu","threadId":"16093","inReplyTo":"1225338485-11046-1-git-send-email-sam@vilain.net","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-10-30T14:39:18Z","receivedAt":"2008-10-30T14:39:18Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Oct 29, 2008 at 08:48:05PM -0700, Sam Vilain wrote:\n> From: Sam Vilain \n> \n> For cross-command CLI changes to be effective, they need to be\n> cohesively planned. Add a planning document for this next set of\n> changes.\n\nHere are my favorites:\n\n* Add the command \"git revert-file \" which is syntactic sugar for:\n\n git checkout HEAD -- \n\n Rationale: Many other SCM's have a way of undoing local edits to a\n file very simply, i.e.\"hg revert \" or \"svn revert \", and\n for many developers's workflow, it's useful to be able to undo local\n edits to a single file, but not to everything else in the working\n directory. And \"git checkout HEAD -- \" is rather cumbersome\n to type, and many beginning users don't find it intuitive to look in\n the \"git-checkout\" man page for instructions on how to revert a\n local file.\n\n* Change the argument handling for \"git format-patch\" so it is\n consistent with everything else which takes a set of commits. Yes,\n it means that where people have gotten used to typing \"git\n format-patch origin\", they'll have to type instead: \"git\n format-patch origin..\", but's much more consistent. We've done the\n best we can by documenting the existing behavior, but if'we re going\n to make major, potentially incompatible, CLI changes, this is\n something to at least consider. Maybe with a config file for people\n who really don't want to retrain their fingers to type the two extra\n periods?\n\n\t\t\t\t\t\t- Ted\n"},{"id":"94291","messageId":"20081030144321.GF24098@artemis.corp","threadId":"16093","inReplyTo":"20081030143918.GB14744@mit.edu","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-10-30T14:43:21Z","receivedAt":"2008-10-30T14:43:21Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Thu, Oct 30, 2008 at 02:39:18PM +0000, Theodore Tso wrote:\n> On Wed, Oct 29, 2008 at 08:48:05PM -0700, Sam Vilain wrote:\n> > From: Sam Vilain \n> > \n> > For cross-command CLI changes to be effective, they need to be\n> > cohesively planned. Add a planning document for this next set of\n> > changes.\n> \n> Here are my favorites:\n> \n> * Add the command \"git revert-file \" which is syntactic sugar for:\n> \n> git checkout HEAD -- \n> \n> Rationale: Many other SCM's have a way of undoing local edits to a\n> file very simply, i.e.\"hg revert \" or \"svn revert \", and\n> for many developers's workflow, it's useful to be able to undo local\n> edits to a single file, but not to everything else in the working\n> directory. And \"git checkout HEAD -- \" is rather cumbersome\n> to type, and many beginning users don't find it intuitive to look in\n> the \"git-checkout\" man page for instructions on how to revert a\n> local file.\n\nThis is what is currently proposed for undo, but yeah, revert-file or\nmaybe rather revert-changes may be suitable.\n\n> * Change the argument handling for \"git format-patch\" so it is\n> consistent with everything else which takes a set of commits. Yes,\n> it means that where people have gotten used to typing \"git\n> format-patch origin\", they'll have to type instead: \"git\n> format-patch origin..\", but's much more consistent. We've done the\n> best we can by documenting the existing behavior, but if'we re going\n> to make major, potentially incompatible, CLI changes, this is\n> something to at least consider. Maybe with a config file for people\n> who really don't want to retrain their fingers to type the two extra\n> periods?\n\ngit format-patch origin/next.. works already. I'm used to the asymetric\ngit format-patch origin/next syntax, and I would be sorry if it\ndisappeared though, and I see no really good reason to get rid of it.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"94292","messageId":"20081030145253.GK14786@spearce.org","threadId":"16093","inReplyTo":"alpine.LFD.2.00.0810301024300.13034@xanadu.home","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-10-30T14:52:53Z","receivedAt":"2008-10-30T14:52:53Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nicolas Pitre wrote:\n> On Wed, 29 Oct 2008, Sam Vilain wrote:\n> > From: Sam Vilain \n> > \n> > For cross-command CLI changes to be effective, they need to be\n> > cohesively planned. Add a planning document for this next set of\n> > changes.\n> > \n> > Signed-off-by: Sam Vilain \n> [...]\n> \n> > + * 'git checkout branch' would, if there is a remote branch called\n> > + 'branch' on exactly one remote, do what\n> > + 'git checkout -b branch thatremote/branch' does now. If it is\n> > + ambiguous, it would be an error, forcing the explicit notation.\n> \n> I can't do otherwise but disagree with this. Currently, when a remote \n> branch is checked out, the commit corresponding to that remote branch is \n> put on a detached head which is IMHO completely sane and coherent. It \n> even tells you how to create a local branch from there if that's what \n> you wanted to do. So if it is still too confusing at that point then \n> more explanations are needed and not the removal of a perfectly fine \n> feature. Please don't change that behavior.\n\n+1 to Nico's NAK.\n\nAlthough I was at the GitTogether I don't remember this change to\ncheckout being discussed. I must have been asleep reading email\nor something. I am _NOT_ in favor of this change; I think the\ncurrent behavior of \"git checkout origin/master\" is correct and as\nsane as we can make it.\n\n-- \nShawn.\n"},{"id":"94296","messageId":"20081030145928.GA21707@glandium.org","threadId":"16093","inReplyTo":"20081030145253.GK14786@spearce.org","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-10-30T14:59:28Z","receivedAt":"2008-10-30T14:59:28Z","isPatch":true,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Thu, Oct 30, 2008 at 07:52:53AM -0700, Shawn O. Pearce wrote:\n> Nicolas Pitre wrote:\n> > On Wed, 29 Oct 2008, Sam Vilain wrote:\n> > > From: Sam Vilain \n> > > \n> > > For cross-command CLI changes to be effective, they need to be\n> > > cohesively planned. Add a planning document for this next set of\n> > > changes.\n> > > \n> > > Signed-off-by: Sam Vilain \n> > [...]\n> > \n> > > + * 'git checkout branch' would, if there is a remote branch called\n> > > + 'branch' on exactly one remote, do what\n> > > + 'git checkout -b branch thatremote/branch' does now. If it is\n> > > + ambiguous, it would be an error, forcing the explicit notation.\n> > \n> > I can't do otherwise but disagree with this. Currently, when a remote \n> > branch is checked out, the commit corresponding to that remote branch is \n> > put on a detached head which is IMHO completely sane and coherent. It \n> > even tells you how to create a local branch from there if that's what \n> > you wanted to do. So if it is still too confusing at that point then \n> > more explanations are needed and not the removal of a perfectly fine \n> > feature. Please don't change that behavior.\n> \n> +1 to Nico's NAK.\n> \n> Although I was at the GitTogether I don't remember this change to\n> checkout being discussed. I must have been asleep reading email\n> or something. I am _NOT_ in favor of this change; I think the\n> current behavior of \"git checkout origin/master\" is correct and as\n> sane as we can make it.\n\nExcept he was talking about 'git checkout branch', not 'git checkout\norigin/branch'. And I would be fine with 'git checkout branch' doing\nwhat 'git checkout -b branch $remote/branch' does if $remote is unique\n(i.e. there is no other 'branch' branch in any other remote) and the\n'branch' branch doesn't already exist.\n\nMike\n"},{"id":"94297","messageId":"20081030150135.GG24098@artemis.corp","threadId":"16093","inReplyTo":"20081030145928.GA21707@glandium.org","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-10-30T15:01:35Z","receivedAt":"2008-10-30T15:01:35Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Thu, Oct 30, 2008 at 02:59:28PM +0000, Mike Hommey wrote:\n> On Thu, Oct 30, 2008 at 07:52:53AM -0700, Shawn O. Pearce wrote:\n> > +1 to Nico's NAK.\n> > \n> > Although I was at the GitTogether I don't remember this change to\n> > checkout being discussed. I must have been asleep reading email\n> > or something. I am _NOT_ in favor of this change; I think the\n> > current behavior of \"git checkout origin/master\" is correct and as\n> > sane as we can make it.\n> \n> Except he was talking about 'git checkout branch', not 'git checkout\n> origin/branch'. And I would be fine with 'git checkout branch' doing\n> what 'git checkout -b branch $remote/branch' does if $remote is unique\n> (i.e. there is no other 'branch' branch in any other remote) and the\n> 'branch' branch doesn't already exist.\n\nSeconded.\n\nHaving git-checkout $foo being a shorthand for git checkout -b $foo\norigin/$foo when origin/$foo exists and $foo doesn't is definitely handy.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"94298","messageId":"4909CC85.1080803@op5.se","threadId":"16093","inReplyTo":"20081030143918.GB14744@mit.edu","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-30T15:02:29Z","receivedAt":"2008-10-30T15:02:29Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Theodore Tso wrote:\n> On Wed, Oct 29, 2008 at 08:48:05PM -0700, Sam Vilain wrote:\n>> From: Sam Vilain \n>>\n>> For cross-command CLI changes to be effective, they need to be\n>> cohesively planned. Add a planning document for this next set of\n>> changes.\n> \n> Here are my favorites:\n> \n> * Add the command \"git revert-file \" which is syntactic sugar for:\n> \n> git checkout HEAD -- \n> \n> Rationale: Many other SCM's have a way of undoing local edits to a\n> file very simply, i.e.\"hg revert \" or \"svn revert \", and\n> for many developers's workflow, it's useful to be able to undo local\n> edits to a single file, but not to everything else in the working\n> directory. And \"git checkout HEAD -- \" is rather cumbersome\n> to type, and many beginning users don't find it intuitive to look in\n> the \"git-checkout\" man page for instructions on how to revert a\n> local file.\n> \n\nI like it, although I guess one would have to add a \"--staged\" flag to\ngit revert-file to be able to checkout files from index as well, or people\nwill wonder why that can't be done.\n\n> * Change the argument handling for \"git format-patch\" so it is\n> consistent with everything else which takes a set of commits. Yes,\n> it means that where people have gotten used to typing \"git\n> format-patch origin\", they'll have to type instead: \"git\n> format-patch origin..\", but's much more consistent. We've done the\n> best we can by documenting the existing behavior, but if'we re going\n> to make major, potentially incompatible, CLI changes, this is\n> something to at least consider. Maybe with a config file for people\n> who really don't want to retrain their fingers to type the two extra\n> periods?\n> \n\n\"git format-patch\" does exactly the same thing as other commit-range handling\ncommands do, which is assume that the missing commit end-point is HEAD, so it\nactually is consistent, although it doesn't quite look as if it is.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"94305","messageId":"vpqmygmw1mr.fsf@bauges.imag.fr","threadId":"16093","inReplyTo":"20081030143918.GB14744@mit.edu","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-10-30T15:20:28Z","receivedAt":"2008-10-30T15:20:28Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Theodore Tso writes:\n\n> * Add the command \"git revert-file \" which is syntactic sugar for:\n>\n> git checkout HEAD -- \n\nI don't think \"revert-file\" is a good name for this: although other\nSCM often call this \"revert\", what Git calls \"revert\" is about\nreverting an existing commit (it's \"backout\" in hg for example). The\nterminology to revert the working tree to the last commited version is\nalready here in Git, it's \"reset\".\n\nI've already argued in favor of allowing \"git reset --hard \",\nwhich is consistant with existing terminology and doesn't add an extra\ncommand, but without success.\n\n-- \nMatthieu\n"},{"id":"94307","messageId":"alpine.LNX.2.00.0810301518300.13964@reaper.quantumfyre.co.uk","threadId":"16093","inReplyTo":"20081030132453.GB24098@artemis.corp","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2008-10-30T15:25:42Z","receivedAt":"2008-10-30T15:25:42Z","isPatch":true,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Thu, 30 Oct 2008, Pierre Habouzit wrote:\n\n> On Thu, Oct 30, 2008 at 03:48:05AM +0000, Sam Vilain wrote:\n>> +Working with patches\n>> +--------------------\n>> +\n>> + * 'git send-email' should prompt for all SMTP-related information\n>> + about sending e-mail when it is running with no configuration.\n>> + Because these days /usr/lib/sendmail is rarely configured\n>> + correctly.\n>\n> And when the user answer them, it should set them (a bit like zsh does\n> when it's run from the first time e.g.)\n>\n>> +\n>> + * other git send-email functionality which has bitten people -\n>> + particularly building the recipient list - should prompt for\n>> + confirmation until configured to be automatic.\n>> +\n>\n> * git-send-email should be either more interactive, or less: either\n> just use the damn configuration, or propose a mode where it spawns\n> an editor for each patch so that you can add further comments.\n>\n> * git-send-email should be able to format-patches by himself (IOW\n> accept most of format-patch arguments and deal with the patch list\n> by himself, which is usable if the previous point is implemented).\n\nThis gets my vote ...\n\nThese are two of the reasons that I ended up ignoring git-send-email and \nwriting my own replacement. I found the whole format-patch/send-email \ndance too cumbersome and confusing - particularly for sending a single \npatch. To send a single patch I ended up with the command:\n\ngit mail-commmits --edit HEAD~1\n\nIt would be nice if I could replace this with:\n\ngit send-email --edit HEAD~1\n\n;)\n\n>\n>> + * 'git am -3' the default; with global option to make it not the\n>> + default for those that prefer the speed of -2\n>> +\n>> +\n\n-- \nJulian\n\n ---\nBlessed be those who initiate lively discussions with the hopelessly mute,\nfor they shall be know as Dentists.\n"},{"id":"94311","messageId":"20081030163056.GA8899@mit.edu","threadId":"16093","inReplyTo":"20081030144321.GF24098@artemis.corp","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-10-30T16:30:56Z","receivedAt":"2008-10-30T16:30:56Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote:\n> \n> git format-patch origin/next.. works already. I'm used to the asymetric\n> git format-patch origin/next syntax, and I would be sorry if it\n> disappeared though, and I see no really good reason to get rid of it.\n\nThe reason why it annoys me is because I often what to cherry-pick a\nsingle patch to send to someone, and so while \"git show 332d2e78\"\nshows me the patch, but if I want to use git-send-email for that\nparticular patch, \"git format-patch 332d2e78\" doesn't DTRT. I have to\ntype \"git format-patch 332d2e78^..332d2e78\" instead. I've learned to\nlive with it, but it's annoying each time I have to do it.\n\nMore generally, the fact that the CLI has different ways the same set\nof arguments can be decoded can be quite confusing. The most obvious\nway this turns up is to consider which set of commits are\ndisplayed/formatted via these three commands:\n\n git format-patch 332d2e78\n git show 332d2e78\n git log -p 332d2e78\n\nThe first formats all patches that follow commit 332d2e78 (not\nincluding commit 332d2e78), the second shows just commit 332d2e78, and\nthe last prints all commits starting at 332d2e78 and before it.\n\nFor many workflows, the default way a single commit-id is interpreted\nmakes a lot of sense. But for a newcomer, it's very confusing. I'm\nnot saying that we should collapse everything down to a single way of\ndoing things, but git format-patch is an exception, and I don't think\nanything else actually works that way; looking at the man page makes\nit clear that it treats its argument as a revision range EXCEPT when\nonly a single commit is specified.\n\nIt can be justified, and maybe it's convenient enough that this is one\nof those places where tutorials should just explicitly call this out\nas one of those exceptions that make sense given common workflows.\nBut just as English can be heard to learn because \"though\", \"through\",\n\"plough\", \"cough\", and \"tough\" don't rhyme even though they look like\nthey should (even though native speakers have no problem with it),\nsimilarly this is one of those inconsistencies that makes git hard to\nlearn. \n\n(And I get annoyed when I want to run git format-patch on a single\npatch not at the tip of the tree; but if it's just me, I can write a\n\"git format-single-patch\" wrapper script to get around it.)\n\n \t \t \t\t \t \t - Ted\n"},{"id":"94313","messageId":"20081030164357.GJ24098@artemis.corp","threadId":"16093","inReplyTo":"20081030163056.GA8899@mit.edu","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-10-30T16:43:57Z","receivedAt":"2008-10-30T16:43:57Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Thu, Oct 30, 2008 at 04:30:56PM +0000, Theodore Tso wrote:\n> On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote:\n> > \n> > git format-patch origin/next.. works already. I'm used to the asymetric\n> > git format-patch origin/next syntax, and I would be sorry if it\n> > disappeared though, and I see no really good reason to get rid of it.\n> \n> The reason why it annoys me is because I often what to cherry-pick a\n> single patch to send to someone, and so while \"git show 332d2e78\"\n> shows me the patch, but if I want to use git-send-email for that\n> particular patch, \"git format-patch 332d2e78\" doesn't DTRT. I have to\n> type \"git format-patch 332d2e78^..332d2e78\" instead. I've learned to\n> live with it, but it's annoying each time I have to do it.\n[...]\n> (And I get annoyed when I want to run git format-patch on a single\n> patch not at the tip of the tree; but if it's just me, I can write a\n> \"git format-single-patch\" wrapper script to get around it.)\n\nIn fact I believe that what we lack is a shorthand for:\n\n$sha1^..$sha1 because that would solve both of your issues, and it's\nsomething that has bothered me in the past too for other commands.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"94316","messageId":"alpine.LFD.2.00.0810301105350.13034@xanadu.home","threadId":"16093","inReplyTo":"20081030150135.GG24098@artemis.corp","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-10-30T16:53:49Z","receivedAt":"2008-10-30T16:53:49Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 30 Oct 2008, Pierre Habouzit wrote:\n\n> On Thu, Oct 30, 2008 at 02:59:28PM +0000, Mike Hommey wrote:\n> > On Thu, Oct 30, 2008 at 07:52:53AM -0700, Shawn O. Pearce wrote:\n> > > +1 to Nico's NAK.\n> > > \n> > > Although I was at the GitTogether I don't remember this change to\n> > > checkout being discussed. I must have been asleep reading email\n> > > or something. I am _NOT_ in favor of this change; I think the\n> > > current behavior of \"git checkout origin/master\" is correct and as\n> > > sane as we can make it.\n> > \n> > Except he was talking about 'git checkout branch', not 'git checkout\n> > origin/branch'. And I would be fine with 'git checkout branch' doing\n> > what 'git checkout -b branch $remote/branch' does if $remote is unique\n> > (i.e. there is no other 'branch' branch in any other remote) and the\n> > 'branch' branch doesn't already exist.\n> \n> Seconded.\n> \n> Having git-checkout $foo being a shorthand for git checkout -b $foo\n> origin/$foo when origin/$foo exists and $foo doesn't is definitely handy.\n\nNo. This is only the first step towards insanity.\n\nIn many cases origin/$foo == origin/master so this can't work in that \ncase which is, after all, the common case. Therefore I think this is \nwrong to add magic operations which are not useful for the common case \nand actively _hide_ how git actually works. Not only will you have to \nexplain how git works anyway for that common origin/master case, but \nyou'll also have to explain why sometimes the magic works and sometimes \nnot. Please keep such convenience shortcuts for your own scripts and/or \naliases.\n\n\nNicolas\n"},{"id":"94317","messageId":"alpine.LFD.2.00.0810301259130.13034@xanadu.home","threadId":"16093","inReplyTo":"vpqmygmw1mr.fsf@bauges.imag.fr","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-10-30T17:00:18Z","receivedAt":"2008-10-30T17:00:18Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 30 Oct 2008, Matthieu Moy wrote:\n\n> I've already argued in favor of allowing \"git reset --hard \",\n> which is consistant with existing terminology and doesn't add an extra\n> command, but without success.\n\nIf you have a file argument, the --hard option is redundant, isn't it?\nSo what about simply \"git reset \" ?\n\n\nNicolas\n"},{"id":"94319","messageId":"alpine.LFD.2.00.0810301301510.13034@xanadu.home","threadId":"16093","inReplyTo":"20081030163056.GA8899@mit.edu","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-10-30T17:03:11Z","receivedAt":"2008-10-30T17:03:11Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 30 Oct 2008, Theodore Tso wrote:\n\n> On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote:\n> > \n> > git format-patch origin/next.. works already. I'm used to the asymetric\n> > git format-patch origin/next syntax, and I would be sorry if it\n> > disappeared though, and I see no really good reason to get rid of it.\n> \n> The reason why it annoys me is because I often what to cherry-pick a\n> single patch to send to someone, and so while \"git show 332d2e78\"\n> shows me the patch, but if I want to use git-send-email for that\n> particular patch, \"git format-patch 332d2e78\" doesn't DTRT. I have to\n> type \"git format-patch 332d2e78^..332d2e78\" instead.\n\ntry:\n\n\tgit show --pretty=email 332d2e78\n\n\nNicolas\n"},{"id":"94318","messageId":"20081030170329.GK24098@artemis.corp","threadId":"16093","inReplyTo":"alpine.LFD.2.00.0810301259130.13034@xanadu.home","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-10-30T17:03:29Z","receivedAt":"2008-10-30T17:03:29Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Thu, Oct 30, 2008 at 05:00:18PM +0000, Nicolas Pitre wrote:\n> On Thu, 30 Oct 2008, Matthieu Moy wrote:\n> \n> > I've already argued in favor of allowing \"git reset --hard \",\n> > which is consistant with existing terminology and doesn't add an extra\n> > command, but without success.\n> \n> If you have a file argument, the --hard option is redundant, isn't it?\n> So what about simply \"git reset \" ?\n\nerrrrm, git reset resets the index notion of the file to its status\nin HEAD... which I'm sure is *somehow* useful to \"some\" people ;P\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"94320","messageId":"alpine.LFD.2.00.0810301316220.13034@xanadu.home","threadId":"16093","inReplyTo":"20081030170329.GK24098@artemis.corp","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-10-30T17:17:16Z","receivedAt":"2008-10-30T17:17:16Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 30 Oct 2008, Pierre Habouzit wrote:\n\n> On Thu, Oct 30, 2008 at 05:00:18PM +0000, Nicolas Pitre wrote:\n> > On Thu, 30 Oct 2008, Matthieu Moy wrote:\n> > \n> > > I've already argued in favor of allowing \"git reset --hard \",\n> > > which is consistant with existing terminology and doesn't add an extra\n> > > command, but without success.\n> > \n> > If you have a file argument, the --hard option is redundant, isn't it?\n> > So what about simply \"git reset \" ?\n> \n> errrrm, git reset resets the index notion of the file to its status\n> in HEAD... which I'm sure is *somehow* useful to \"some\" people ;P\n\nToo bad...\n\n\nNicolas\n"},{"id":"94321","messageId":"1225387882.19891.9.camel@maia.lan","threadId":"16093","inReplyTo":"alpine.LFD.2.00.0810301105350.13034@xanadu.home","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-10-30T17:31:22Z","receivedAt":"2008-10-30T17:31:22Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Thu, 2008-10-30 at 12:53 -0400, Nicolas Pitre wrote:\n> > Seconded.\n> > \n> > Having git-checkout $foo being a shorthand for git checkout -b $foo\n> > origin/$foo when origin/$foo exists and $foo doesn't is definitely handy.\n> \n> No. This is only the first step towards insanity.\n> \n> In many cases origin/$foo == origin/master so this can't work in that \n> case which is, after all, the common case.\n\nI don't understand that argument at all, can you explain further?\n\n> Therefore I think this is \n> wrong to add magic operations which are not useful for the common case \n> and actively _hide_ how git actually works. Not only will you have to \n> explain how git works anyway for that common origin/master case, but \n> you'll also have to explain why sometimes the magic works and sometimes \n> not. Please keep such convenience shortcuts for your own scripts and/or \n> aliases.\n\nIt's not about magic, it's about sensible defaults. Currently this use\ncase is an error, and the resultant command is very long to type, and\ninvolves typing the branch name twice. I end up writing things like:\n\n git checkout -b {,origin/}wr34251-do-something\n\nFor the user who doesn't know to use the ksh-style {} blocks this is\nvoodoo. The longer form is cumbersome.\n\nFor the case where the thing you type is a resolvable reference, it\nwould just check it out, as now.\n\nSam.\n"},{"id":"94322","messageId":"1225388666.19891.22.camel@maia.lan","threadId":"16093","inReplyTo":"20081030164357.GJ24098@artemis.corp","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-10-30T17:44:26Z","receivedAt":"2008-10-30T17:44:26Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Thu, 2008-10-30 at 17:43 +0100, Pierre Habouzit wrote:\n> In fact I believe that what we lack is a shorthand for:\n> \n> $sha1^..$sha1 because that would solve both of your issues, and it's\n> something that has bothered me in the past too for other commands.\n\nThere is already a shorthand for that;\n\n $sha1^!\n\nIndeed passing that to git-format-patch has the intended effect; it\ncauses it to save a patch for just the commit in question.\n\nI agree that it would make more sense for the current behaviour to be\nchanged;\n\n git format-patch origin/master..\n\nIsn't that much more to type than:\n\n git format-patch origin/master\n\nAnd it makes the case where you just want to format a single patch work\nbetter.\n\nHowever, I worry about the backwards incompatibility. The other changes\nI listed didn't really violate existing expectations.\n\nThat being said, the case where a single commit reference is passed,\nwith no range, should be relatively easy to detect. In this situation\nit could return an error, and encourage the user to use \"--since\" or\n\"--only\"; or to configure one of those to be the default.\n\nI'm wondering whether it's worth building some kind of mechanism to\nnotice that settings like this have not been set, and to print a warning\nlike \"warning: you are using a git that introduced minor command\nchanges; use 'git config --new' to pick your defaults\" - that way,\nchanges to command operation could be introduced that would not annoy\nolder users so much.\n\nSam.\n"},{"id":"94327","messageId":"1225389068.19891.28.camel@maia.lan","threadId":"16093","inReplyTo":"20081030143918.GB14744@mit.edu","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-10-30T17:51:08Z","receivedAt":"2008-10-30T17:51:08Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Thu, 2008-10-30 at 10:39 -0400, Theodore Tso wrote:\n> * Add the command \"git revert-file \" which is syntactic sugar for:\n> \n> git checkout HEAD -- \n> \n> Rationale: Many other SCM's have a way of undoing local edits to a\n> file very simply, i.e.\"hg revert \" or \"svn revert \", and\n> for many developers's workflow, it's useful to be able to undo local\n> edits to a single file, but not to everything else in the working\n> directory. And \"git checkout HEAD -- \" is rather cumbersome\n> to type, and many beginning users don't find it intuitive to look in\n> the \"git-checkout\" man page for instructions on how to revert a\n> local file.\n\nWell, I don't have strong feelings on the exact command name used; I\nsuggested \"undo\", probably also ambiguous. But still, a significant\nnumber of users are surprised when they type 'git revert' and they get a\nbacked out patch. It's such an uncommon operation, it doesn't deserve\nto be triggered so easily. And reverting files to the state in the\nindex and/or HEAD is a common operation that deserves being short to\ntype.\n\nMaking it plain \"revert\" would violate expectations of existing users;\nit seems a better idea to just deprecate it, and point the users to the\nnew method - cherry-pick --revert - or the command they might have meant\n- whatever that becomes.\n\nSam.\n"},{"id":"94330","messageId":"1225390018.19891.38.camel@maia.lan","threadId":"16093","inReplyTo":"alpine.LFD.2.00.0810301316220.13034@xanadu.home","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-10-30T18:06:58Z","receivedAt":"2008-10-30T18:06:58Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Thu, 2008-10-30 at 13:17 -0400, Nicolas Pitre wrote:\n> > errrrm, git reset resets the index notion of the file to its status\n> > in HEAD... which I'm sure is *somehow* useful to \"some\" people ;P\n> \n> Too bad...\n\nThe changes need to not unnecessarily break scripts or let down people's\nexpectations. I'd be happy to deprecate the use of reset with file\narguments, to keep 'reset' focused on resetting the current HEAD and not\nconcerned with files; but changing its behaviour on a subtle level like\nthis is sure to annoy...\n\nSam.\n"},{"id":"94334","messageId":"alpine.LFD.2.00.0810301423520.13034@xanadu.home","threadId":"16093","inReplyTo":"1225387882.19891.9.camel@maia.lan","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-10-30T18:28:35Z","receivedAt":"2008-10-30T18:28:35Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 30 Oct 2008, Sam Vilain wrote:\n\n> On Thu, 2008-10-30 at 12:53 -0400, Nicolas Pitre wrote:\n> > > Seconded.\n> > > \n> > > Having git-checkout $foo being a shorthand for git checkout -b $foo\n> > > origin/$foo when origin/$foo exists and $foo doesn't is definitely handy.\n> > \n> > No. This is only the first step towards insanity.\n> > \n> > In many cases origin/$foo == origin/master so this can't work in that \n> > case which is, after all, the common case.\n> \n> I don't understand that argument at all, can you explain further?\n\nBy default, git creates a branch called \"master. Hence, by default, if \nyou clone that repository, this branch will be called origin/master. So \nby default $foo is already ambiguous.\n\n> > Therefore I think this is \n> > wrong to add magic operations which are not useful for the common case \n> > and actively _hide_ how git actually works. Not only will you have to \n> > explain how git works anyway for that common origin/master case, but \n> > you'll also have to explain why sometimes the magic works and sometimes \n> > not. Please keep such convenience shortcuts for your own scripts and/or \n> > aliases.\n> \n> It's not about magic, it's about sensible defaults. Currently this use\n> case is an error, and the resultant command is very long to type, and\n> involves typing the branch name twice. I end up writing things like:\n> \n> git checkout -b {,origin/}wr34251-do-something\n> \n> For the user who doesn't know to use the ksh-style {} blocks this is\n> voodoo. The longer form is cumbersome.\n\nThis is no excuse for promoting semantics only useful in such special \ncases.\n\n> For the case where the thing you type is a resolvable reference, it\n> would just check it out, as now.\n\nAs long as it checks it out with a detached head if it is a remote \nbranch then I have no issue.\n\n\nNicolas\n"},{"id":"94346","messageId":"20081030224625.GA4030@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"16093","inReplyTo":"alpine.LFD.2.00.0810301423520.13034@xanadu.home","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2008-10-30T22:46:25Z","receivedAt":"2008-10-30T22:46:25Z","isPatch":true,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Thu, Oct 30, 2008 at 02:28:35PM -0400, Nicolas Pitre wrote:\n> > It's not about magic, it's about sensible defaults. Currently this use\n> > case is an error, and the resultant command is very long to type, and\n> > involves typing the branch name twice. I end up writing things like:\n> > \n> > git checkout -b {,origin/}wr34251-do-something\n> > \n> > For the user who doesn't know to use the ksh-style {} blocks this is\n> > voodoo. The longer form is cumbersome.\n> \n> This is no excuse for promoting semantics only useful in such special \n> cases.\n\nIt is really not so rare to have an upstream repo with branches such\nas \"stable\", \"next\" and the like. This syntax extension would make is\nas straightforward to work on \"stable\" as it is on remote HEAD\n(usually master, which has already been magically setup for you).\n\n\nBTW this use case reminds me that the remote HEAD has its own special\ntreatment for \"clone\", which AFAIK cannot be overriden from\ncommand-line (I still sometimes lack what cogito provided as \"cg clone\nURL#branch\").\n\n\n> As long as it checks it out with a detached head if it is a remote \n> branch then I have no issue.\n\nYes it is possible, but that does not necessarily make a UI\nimprovement worthless.\n\nBest regards,\n-- \nYann\n"},{"id":"94349","messageId":"20081030232717.GB10779@mit.edu","threadId":"16093","inReplyTo":"1225389068.19891.28.camel@maia.lan","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-10-30T23:27:17Z","receivedAt":"2008-10-30T23:27:17Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Oct 30, 2008 at 10:51:08AM -0700, Sam Vilain wrote:\n> \n> Well, I don't have strong feelings on the exact command name used; I\n> suggested \"undo\", probably also ambiguous. But still, a significant\n> number of users are surprised when they type 'git revert' and they get a\n> backed out patch.\n\nYeah, that's why I suggested \"git revert-file\". It's less ambiguous\nthan \"undo\", and it's easier for people used to \"hg revert\" and \"svn\nrevert\" to find \"git revert-file\". And, it won't be run accidentally\nby old-timers who are used to the old (to be deprecated) \"git revert\".\nBut I'm not that picky about the name; I just missed the \"git undo\"\nproposal in your patch.\n\n> Making it plain \"revert\" would violate expectations of existing users;\n> it seems a better idea to just deprecate it, and point the users to the\n> new method - cherry-pick --revert - or the command they might have meant\n> - whatever that becomes.\n\nYup, I agree; that's why I suggested \"git revert-file\".\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"94350","messageId":"1225409309.6765.5.camel@maia.lan","threadId":"16093","inReplyTo":"alpine.LFD.2.00.0810301423520.13034@xanadu.home","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-10-30T23:28:29Z","receivedAt":"2008-10-30T23:28:29Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Thu, 2008-10-30 at 14:28 -0400, Nicolas Pitre wrote:\n> > For the case where the thing you type is a resolvable reference, it\n> > would just check it out, as now.\n> As long as it checks it out with a detached head if it is a remote \n> branch then I have no issue.\n\nAbsolutely - if you've already got a branch \"master\", then\n\"git checkout master\" should definitely give it to you. If you go\n\"git checkout origin/master\", you get a floating head. But I quite often\nfind myself wanting to check out a remote branch, and give it a name just\nlike on the remote. I want \"git checkout blah\" to assume that's\nwhat I mean, until I make a local branch \"blah\".\n\n> By default, git creates a branch called \"master. Hence, by default, if \n> you clone that repository, this branch will be called origin/master. So \n> by default $foo is already ambiguous.\n\nRight - 'master' in this case resolves to something. The ambiguity is\nresolved by defaulting to the thing that resolves. The fall-back\nbehaviour is only triggered if you asked for something that is currently\nan error. Because breaking expectations sucks.\n\nSam.\n"},{"id":"94351","messageId":"gedhh6$urq$1@ger.gmane.org","threadId":"16093","inReplyTo":"1225387882.19891.9.camel@maia.lan","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-30T23:55:17Z","receivedAt":"2008-10-30T23:55:17Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sam Vilain wrote:\n\n> It's not about magic, it's about sensible defaults.  Currently this use\n> case is an error, and the resultant command is very long to type, and\n> involves typing the branch name twice.  I end up writing things like:\n> \n>   git checkout -b {,origin/}wr34251-do-something\n\nCan't you use currently\n\n git checkout --track origin/wr34251-do-something\n\n\nP.S. Somehow I don't see first message in this thread on GMane...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"94358","messageId":"20081031003413.GB5745@sigill.intra.peff.net","threadId":"16093","inReplyTo":"20081030132453.GB24098@artemis.corp","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-31T00:34:14Z","receivedAt":"2008-10-31T00:34:14Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 30, 2008 at 02:24:53PM +0100, Pierre Habouzit wrote:\n\n> > + * 'git stage' would do what 'git add' does now.\n> -> git stage -i/-p shall do what git add -i/-p does.\n\nYes, and that is obviously easy.\n\n> > + * 'git unstage' would do what 'git reset --' does now\n> -> likely we need a git unstage -i/-p to interactively unstage some\n> bits.\n\nAgreed, though this is a bit harder. But I think this should go hand in\nhand with \"git stash -i\" and \"git stash apply -i\" (as I mentioned in my\nother mail in this thread).\n\n-Peff\n"},{"id":"94371","messageId":"1225435899.20883.25.camel@maia.lan","threadId":"16093","inReplyTo":"gedhh6$urq$1@ger.gmane.org","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-10-31T06:51:39Z","receivedAt":"2008-10-31T06:51:39Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Fri, 2008-10-31 at 00:55 +0100, Jakub Narebski wrote:\n> > involves typing the branch name twice. I end up writing things like:\n> > \n> > git checkout -b {,origin/}wr34251-do-something\n> \n> Can't you use currently\n> \n> git checkout --track origin/wr34251-do-something\n\nAh, that's a new feature. Still, I think it's poorly Huffman coded; far\ntoo verbose.\n\nBut let's resume this discussion after I dig up the old thread about\npushing and pulling too... I think it makes sense to look at this as a\nwhole.\n\nCheers,\nSam.\n"},{"id":"94373","messageId":"200810310836.02908.jnareb@gmail.com","threadId":"16093","inReplyTo":"1225435899.20883.25.camel@maia.lan","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-31T07:36:01Z","receivedAt":"2008-10-31T07:36:01Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia piątek 31. października 2008 07:51, Sam Vilain napisał:\n> On Fri, 2008-10-31 at 00:55 +0100, Jakub Narebski wrote:\n\n> > > involves typing the branch name twice. I end up writing things like:\n> > > \n> > > git checkout -b {,origin/}wr34251-do-something\n> > \n> > Can't you use currently\n> > \n> > git checkout --track origin/wr34251-do-something\n> \n> Ah, that's a new feature. Still, I think it's poorly Huffman coded; far\n> too verbose.\n\nWell, either you have a little bit more verbose, or you have to have\nsome DWIM-mery, which (as usual with DWIM) can go wrong.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"299084","messageId":"f73f7ab80810310438k3282639eta90f2a0589a12c1@mail.gmail.com","threadId":"16093","inReplyTo":"d4bc1a2a0810300355q42b35a35p2ba0e778691a0ab6@mail.gmail.com","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Kyle Moffett","fromEmail":"kyle@moffetthome.net","sentAt":"2008-10-31T11:38:19Z","receivedAt":"2008-10-31T11:38:19Z","isPatch":true,"sender":{"key":"kyle@moffetthome.net","avatar":null},"body":"On Thu, Oct 30, 2008 at 6:55 AM, Stefan Karpinski\n wrote:\n> On Wed, Oct 29, 2008 at 8:48 PM, Sam Vilain wrote:\n>> + * 'git export' command that does what\n>> + 'git archive --format=tar --prefix=dir | tar x' does now\n>\n> It would be nice if the \"git export\" command could \"checkout\" a\n> non-repo copy of a remote repo at a specific version. This would be as\n> simple as calling archive on the remote size and then unarchiving it\n> locally. But would of course take care of all the plumbing.\n\nI'm not sure whether the \"git archive | tar\" or the following is more efficient:\n\nexport GIT_INDEX_FILE=\"$(mktemp .git/export-index.XXXXXX)\"\ngit read-tree -i \"$1\"\ngit checkout-index -f -a --prefix=\"$2/\"\n\nCheers,\nKyle Moffett\n"},{"id":"94508","messageId":"alpine.DEB.1.00.0811010137020.22125@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"16093","inReplyTo":"20081030150135.GG24098@artemis.corp","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-11-01T00:37:24Z","receivedAt":"2008-11-01T00:37:24Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 30 Oct 2008, Pierre Habouzit wrote:\n\n> On Thu, Oct 30, 2008 at 02:59:28PM +0000, Mike Hommey wrote:\n> > On Thu, Oct 30, 2008 at 07:52:53AM -0700, Shawn O. Pearce wrote:\n> > > +1 to Nico's NAK.\n> > > \n> > > Although I was at the GitTogether I don't remember this change to\n> > > checkout being discussed. I must have been asleep reading email\n> > > or something. I am _NOT_ in favor of this change; I think the\n> > > current behavior of \"git checkout origin/master\" is correct and as\n> > > sane as we can make it.\n> > \n> > Except he was talking about 'git checkout branch', not 'git checkout\n> > origin/branch'. And I would be fine with 'git checkout branch' doing\n> > what 'git checkout -b branch $remote/branch' does if $remote is unique\n> > (i.e. there is no other 'branch' branch in any other remote) and the\n> > 'branch' branch doesn't already exist.\n> \n> Seconded.\n> \n> Having git-checkout $foo being a shorthand for git checkout -b $foo\n> origin/$foo when origin/$foo exists and $foo doesn't is definitely handy.\n\nHave you guys actually checked out what\n\n\tgit checkout -t origin/foo\n\ndoes?\n\nCiao,\nDscho\n"},{"id":"94573","messageId":"51419b2c0811011136uabb544g87e156631d025d33@mail.gmail.com","threadId":"16093","inReplyTo":"1225338485-11046-1-git-send-email-sam@vilain.net","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-11-01T18:36:30Z","receivedAt":"2008-11-01T18:36:30Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nGood list.. I agree with others that the 'undo' name doesn't sound\nright (and will discuss other issues with it in response to another\nemail) but otherwise nice work.\n\nOn Wed, Oct 29, 2008 at 9:48 PM, Sam Vilain wrote:\n> + * 'git push' to checked out branch of non-bare repository not\n> + allowed without special configuration. Configuration available\n> + that allows working directory to be updated, known caveats\n> + notwithstanding. Ideally, it would refuse only in situations\n> + where a broken working copy would be left (because you couldn't\n> + fix it), and work when it can be known to be safe.\n\nConfiguration of remote repository, special command-line override, or both?\n\n\nSome food for thought: One thing I did in EasyGit was to disallow\npushes to non-bare repositories* unless both source and destinations\nreferences were explicitly specified. For example:\n\n$ eg push origin master # or 'eg push', in this case\nAborting: You are trying to push to a repository with an associated working\ncopy, which will leave its working copy out of sync with its repository.\nRather than pushing changes to that repository, you should go to where that\nrepository is located and pull changes into it (using eg pull). If you\nknow what you are doing and know how to deal with the consequences, you can\noverride this check by explicitly specifying source and destination\nreferences, e.g.\n eg push REMOTE BRANCH:REMOTE_BRANCH\nPlease refer to\n eg help topic refspecs\nto learn what this syntax means and what the consequences of overriding this\ncheck are.\n\n$ eg push origin master:master\nCounting objects: 5, done.\nCompressing objects: 100% (2/2), done.\nWriting objects: 100% (3/3), 260 bytes, done.\nTotal 3 (delta 1), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nTo /home/newren/testing/dumb/.git\n 852ffee..f5596e4 master -> master\n\n\nThis seems to prevent errors for new users, while still allowing\npeople to work around firewall issues.\n\n* The big problem was that I was only able to detect if a remote\nrepository was bare or not if it was accessed via the local filesystem\nor via ssh; for git:// (or rsync://) repositories I didn't know how to\nperform such a check and so I simply omitted it.\n\n\nElijah\n"},{"id":"94578","messageId":"51419b2c0811011226p3369b7f7t37b98032ca8dd9ac@mail.gmail.com","threadId":"16093","inReplyTo":"20081030143918.GB14744@mit.edu","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-11-01T19:26:27Z","receivedAt":"2008-11-01T19:26:27Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nOn Thu, Oct 30, 2008 at 8:39 AM, Theodore Tso wrote:\n> Here are my favorites:\n>\n> * Add the command \"git revert-file \" which is syntactic sugar for:\n>\n> git checkout HEAD -- \n>\n> Rationale: Many other SCM's have a way of undoing local edits to a\n> file very simply, i.e.\"hg revert \" or \"svn revert \", and\n> for many developers's workflow, it's useful to be able to undo local\n> edits to a single file, but not to everything else in the working\n> directory. And \"git checkout HEAD -- \" is rather cumbersome\n> to type, and many beginning users don't find it intuitive to look in\n> the \"git-checkout\" man page for instructions on how to revert a\n> local file.\n\nI agree with the rationale, but the suggested implementation (as with\nthe original suggestion for \"git undo\") is somewhat problematic. I\nhave a write-up somewhere documenting the ways various individual git\ncommands fail to be an appropriate replacement for svn/hg/bzr\nrevert[1], but in short the \"git checkout HEAD -- \"\nimplementation for svn/hg/bzr-like revert fails in the following ways:\n * It does not work for the initial commit\n * It won't untrack or remove files (this is related to the previous\nand following items)\n * It doesn't allow reverting a file or directory to a revision prior\nto HEAD (making it like svn; note though that both bzr and hg have\nsuch an option and I have found it handy a few times)\n * It's inappropriate to use during an incomplete merge.\n\nThe incomplete merge case is particularly interesting. If the user\nspecifies a file or subdirectory, they should also specify a branch to\nrevert relative to (and it should be an error if they don't). If the\nuser specifies \".\" then there's the question of whether they are\nattempting to undo the merge (meaning that .git/MERGE_MSG and\n.git/MERGE_HEAD should be removed).\n\nJust as food for thought, here's what eg does in the incomplete merge case:\n\n$ eg revert foo\nAborting: Cannot revert the changes since the last commit, since you are in\nthe middle of a merge and there are multiple last commits. Please add\n --since BRANCH\nto your flags to eg revert, where BRANCH is one of\n master, devel\nIf you simply want to abort your merge and undo its conflicts, run\n eg revert --since HEAD\n\n\nThere's a couple more issues here that I could go on about, but I'll\nmention just one more thing for this email: Since users often get\nconfused between different kinds of \"reverting\" or \"undoing\", a plain\n'eg revert' is also pretty helpful in a wide variety of circumstances\n(it always aborts with an error message, but one that detects what the\nuser might want and suggests appropriate commands in the various\ncases.)\n\nElijah\n\n\n[1] There are a number of different commands that people suggest for\nnew users to replace other systems' revert behavior, but each has\nareas in which it will fail to do what users expect or do additional\nthings users don't want (including discarding data) Interestingly,\nI've tried four different alternative git porcelains and each one\nimplemented their svn/hg/bzr-like revert incorrectly. One of these\nwas EasyGit, in which I got it wrong not once but three separate\ntimes. (And if alternative porcelain authors can't easily get it\nright, we clearly can't expect normal users to know how to do so; I\nthink this is a pretty good argument for providing a function for this\nbehavior in core git.) I think I finally have it implemented\ncorrectly now in EasyGit, after my fourth try...\n"},{"id":"94580","messageId":"51419b2c0811011242k439c1504ve15dc2faff262224@mail.gmail.com","threadId":"16093","inReplyTo":"vpqmygmw1mr.fsf@bauges.imag.fr","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-11-01T19:42:40Z","receivedAt":"2008-11-01T19:42:40Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nOn Thu, Oct 30, 2008 at 9:20 AM, Matthieu Moy wrote:\n> Theodore Tso writes:\n>\n>> * Add the command \"git revert-file \" which is syntactic sugar for:\n>>\n>> git checkout HEAD -- \n>\n> I don't think \"revert-file\" is a good name for this: although other\n> SCM often call this \"revert\", what Git calls \"revert\" is about\n> reverting an existing commit (it's \"backout\" in hg for example). The\n> terminology to revert the working tree to the last commited version is\n> already here in Git, it's \"reset\".\n\ngit's reset is _not_ the same as svn/bzr/hg's revert; and it's overlap\nin functionality is smaller than you realize.\n\n> I've already argued in favor of allowing \"git reset --hard \",\n> which is consistant with existing terminology and doesn't add an extra\n> command, but without success.\n\nSuch a command would\n * delete newly added files instead of simply untracking them.\nThat's the right thing for reset, but not for a svn/bzr/hg-like revert\n(and unfortunately means unintended data loss.)\n * doesn't make sense during an incomplete merge, unless you add some\nway of specifying which branch users want to revert their files back\nto. Aren't there enough confusing flags for reset already? (One\nsurprisingly common comment I get about eg is that git reset is too\nhard to understand and eg reset fixes it -- despite the fact that I\nmerely renamed two flags and hid the second form of the command.)\n * doesn't work for the initial commit\n * provides no way to revert files or subdirectories back to their\nstate at some previous revision (hg and bzr revert have a flag to\nprovide this; it's not useful all the time but is on occasion) Also,\nif users try to modify their command slightly to get such behavior,\nsay 'git reset --hard REVISION' instead of 'git reset --hard .', then\nthey're in trouble. (Recoverable, but they need an 'expert' to help\nthem now.)\n\n\nAlso, there's three different kinds of \"undo\": switching to an old\nrevision (git checkout REVISION, or svn/hg update -r, etc.),\nforgetting or discarding commits/merges/rebases (git reset), and\nmodifying files to undo previous modifications without touching HEAD\n(svn/bzr/hg revert). Users get confused enough between these\ndifferent kinds of undo; overloading them further would be really bad,\nIMO.\n\n(Part of the reason for users getting confused between these kinds of\nundo is the fact that git doesn't implemented svn/bzr/hg-like revert,\nand tends to steer them towards git checkout and git reset, which are\ncommands typically meant for the *other* kinds of undo.)\n\n\nJust my $0.02,\nElijah\n"},{"id":"94583","messageId":"51419b2c0811011257v74a75053la59755e7dabe2f09@mail.gmail.com","threadId":"16093","inReplyTo":"4909CC85.1080803@op5.se","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-11-01T19:57:54Z","receivedAt":"2008-11-01T19:57:54Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nOn Thu, Oct 30, 2008 at 9:02 AM, Andreas Ericsson wrote:\n> I like it, although I guess one would have to add a \"--staged\" flag to\n> git revert-file to be able to checkout files from index as well, or people\n> will wonder why that can't be done.\n\nEw. 'git revert-file --staged foo'? If you want to revert the\n*unstaged* changes of a file, it should be 'git revert-file --unstaged\nfoo'.\nI would expect 'git revert-file --staged foo' to revert the staged\nchanges in foo, i.e. it should do what 'git reset -- foo' does (except\nthat it should also work for the initial commit). Thus, there'd be\nlittle need for a --staged flag to revert-file, unless we allowed\nreverting individual files back to some revision prior to HEAD (like\nbzr and hg do)...\n"},{"id":"94588","messageId":"51419b2c0811011327j492b520dq2388fc8972b48cab@mail.gmail.com","threadId":"16093","inReplyTo":"1225389068.19891.28.camel@maia.lan","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-11-01T20:27:03Z","receivedAt":"2008-11-01T20:27:03Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\n(Sorry for sending so many emails, and being late to the conversation.\n There's a couple others that I wanted to respond to but I'll wait off\non those and finish with this email to avoid spamming everyone any\nmore right now.)\n\nOn Thu, Oct 30, 2008 at 11:51 AM, Sam Vilain wrote:\n> Well, I don't have strong feelings on the exact command name used; I\n> suggested \"undo\", probably also ambiguous. But still, a significant\n> number of users are surprised when they type 'git revert' and they get a\n> backed out patch. It's such an uncommon operation, it doesn't deserve\n> to be triggered so easily. And reverting files to the state in the\n> index and/or HEAD is a common operation that deserves being short to\n> type.\n>\n> Making it plain \"revert\" would violate expectations of existing users;\n> it seems a better idea to just deprecate it, and point the users to the\n> new method - cherry-pick --revert - or the command they might have meant\n> - whatever that becomes.\n\nThere is another option, though it has its own problems too. There\nare basically two kinds of reverting here -- reverting all the changes\n*in* a given revision (which I'll called 'revert-in') and reverting\nall the changes *since* a given revision (typically HEAD; I'll call\nthis 'revert-since'). These two operations can be supported from the\nsame command, though their use cases are different enough that it may\nseem slightly weird:\n\n revert-since revert-in\n * is usually used in a dirty tree * is typically used in a clean tree\n * specific paths are usually * specific paths are not often\n specified specified\n * it is rare to want to commit * making a commit after reverting\n immediately after reverting is what you usually want\n * it is uncommon to need to\n specify a revision\n\nI decided to combine them in EasyGit, simply because that made things\nthe most discoverable for both existing git and svn/bzr/hg users. The\nbig problem here is that --commit is turned on by default when --in is\nspecified, and --no-commit is the default when --since is specified.\nAnyway, some examples:\n\neg revert REVISION => Error -- you must specify either --since or\n--in when specifying a revision\neg revert --in REVISION => Same as git revert REVISION\neg revert --since HEAD FILE1 FILE2 => Same as svn revert FILE1 FILE2\neg revert FILE1 FILE2 => shorthand for the previous command; --since\nHEAD is default when no revision is specified\neg revert --since HEAD~3 SUBDIRECTORY => should be clear; an extension\nover what svn revert can do\n\nThen there's also the possibility that users only want to revert\nunstaged changes, or only want to revert staged changes...\n\n\nAnyway, just some food for thought. I've spammed the list enough in\nthis thread, so I'll break for now. Thanks for listening.\n\nElijah\n"},{"id":"94608","messageId":"20081102010634.GF8134@mit.edu","threadId":"16093","inReplyTo":"51419b2c0811011327j492b520dq2388fc8972b48cab@mail.gmail.com","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-11-02T01:06:34Z","receivedAt":"2008-11-02T01:06:34Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Nov 01, 2008 at 02:27:03PM -0600, Elijah Newren wrote:\n> \n> There is another option, though it has its own problems too. There\n> are basically two kinds of reverting here -- reverting all the changes\n> *in* a given revision (which I'll called 'revert-in') and reverting\n> all the changes *since* a given revision (typically HEAD; I'll call\n> this 'revert-since'). These two operations can be supported from the\n> same command, though their use cases are different enough that it may\n> seem slightly weird:\n\nIn my opinion, that is a Really Bad Idea from a usability and UI\ndesign point of view. Each command should do one and only one thing,\nand not do different things depending on what options you give it.\nGit violates this rules in a number of places already, What you call\n\"revert-since\" and \"revert-in\" are so different that using the same\nsubcommand is just going to horribly confuse users.\n\nBetter to have \"git revert\" print a message explining that it is\ndeprecated, and to tell users that they probably want either \"git\ncherry-pick --revert\" or \"git revert-file\", depending on whether they\nare an experienced git user (in which case they probably want git\ncherry-pick --revert\"), or if that person who is familiar svn or hg's\n\"svn revert\" or \"hg revert\", they probably want \"git revert-file\".\n\n \t \t \t \t \t - Ted\n"},{"id":"94628","messageId":"51419b2c0811012141x1620f111rbebc836f816c7b4e@mail.gmail.com","threadId":"16093","inReplyTo":"20081102010634.GF8134@mit.edu","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-11-02T04:41:17Z","receivedAt":"2008-11-02T04:41:17Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sat, Nov 1, 2008 at 7:06 PM, Theodore Tso wrote:\n> In my opinion, that is a Really Bad Idea from a usability and UI\n> design point of view. Each command should do one and only one thing,\n> and not do different things depending on what options you give it.\n> Git violates this rules in a number of places already, What you call\n> \"revert-since\" and \"revert-in\" are so different that using the same\n> subcommand is just going to horribly confuse users.\n>\n> Better to have \"git revert\" print a message explining that it is\n> deprecated, and to tell users that they probably want either \"git\n> cherry-pick --revert\" or \"git revert-file\", depending on whether they\n> are an experienced git user (in which case they probably want git\n> cherry-pick --revert\"), or if that person who is familiar svn or hg's\n> \"svn revert\" or \"hg revert\", they probably want \"git revert-file\".\n\nYeah, good points. I guess I could just make --no-commit the default\nin all cases to remove the \"magic\", but then it's too much typing for\nthe revert-in case (\"eg revert --commit --in REVISION\" vs. \"git revert\nREVISION\"). Two separate commands may make more sense, but then\nthere's the naming issue (I had difficulty coming up with a different\nname that I liked, and it appears others are having a little trouble\nwith the naming too). Tough nut to crack from any angle. :-(\n"},{"id":"94632","messageId":"7v1vxu4q49.fsf@gitster.siamese.dyndns.org","threadId":"16093","inReplyTo":"20081030163056.GA8899@mit.edu","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-02T06:08:06Z","receivedAt":"2008-11-02T06:08:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso writes:\n\n> On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote:\n>> \n>> git format-patch origin/next.. works already. I'm used to the asymetric\n>> git format-patch origin/next syntax, and I would be sorry if it\n>> disappeared though, and I see no really good reason to get rid of it.\n>\n> The reason why it annoys me is because I often what to cherry-pick a\n> single patch to send to someone, and so while \"git show 332d2e78\"\n> shows me the patch, but if I want to use git-send-email for that\n> particular patch, \"git format-patch 332d2e78\" doesn't DTRT. I have to\n> type \"git format-patch 332d2e78^..332d2e78\" instead.\n> ...\n> (And I get annoyed when I want to run git format-patch on a single\n> patch not at the tip of the tree; but if it's just me, I can write a\n> \"git format-single-patch\" wrapper script to get around it.)\n\nHuh? I am so used to \"git format-patch -1 HEAD\" (or \"332d2e78\") that I am\nvery surprised.\n"},{"id":"94654","messageId":"20081102100915.GI8134@mit.edu","threadId":"16093","inReplyTo":"7v1vxu4q49.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-11-02T10:09:15Z","receivedAt":"2008-11-02T10:09:15Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Nov 01, 2008 at 11:08:06PM -0700, Junio C Hamano wrote:\n> > (And I get annoyed when I want to run git format-patch on a single\n> > patch not at the tip of the tree; but if it's just me, I can write a\n> > \"git format-single-patch\" wrapper script to get around it.)\n> \n> Huh? I am so used to \"git format-patch -1 HEAD\" (or \"332d2e78\") that I am\n> very surprised.\n\nWell, the explanation is that \"-\" isn't in the SYNPOSIS section of\n'git format-patch', and so I never knew you could do it that way. A\nnew user of git has to paw through approximately 50 options in the\nOPTIONS section of the man page before finding \"-\"; and somehow\nI've always missed it. I'd suggest adding an explicit mention of -\nto the DESCRIPTION section, perhaps in the paragraph:\n\n A single commit, when interpreted as a expression,\n means \"everything that leads to that commit\", but if you write git\n format-patch , the previous rule applies to that command\n line and you do not get \"everything since the beginning of the\n time\". If you want to format everything since project inception to\n one commit, say \"git format-patch --root \" to make it clear\n that it is the latter case.\n\nAdding the sentence:\n\n If you want to format a single commit, you can do this via \n \"git format-patch -1 \" or the more esoteric and perl-ish,\n \"git format-patch ^!\"\n\nmight be helpful.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"94694","messageId":"7vy70123rr.fsf@gitster.siamese.dyndns.org","threadId":"16093","inReplyTo":"20081030132453.GB24098@artemis.corp","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-02T21:53:44Z","receivedAt":"2008-11-02T21:53:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pierre Habouzit writes:\n\n> * 'git track' would do what git add -N does now.\n> * 'git untrack' would do what 'git rm --cached' does now.\n\nOk with me up to here.\n\n>> + * 'git undo' would do what 'git checkout HEAD --' does now\n> ...\n> I have no constructive proposal to replace it though, but I believe git\n> undo would cause lots of harm.\n\nI'm in agreement.\n\n> * git-send-email should be either more interactive, or less: either\n> just use the damn configuration, or propose a mode where it spawns\n> an editor for each patch so that you can add further comments.\n\nIn principle I'd agree, but I use send-email non-interactively myself (I\ntype Meta/SE where Meta is an independent checkout of my 'todo' branch),\nso I am not sure if the \"just use the configuration\" is an added\nrequirement. I also have this in .git/config in the repo:\n\n [sendemail]\n smtpserver = /usr/bin/msmtp\n to = git@vger.kernel.org\n suppressfrom\n signedoffcc = false\n\n> * git-send-email should be able to format-patches by himself (IOW\n> accept most of format-patch arguments and deal with the patch list\n> by himself, which is usable if the previous point is implemented).\n\nI earlier was against this, mostly out of the \"each tool to do the job it\nwas designed to do well\" principle, but with your workflow description and\nPeff's comment, I am open to add this kind of \"run format-patch internally\"\nwrapper behaviour to send-email which is already a Porcelain anyway.\n\n>> + * 'git am -3' the default; with global option to make it not the\n>> + default for those that prefer the speed of -2\n\nI am moderately negative on this, but not because of performance concern.\n\nThe --3way fall back is done only when it is necessary, and there is no\n\"prefer the speed\" involved. It is between \"stop when the patch does not\napply because there may be something iffy going on\" and \"assume it is Ok\nin such an iffy case to pretend that you apply the patch to the original\ncopy and cherry-pick the result to your updated tree\". IOW, it is a\nsafety concern.\n"},{"id":"94695","messageId":"7vtzap23f3.fsf@gitster.siamese.dyndns.org","threadId":"16093","inReplyTo":"20081030143918.GB14744@mit.edu","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-02T22:01:20Z","receivedAt":"2008-11-02T22:01:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso writes:\n\n> Here are my favorites:\n>\n> * Add the command \"git revert-file \" which is syntactic sugar for:\n>\n> git checkout HEAD -- \n\nThis is good; I do not recall offhand what we do if some of the do\nnot appear in HEAD right now, but I have a suspicion that it would be a\nno-op, in which case interested parties may first want to fix checkout to\nremove such paths.\n\nAlso I thiink you can add \"git revert-commit [$committish]\" as a synonym\nto the current \"git revert [$committish]\" if it makes things easier to\nexplain to others.\n\n> * Change the argument handling for \"git format-patch\" so it is\n> consistent with everything else which takes a set of commits. Yes,\n> it means that where people have gotten used to typing \"git\n> format-patch origin\", they'll have to type instead: \"git\n> format-patch origin..\", but's much more consistent.\n\nI think that has already happened some time ago in the sense that you can\nsay \"origin..\" and it does what you want. I do not think it merits to\ndeprecate the original one --- if you do not like it, you do not use it\nnor teach it to others.\n"},{"id":"94696","messageId":"7vabch22ou.fsf@gitster.siamese.dyndns.org","threadId":"16093","inReplyTo":"20081030170329.GK24098@artemis.corp","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-02T22:17:05Z","receivedAt":"2008-11-02T22:17:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pierre Habouzit writes:\n\n> On Thu, Oct 30, 2008 at 05:00:18PM +0000, Nicolas Pitre wrote:\n>\n>> If you have a file argument, the --hard option is redundant, isn't it?\n>> So what about simply \"git reset \" ?\n>\n> errrrm, git reset resets the index notion of the file to its status\n> in HEAD... which I'm sure is *somehow* useful to \"some\" people ;P\n\nI'd agree that 'reset' is rather unfortunate. It very originally was all\nabout the index (the \"mixed\" semantics, specifically \"git reset\" without\nany committish nor any pathspec, was the original use case) and nothing\nelse. IOW, \"I staged a wrong change, let's start over by discarding all\nstaged changes\". A logical extension to it is \"git reset -- pathspec\",\nIOW, \"I know which paths I fubared, please reset only these paths, as\nother staged changes are Ok\".\n\nSo \"reset \" is very much useful.\n\nThen 'reset' learned to also muck with HEAD, so \"reset HEAD^\" (still\nmixed, without any pathspec) can be used to amend the latest commit but\nwithout losing the state you would eventually want to arrive at. A\nlogical extension to this was \"git reset --hard HEAD^\" to nuking instead\nof amending the mistake, and \"git reset --soft HEAD^\" to save the trouble\nof staging the changes when the mistake you are fixing is small compared\nto the entire change.\n\n\"checkout [$committish] $path\" came much later, and the command is all\nabout index and files, and never about resetting HEAD. \"checkout $path\"\ndoes \"reset --hard $path\" (notice there is no $committish in either one)\nwould have done, so we stopped enhancing the \"reset\" command in that\ndirection.\n"},{"id":"94716","messageId":"1225692071.20883.44.camel@maia.lan","threadId":"16093","inReplyTo":"7vabch22ou.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-11-03T06:01:11Z","receivedAt":"2008-11-03T06:01:11Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Sun, 2008-11-02 at 14:17 -0800, Junio C Hamano wrote:\n> I'd agree that 'reset' is rather unfortunate. It very originally was all\n> about the index (the \"mixed\" semantics, specifically \"git reset\" without\n> any committish nor any pathspec, was the original use case) and nothing\n> else. IOW, \"I staged a wrong change, let's start over by discarding all\n> staged changes\". A logical extension to it is \"git reset -- pathspec\",\n> IOW, \"I know which paths I fubared, please reset only these paths, as\n> other staged changes are Ok\".\n> \n> So \"reset \" is very much useful.\n> \n> Then 'reset' learned to also muck with HEAD, so \"reset HEAD^\" (still\n> mixed, without any pathspec) can be used to amend the latest commit but\n> without losing the state you would eventually want to arrive at. A\n> logical extension to this was \"git reset --hard HEAD^\" to nuking instead\n> of amending the mistake, and \"git reset --soft HEAD^\" to save the trouble\n> of staging the changes when the mistake you are fixing is small compared\n> to the entire change.\n> \n> \"checkout [$committish] $path\" came much later, and the command is all\n> about index and files, and never about resetting HEAD. \"checkout $path\"\n> does \"reset --hard $path\" (notice there is no $committish in either one)\n> would have done, so we stopped enhancing the \"reset\" command in that\n> direction.\n\nInteresting.\n\nI'm wondering whether the important thing here is not making a new\ncommand, but simply deprecating \"revert\", and pointing the user to \"git\nreset\" - then making sure that you can do everything revert-like (eg, as\nElijah points out) from that command.\n\nSam.\n"},{"id":"94728","messageId":"1225701813.20883.85.camel@maia.lan","threadId":"16093","inReplyTo":"200810310836.02908.jnareb@gmail.com","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-11-03T08:43:33Z","receivedAt":"2008-11-03T08:43:33Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Fri, 2008-10-31 at 08:36 +0100, Jakub Narebski wrote:\n> > > git checkout --track origin/wr34251-do-something\n> > \n> > Ah, that's a new feature. Still, I think it's poorly Huffman coded; far\n> > too verbose.\n> \n> Well, either you have a little bit more verbose, or you have to have\n> some DWIM-mery, which (as usual with DWIM) can go wrong.\n\nThat's right, you need to choose when to assume that the user meant\nsomething that they didn't write very carefully.\n\nBut look at this:\n\n git checkout origin/master\n\n git checkout -t origin/master\n\nThe option is called \"--track\", yet in this case what it actually means\nin the default situation where you have autosetupmerge (or whatever it's\nreally called) set to true, is that it modifies the command to imply \"-b\nmaster\". So, in this situation, that is clearly what was meant.\n\nPerhaps you can give an example of why this particular piece of DWIM\nmight not be WYM?\n\nSam.\n"},{"id":"94750","messageId":"200811031306.28615.jnareb@gmail.com","threadId":"16093","inReplyTo":"1225701813.20883.85.camel@maia.lan","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-11-03T12:06:27Z","receivedAt":"2008-11-03T12:06:27Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia poniedziałek 3. listopada 2008 09:43, Sam Vilain napisał:\n> On Fri, 2008-10-31 at 08:36 +0100, Jakub Narebski wrote:\n\n> > > > git checkout --track origin/wr34251-do-something\n> > > \n> > > Ah, that's a new feature. Still, I think it's poorly Huffman coded; far\n> > > too verbose.\n> > \n> > Well, either you have a little bit more verbose, or you have to have\n> > some DWIM-mery, which (as usual with DWIM) can go wrong.\n> \n> That's right, you need to choose when to assume that the user meant\n> something that they didn't write very carefully.\n> \n> But look at this:\n> \n> git checkout origin/master\n> \n> git checkout -t origin/master\n> \n> The option is called \"--track\", yet in this case what it actually means\n> in the default situation where you have autosetupmerge (or whatever it's\n> really called) set to true, is that it modifies the command to imply \"-b\n> master\". So, in this situation, that is clearly what was meant.\n> \n> Perhaps you can give an example of why this particular piece of DWIM\n> might not be WYM?\n\nI was not talking about \"git checkout -t origin/master\" being shortcut\nfor \"git checkout -b master -t origin/master\", but about proposed\nDWIM-mery for \"git checkout -b \" which would be\n\n { git checkout -b -t /\n git checkout -b = { if there exists / \n {\n { git checkout -b HEAD\n { otherwise\n-- \nJakub Narebski\nPoland\n"},{"id":"94760","messageId":"20081103134722.GF13930@artemis.corp","threadId":"16093","inReplyTo":"7vy70123rr.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-11-03T13:47:22Z","receivedAt":"2008-11-03T13:47:22Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Nov 02, 2008 at 09:53:44PM +0000, Junio C Hamano wrote:\n> Pierre Habouzit writes:\n> > * git-send-email should be either more interactive, or less: either\n> > just use the damn configuration, or propose a mode where it spawns\n> > an editor for each patch so that you can add further comments.\n> \n> In principle I'd agree, but I use send-email non-interactively myself (I\n> type Meta/SE where Meta is an independent checkout of my 'todo' branch),\n> so I am not sure if the \"just use the configuration\" is an added\n> requirement. I also have this in .git/config in the repo:\n> \n> [sendemail]\n> smtpserver = /usr/bin/msmtp\n> to = git@vger.kernel.org\n> suppressfrom\n> signedoffcc = false\n\nWell with my patches it goes _more_ interactive on request only, so that\nwouldn't break your setup (you have to explicitely pass --annotated\nand/or --compose). Okay arguably not the feature that auto enables\n--compose on series of more than 1 patch, but you can redirect\nsend-email to | cat or pass --no-compose for that. Or we can drop that\nbit of the patch if people find it too cumbersome, I can put that in an\nalias I don't really care.\n\nI really _care_ about not breaking send-email for its previous uses.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"}]}