{"thread":{"id":"16104","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","startedAt":"2008-10-31T00:31:54Z","lastAt":"2008-11-05T22:53:27Z","messageCount":25,"participants":["Jeff King","Sam Vilain","Pierre Habouzit","Johannes Schindelin","Theodore Tso","Junio C Hamano","Jakub Narebski","Sverre Rabbelier","Dmitry Potapov"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"94357","messageId":"20081031003154.GA5745@sigill.intra.peff.net","threadId":"16104","inReplyTo":"20081030002239.D453B21D14E@mail.utsl.gen.nz","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-31T00:31:54Z","receivedAt":"2008-10-31T00:31:54Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 29, 2008 at 05:22:00PM -0700, Sam Vilain wrote:\n\n> Some suggestions, which have been briefly scanned over by some of the\n> (remaining) GitTogether attendees. Please keep it constructive! :)\n\nThanks for putting this together.\n\n> + * 'git stage' would do what 'git add' does now.\n> +\n> + * 'git unstage' would do what 'git reset --' does now\n\nThese seem reasonable.\n\n> + * 'git status' would encourage the user to use\n> + 'git diff --staged' to see staged changes as a patch\n\nI notice the commit template message getting longer and longer. Maybe it\nis time for status.verbosetemplate (which could default to true, I just\nwant to be able to turn it off).\n\n> + * 'git commit' with no changes should give useful information about\n> + using 'git stage', 'git commit -a' or 'git commit filename ...'\n\nThere is already infrastructure that figures out exactly what the\nsituation is (no changes versus changes in untracked files versus\nchanges in unstaged files), so it should just be a matter of tweaking\nthe messages.\n\n> + * 'git add' and 'git rm': no change\n> +\n> + * 'git update-index' considered plumbing, not changed\n\nDefinitely.\n\n> + * 'git revert' deprecated in favour of 'git cherry-pick --revert'\n\nI think I would make it \"-R, --reverse\", since it really is analagous to\n\"git diff -R\".\n\n> + * 'git undo' would do what 'git checkout HEAD --' does now\n\nThis is an awful name, IMHO. It doesn't point out _what_ you're undoing,\nso it leaves me with the feeling that you can undo arbitrary things.\nI think the name needs to be considered along with related operations.\n\nSo think of us as having three \"spots\": the HEAD (H), the \"stage\"[1] (S),\nand the working tree (W). And we want commands for moving content\nbetween them. Now we have:\n\n W->S: add\n H->S: reset --\n S->W: checkout --\n S->H: commit (no paths)\n\nAnd if you want to include things that jump the staging area:\n\n W->H: commit (paths or -a)\n H->W: checkout HEAD --\n\nSo I think with your stage/unstage, we have:\n\n W->S: stage\n H->S: unstage\n S->W: ?\n S->H: commit (no paths)\n W->H: commit (paths or -a)\n H->W: ?\n\nSo I think we can note something: movement commands are related based on\ntheir _destination_. So since both of the missing ones impact the\nworking tree, they should have a related name.\n\nBut do note the difference between \"stage vs unstage\" as opposed to\n\"commit versus commit -a\". I think this is because the stage sits in the\nmiddle. So it is mentally \"which direction are changes coming from\" and\nnot \"how _far_ are changes coming from\".\n\nSo by that rationale, we should have a single command which says \"put\nstuff in the working tree\", with a flag for \"from HEAD\" versus \"from the\nstaging area.\" And that's what we have right now with \"git checkout\".\nThe real problem with it is that it is an overload of checkout's other\nbehavior of switching branches.\n\nSo what I am saying is \"git undo\" _must_ support both \"put index content\ninto working tree\" as well as \"put HEAD content into working tree\", or\nit will be a step backwards in consistency.\n\nSo I guess that doesn't really suggest a name. But \"undo\" is awful. ;P\n\nSide note: there are actually _other_ places you might want to move\ncontent. Like a stash. So now you can think of it as:\n\n stash\n ^ ^\n / \\\n / \\\n v v\n HEAD <--> stage <--> working tree\n\nSo maybe we just need a \"git content\" command. And then you can \"git\ncontent --from=HEAD --to=tree \" or \"git content --from=tree\n--to=stash\", with all equally supporting \"--interactive\". And of course\nI am kidding, because typing that would be awful. But I think\nconceptually, it makes sense. To me, anyway.\n\n> + * 'git branch --switch' : alternative to checkout\n\nBlech. I think switching branches is the one thing that checkout does\nunconfusedly. And this is much more typing. Not to mention that So I\nwould rather see \"git switch\" if checkout is somehow unpalatable.\n\nBut I don't know that it is. This seems like an attempt to say \"branch\noperations should all be part of 'git branch'\". But checkout isn't\nnecessarily a branch operation. Consider detaching HEAD to a tag. Should\nit be \"git tag --switch\"?\n\n> + * 'git push --matching' does what 'git push' does today (without\n> + explicit configuration)\n\nI think this is reasonable even without other changes, just to override\nany 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\nThere was a thread between me and Junio some months ago that touched on\nthis. I don't remember all of the arguments, but it was resolved to keep\nthe current behavior. Any proposal along these lines should at least\nrevisit and respond to those arguments.\n\n> + * 'git push' to checked out branch of non-bare repository not\n> + allowed without special configuration. Configuration available\n\nI have this patch done and sitting in my repo, but I need to add the\n\"without special configuration\" bit and add tests and docs.\n\n> +Informational\n> +-------------\n> +\n> + * 'git branch' should default to '--color=auto -v'\n\nThis should at least be configurable (even if it defaults to \"on\"). \"-v\"\nis more expensive, and not always wanted.\n\nI, for one, just use \"git branch\" to get the current branch. I don't\nknow of a more obvious way to ask for it (and please don't mention an\never-changing bash prompt).\n\n> + * 'git tag -l' should show more information\n\nI remember somebody talking about this, but not the details. Which\ninformation?\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 would prefer that personally. I think Linus has been very reasonable\nin the past about recognizing that his workflow and speed requirements\naren't always typical, and being willing to accept setting a\nconfiguration flag in those cases. So I think if he ack'd such a patch,\nnobody else would complain.\n\n> + * 'git export' command that does what\n> + 'git archive --format=tar --prefix=dir | tar x' does now\n\nI agree, if you mean \"does what ... does now\" means \"looks to the user\nlike ... is happening\". This is much more sanely done using\ngit-checkout-index (though somebody suggested \"remote export\", which\nwould need to use tar itself).\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\nBut not all of those things are necessarily related, and some of them\nhave security implications. I would hate to get a bug report like \"I\nused --server because I wanted to share my content via dumb http, but my\nrepo was p0wned because of too-loose group permissions.\"\n\n-Peff\n"},{"id":"94370","messageId":"1225435238.20883.18.camel@maia.lan","threadId":"16104","inReplyTo":"20081031003154.GA5745@sigill.intra.peff.net","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-10-31T06:40:38Z","receivedAt":"2008-10-31T06:40:38Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Thu, 2008-10-30 at 20:31 -0400, Jeff King wrote:\n> > Some suggestions, which have been briefly scanned over by some of the\n> > (remaining) GitTogether attendees. Please keep it constructive! :)\n> Thanks for putting this together.\n\nNo problem! Thanks for responding. I've been amazed that it seems to\nhave been largely taken well :) But there are still very important\nchanges required.\n\n> > + * 'git status' would encourage the user to use\n> > + 'git diff --staged' to see staged changes as a patch\n> \n> I notice the commit template message getting longer and longer. Maybe it\n> is time for status.verbosetemplate (which could default to true, I just\n> want to be able to turn it off).\n\nRight. We'll have to work through that when we look at how 'git status'\noutput is displayed. There may be some people who parse the existing\noutput, but they should get to read the release notes about the proper\nways to do that. I think the whole output could do with a shake-up.\n\n> > + * 'git undo' would do what 'git checkout HEAD --' does now\n> This is an awful name, IMHO. It doesn't point out _what_ you're undoing,\n\nAs others have said, yes.\n\n> So I think with your stage/unstage, we have:\n> \n> W->S: stage\n> H->S: unstage\n> S->W: ?\n> S->H: commit (no paths)\n> W->H: commit (paths or -a)\n> H->W: ?\n> \n> So I think we can note something: movement commands are related based on\n> their _destination_. So since both of the missing ones impact the\n> working tree, they should have a related name.\n\nAn interesting observation.\n\nI still think it's OK to use 'git revert-files' for this; it just seems\nso long. Switches could specify where to and from.\n\n> Side note: there are actually _other_ places you might want to move\n> content. Like a stash. So now you can think of it as:\n> \n> stash\n> ^ ^\n> / \\\n> / \\\n> v v\n> HEAD <--> stage <--> working tree\n> \n> So maybe we just need a \"git content\" command. And then you can \"git\n> content --from=HEAD --to=tree \" or \"git content --from=tree\n> --to=stash\", with all equally supporting \"--interactive\". And of course\n> I am kidding, because typing that would be awful. But I think\n> conceptually, it makes sense. To me, anyway.\n\nAgain interesting, you could look at the stash as a whole bunch of\nstaged commits yet to happen. Of course, adding a file when the version\nin HEAD doesn't match the version in the base of the stash is a bit\ninsane, so should probably be an error.\n\nI'll have a ponder over this and whether there is a simple word for this\nall.\n\n> > + * 'git branch --switch' : alternative to checkout\n> \n> Blech. I think switching branches is the one thing that checkout does\n> unconfusedly. And this is much more typing. Not to mention that So I\n> would rather see \"git switch\" if checkout is somehow unpalatable.\n>\n> But I don't know that it is. This seems like an attempt to say \"branch\n> operations should all be part of 'git branch'\". But checkout isn't\n> necessarily a branch operation. Consider detaching HEAD to a tag. Should\n> it be \"git tag --switch\"?\n\nYou're right with all that. I don't think that it is necessarily wrong\nto have two ways to get at functionality, depending on whether you start\nwith the noun or the verb first; so long as it doesn't introduce\nconfusion. And if anything, I think --switch is wrong; --checkout is\nprobably more consistent.\n\nI think I might have to mark this one as [maybe], and make it --checkout\n- as you say, it would need to go on all the other commands that are\nnouns and able to be checked out to be consistent. Let's see how that\nlooks in round 2.\n\n> > + * 'git push --matching' does what 'git push' does today (without\n> > + explicit configuration)\n> \n> I think this is reasonable even without other changes, just to override\n> any configuration.\n\nExcellent, I have another vote towards this push sanity! :)\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> There was a thread between me and Junio some months ago that touched on\n> this. I don't remember all of the arguments, but it was resolved to keep\n> the current behavior. Any proposal along these lines should at least\n> revisit and respond to those arguments.\n\nRight. So, before round 2, I'll read and attempt to summarise that\nthread - assuming I can find it! :)\n\n> > + * 'git push' to checked out branch of non-bare repository not\n> > + allowed without special configuration. Configuration available\n> I have this patch done and sitting in my repo, but I need to add the\n> \"without special configuration\" bit and add tests and docs.\n\nLooking forward to that! Thanks.\n\n> > + * 'git branch' should default to '--color=auto -v'\n> This should at least be configurable (even if it defaults to \"on\"). \"-v\"\n> is more expensive, and not always wanted.\n> \n> I, for one, just use \"git branch\" to get the current branch. I don't\n> know of a more obvious way to ask for it (and please don't mention an\n> ever-changing bash prompt).\n\nWhat's wrong with 'git symbolic-ref HEAD' ? *ducks*\n\nOf course 'git branch -q' would then be the quick version, or 'git\nbr' (after git config --global alias.br 'branch -q')\n\nAnother command people often want is 'git info' to tell them stuff like\nthey might get from 'git status' or 'git remote' but without all the\nfile details...\n\n> > + * 'git tag -l' should show more information\n> \n> I remember somebody talking about this, but not the details. Which\n> information?\n\nOh, good point. Basically the same stuff that 'git branch -v' shows; in\nany case, its behaviour should be relatively consistent compared to 'git\nbranch'.\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> \n> But not all of those things are necessarily related, and some of them\n> have security implications. I would hate to get a bug report like \"I\n> used --server because I wanted to share my content via dumb http, but my\n> repo was p0wned because of too-loose group permissions.\"\n\nok. That should come down to the detail of how '--server' is specified,\nI think. I'll expand on that during round 2.\n\nSam.\n"},{"id":"94377","messageId":"20081031082015.GA21015@artemis.corp","threadId":"16104","inReplyTo":"1225435238.20883.18.camel@maia.lan","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-10-31T08:20:15Z","receivedAt":"2008-10-31T08:20:15Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Fri, Oct 31, 2008 at 06:40:38AM +0000, Sam Vilain wrote:\n> On Thu, 2008-10-30 at 20:31 -0400, Jeff King wrote:\n> > > Some suggestions, which have been briefly scanned over by some of the\n> > > (remaining) GitTogether attendees. Please keep it constructive! :)\n> > Thanks for putting this together.\n> \n> No problem! Thanks for responding. I've been amazed that it seems to\n> have been largely taken well :) But there are still very important\n> changes required.\n\nWell, most of it we discussed IRL, that helps tremendously ;)\n\n> I still think it's OK to use 'git revert-files' for this; it just seems\n> so long. Switches could specify where to and from.\n\nWell the point is we will probably just deprecate git-revert and remove\nit alltogether in git 2.6. At that time you will be able to define\ngit-revert as an alias to git cherry-pick -R if you're an old fart, or\ngit revert-files if you're an svn user ;)\n\nBut I see no convincing name that hasn't \"revert\" in them, hence will be\nlong :/\n\n> Of course 'git branch -q' would then be the quick version, or 'git\n> br' (after git config --global alias.br 'branch -q')\n\noh no, not -q please, -q is quiet, -h is help, -v is verbose. I mean\nPOSIX should define these. Do not give those switch any other kind of\nsementics anymore, we've done that, and it hurts. -Q is fine with me\nthough.\n\n> Another command people often want is 'git info' to tell them stuff like\n> they might get from 'git status' or 'git remote' but without all the\n> file details...\n\nAnd to say to them if they're in the midle of a merge, of a rebase, an\nam, on a detached, head, .... what is in the __git_ps1 of bash actually.\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> > \n> > But not all of those things are necessarily related, and some of them\n> > have security implications. I would hate to get a bug report like \"I\n> > used --server because I wanted to share my content via dumb http, but my\n> > repo was p0wned because of too-loose group permissions.\"\n> \n> ok. That should come down to the detail of how '--server' is specified,\n> I think. I'll expand on that during round 2.\n\nWhat about git init --svn-like ? /me *ducks*\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"94416","messageId":"alpine.DEB.1.00.0810311745030.22125@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"16104","inReplyTo":"20081031003154.GA5745@sigill.intra.peff.net","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-10-31T16:46:35Z","receivedAt":"2008-10-31T16:46:35Z","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, Jeff King wrote:\n\n> On Wed, Oct 29, 2008 at 05:22:00PM -0700, Sam Vilain wrote:\n> \n> > + * 'git branch --switch' : alternative to checkout\n> \n> Blech. I think switching branches is the one thing that checkout does \n> unconfusedly. And this is much more typing. Not to mention that So I \n> would rather see \"git switch\" if checkout is somehow unpalatable.\n\nYou know, I asked for this because a _user_ told me \"Guess how long it \ntook me to find out how to check out a branch!\".\n\nI think if you are not confused by CVS/SVN, the name \"checkout\" is utterly \nunintuitive.\n\nCiao,\nDscho\n"},{"id":"94619","messageId":"20081102034224.GA5261@coredump.intra.peff.net","threadId":"16104","inReplyTo":"alpine.DEB.1.00.0810311745030.22125@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-02T03:42:24Z","receivedAt":"2008-11-02T03:42:24Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 31, 2008 at 05:46:35PM +0100, Johannes Schindelin wrote:\n\n> > > + * 'git branch --switch' : alternative to checkout\n> > \n> > Blech. I think switching branches is the one thing that checkout does \n> > unconfusedly. And this is much more typing. Not to mention that So I \n> > would rather see \"git switch\" if checkout is somehow unpalatable.\n> \n> You know, I asked for this because a _user_ told me \"Guess how long it \n> took me to find out how to check out a branch!\".\n> \n> I think if you are not confused by CVS/SVN, the name \"checkout\" is utterly \n> unintuitive.\n\nOK. I am not opposed to such a change as long as:\n\n - this is not just _a_ user, but a _common_ user confusion. IOW, I\n don't recall this complaint coming up a lot (or at least not nearly\n as often as other ones do). But maybe you have more data.\n\n - it is done consistently.\n\n My initial \"blech\" was a little premature, as I was thinking \"instead\n of checkout\", though it does clearly say \"alternative\" there.\n\n However, (and somebody else in the thread very cleverly came up with\n this analysis, not me), this is basically going from \"verb the noun\"\n to \"noun --verb\". And that's reasonable, if users think in terms of\n nouns. But we should be consistent in applying that transformation,\n and make it available for other nouns that match that verb. In other\n words, \"git tag --switch\". And however one might manipulate remote\n tracking branches (\"git branch -r --switch\", I guess).\n\n Personally I find it somewhat backwards, but I think CVS rotted my\n brain long ago.\n\n-Peff\n"},{"id":"94621","messageId":"20081102035310.GA5357@coredump.intra.peff.net","threadId":"16104","inReplyTo":"20081031003154.GA5745@sigill.intra.peff.net","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-02T03:53:10Z","receivedAt":"2008-11-02T03:53:10Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 30, 2008 at 08:31:54PM -0400, Jeff King wrote:\n\n> So think of us as having three \"spots\": the HEAD (H), the \"stage\"[1] (S),\n> and the working tree (W). And we want commands for moving content\n\nRe-reading this, I realized I forgot to fill in my footnote. But it was\ngoing to be:\n\n [1] Actually, the term \"the stage\" is growing on me.\n\n-Peff\n"},{"id":"94623","messageId":"20081102041832.GB5261@coredump.intra.peff.net","threadId":"16104","inReplyTo":"1225435238.20883.18.camel@maia.lan","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-02T04:18:33Z","receivedAt":"2008-11-02T04:18:33Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 30, 2008 at 11:40:38PM -0700, Sam Vilain wrote:\n\n> > I notice the commit template message getting longer and longer. Maybe it\n> > is time for status.verbosetemplate (which could default to true, I just\n> > want to be able to turn it off).\n> Right. We'll have to work through that when we look at how 'git status'\n> output is displayed. There may be some people who parse the existing\n> output, but they should get to read the release notes about the proper\n> ways to do that. I think the whole output could do with a shake-up.\n\nMaybe I am wrong, but I thought at some point we decided that parsing\nthe output of \"git status\" was insane and wrong, since it's porcelain.\nOTOH, it is also an easy way for editors to see what is happening in a\ncommit whose message you are editing (and to do, for example, syntax\nhighlighting on it). So it may be that it is getting parsed anyway.\n\n> [moving content from HEAD or index to working tree]\n> I still think it's OK to use 'git revert-files' for this; it just seems\n> so long. Switches could specify where to and from.\n\nYeah, revert-files is pretty painful to type. And I'm not looking\nforward to fielding UI questions about \"why isn't it just revert?\" :)\n\nSomebody suggested \"clobber\", which I think is a bit _too_ intense.\n\nI guess something like \"retrieve\" is too ambiguous. You really need\nsomething that implies movement of content, and something that implies\nthe working directory. \"Checkout\" is actually not a bad name; if only we\nhad \"git switch\" instead of \"git checkout\" for switching branches, it\nwould be perfect.\n\nSo I am a bit stumped. Maybe \"clobber\" is not so bad. ;)\n\n> Again interesting, you could look at the stash as a whole bunch of\n> staged commits yet to happen. Of course, adding a file when the version\n> in HEAD doesn't match the version in the base of the stash is a bit\n> insane, so should probably be an error.\n> \n> I'll have a ponder over this and whether there is a simple word for this\n> all.\n\nWhether or not we come up with a simple word, I think it makes sense to\nexpose this through \"git stash -i\" (since, after all, we are just\nputting stuff into an index there).\n\n> You're right with all that. I don't think that it is necessarily wrong\n> to have two ways to get at functionality, depending on whether you start\n> with the noun or the verb first; so long as it doesn't introduce\n> confusion. And if anything, I think --switch is wrong; --checkout is\n> probably more consistent.\n\nAgreed on --checkout. I think your \"noun or verb\" comment hits the nail\nright on the head. I wonder if there are other places where\nfunctionality can be exposed in either direction (I think we already\nhave some in \"git fetch \" versus \"git remote update\").\n\n> > There was a thread between me and Junio some months ago that touched on\n> > this. I don't remember all of the arguments, but it was resolved to keep\n> > the current behavior. Any proposal along these lines should at least\n> > revisit and respond to those arguments.\n> \n> Right. So, before round 2, I'll read and attempt to summarise that\n> thread - assuming I can find it! :)\n\nI think it was \"Minor annoyance with git push\" from this past February.\nQuite a long thread, but there is some in this subthread:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/73038/focus=73208\n\n> Another command people often want is 'git info' to tell them stuff like\n> they might get from 'git status' or 'git remote' but without all the\n> file details...\n\nYeah, I don't know if you have followed the other threads in the past\nmonth or so, but I think there is some desire for a \"new\" status with\na nicer format.\n\nAnd I think it might be nice to structure it as a long list of things it\n_can_ report on, and then let you tweak those with command-line options\nand config settings. E.g., I might set info.currentbranch, info.staged,\nand info.untracked because that is what _I_ like to see to get a sense\nof what is happening in the repo.\n\nAnd I will get around to designing that after I clear the other 100\nthings off my todo list. ;)\n\n> > > + * 'git tag -l' should show more information\n> > I remember somebody talking about this, but not the details. Which\n> > information?\n> Oh, good point. Basically the same stuff that 'git branch -v' shows; in\n> any case, its behaviour should be relatively consistent compared to 'git\n> branch'.\n\nOK, that makes sense to me. I think of \"git tag -l\" as plumbing-ish,\nthough, so we might be breaking people's scripts (yes, I know the \"real\"\nplumbing for this is for-each-ref, but it really is a pain to parse the\ntags out of that versus \"for i in `git tag -l`\").\n\n-Peff\n"},{"id":"94653","messageId":"20081102095658.GH8134@mit.edu","threadId":"16104","inReplyTo":"20081102041832.GB5261@coredump.intra.peff.net","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-11-02T09:56:58Z","receivedAt":"2008-11-02T09:56:58Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Nov 02, 2008 at 12:18:33AM -0400, Jeff King wrote:\n> \n> Yeah, revert-files is pretty painful to type. And I'm not looking\n> forward to fielding UI questions about \"why isn't it just revert?\" :)\n> \n\nAt least for me, I don't use it *that* often, so it's not that painful\nfor me (I have it as an \"git revert-file\" as an alias already). \n\nAnd the answer, \"because 'git revert' used to do something else\" is I\nthink a perfectly reasonable answer. I probably do \"git revert-files\"\nabout 3-5 times more often than I do \"git revert\", so it's a bit\nstrange from a character count perspective, but history is history.\n\n> Somebody suggested \"clobber\", which I think is a bit _too_ intense.\n> \n> I guess something like \"retrieve\" is too ambiguous. You really need\n> something that implies movement of content, and something that implies\n> the working directory. \"Checkout\" is actually not a bad name; if only we\n> had \"git switch\" instead of \"git checkout\" for switching branches, it\n> would be perfect.\n\nIf people really want a shorter name, how about bk's \"unedit\"? I'd\nstill worry about people being able to find it, since the reality is\nthat most of the world knows this command as revert, though.\n\n \t \t \t \t \t \t - Ted\n"},{"id":"94698","messageId":"7v3ai9226q.fsf@gitster.siamese.dyndns.org","threadId":"16104","inReplyTo":"20081031003154.GA5745@sigill.intra.peff.net","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:27:57Z","receivedAt":"2008-11-02T22:27:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> + * 'git push --matching' does what 'git push' does today (without\n>> + explicit configuration)\n>\n> I think this is reasonable even without other changes, just to override\n> any configuration.\n\nI don't. Can't you say \"git push $there HEAD\" these days? I vaguely\nrecall that there is a way to configure push that way for people too lazy\nto type \"origin HEAD\" after \"git push\".\n\n>> + * 'git export' command that does what\n>> + 'git archive --format=tar --prefix=dir | tar x' does now\n>\n> I agree, if you mean \"does what ... does now\" means \"looks to the user\n> like ... is happening\". This is much more sanely done using\n> git-checkout-index (though somebody suggested \"remote export\", which\n> would need to use tar itself).\n\nI think I was neutral in the discussion that led to the removal of\n\"git-export\", but the rationale IIRC was exactly because \"git-export\" can\nbe done by simply piping \"git-tar\" to tar. On the other hand, if all you\nhad was \"export\" and you wanted to create a release tar/zip ball, you have\nto first create a (potentially huge) hierarchy in the filesystem only to\narchive it. This change needs to defend that the benefit of being able to\ncreate a new non-git checkout elsewhere on the filesystem far outweighs\nthe downside of addition of another command (i.e. \"eek, why does git have\nthat many commands\" from new people).\n"},{"id":"94715","messageId":"1225691960.20883.41.camel@maia.lan","threadId":"16104","inReplyTo":"7v3ai9226q.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-03T05:59:20Z","receivedAt":"2008-11-03T05:59:20Z","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:27 -0800, Junio C Hamano wrote:\n> Jeff King writes:\n> \n> >> + * 'git push --matching' does what 'git push' does today (without\n> >> + explicit configuration)\n> >\n> > I think this is reasonable even without other changes, just to override\n> > any configuration.\n> \n> I don't. Can't you say \"git push $there HEAD\" these days? I vaguely\n> recall that there is a way to configure push that way for people too lazy\n> to type \"origin HEAD\" after \"git push\".\n\nI don't think it's about laziness, it's more about making sure that\nwithout specifying behaviour, the action of the command is conservative.\nPushing all matching refs is not conservative; it's \"magic\". And in my\nexperience, people get bitten by it, because they think, \"ok, time to\npush this branch\", type \"git push\" and then a lot more than they\nexpected gets pushed.\n\nI can see that some people want this behaviour by default; but to me\n\"push the current branch back to where it came from\" seems like far more\na rational default for at least 90% of users.\n\nSam.\n"},{"id":"94722","messageId":"20081103065636.GB10772@coredump.intra.peff.net","threadId":"16104","inReplyTo":"7v3ai9226q.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-03T06:56:37Z","receivedAt":"2008-11-03T06:56:37Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 02, 2008 at 02:27:57PM -0800, Junio C Hamano wrote:\n\n> >> + * 'git push --matching' does what 'git push' does today (without\n> >> + explicit configuration)\n> >\n> > I think this is reasonable even without other changes, just to override\n> > any configuration.\n> \n> I don't. Can't you say \"git push $there HEAD\" these days? I vaguely\n> recall that there is a way to configure push that way for people too lazy\n> to type \"origin HEAD\" after \"git push\".\n\nI think you are reading more into my statement than I intended. I meant\nthat adding an explicit --matching was reasonable, _even if it matches\nthe default_. I can think of two reasons:\n\n 1. Even if it is a no-op, it is more explicit for showing newbies what\n is going on. And it also means that _if_ we wanted to introduce\n new behavior or configurability, we will have already had\n \"--matching\" for some time. So it will be safe(r) at that point to\n immediately start saying \"--matching\" in your scripts to specify the\n behavior you want, without as much worry about confusing an older\n version.\n\n 2. Even today, the behavior of push can be modified with configuration\n in remote.*.mirror. I would expect \"git push --matching\" to override\n this. Though perhaps that is too confusing a behavior, as mirroring\n does more than just ref selection, including force-updating.\n\nSo my statement was not anything about \"git push $there HEAD\", but just\nthat adding \"--matching\" was reasonable.\n\n> I think I was neutral in the discussion that led to the removal of\n> \"git-export\", but the rationale IIRC was exactly because \"git-export\" can\n> be done by simply piping \"git-tar\" to tar. On the other hand, if all you\n> had was \"export\" and you wanted to create a release tar/zip ball, you have\n> to first create a (potentially huge) hierarchy in the filesystem only to\n> archive it. This change needs to defend that the benefit of being able to\n> create a new non-git checkout elsewhere on the filesystem far outweighs\n> the downside of addition of another command (i.e. \"eek, why does git have\n> that many commands\" from new people).\n\nI think the complaint is just that it is awkward to have to pipe to tar\n(and harder to check error status), when \"export to directory\" is a\nreasonably common request.\n\nIf the concern is about another command, then perhaps rather than \"git\nexport\" it would be simpler to have \"git archive --format=dir\" as a\nconvenience (and it could even use the checkout-index optimization in\nthe local case, rather than generating a tar).\n\n-Peff\n"},{"id":"94723","messageId":"20081103065941.GA10961@coredump.intra.peff.net","threadId":"16104","inReplyTo":"20081103065636.GB10772@coredump.intra.peff.net","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-03T06:59:41Z","receivedAt":"2008-11-03T06:59:41Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 03, 2008 at 01:56:36AM -0500, Jeff King wrote:\n\n> So my statement was not anything about \"git push $there HEAD\", but just\n> that adding \"--matching\" was reasonable.\n\nAnd btw, I am not saying I necessarily disagree with Sam's proposal\nabout bare \"git push\". I am undecided about the best course of action\nthere.\n\nI just wanted to make clear that it was not what I was talking about in\nthe original mail.\n\n-Peff\n"},{"id":"94733","messageId":"20081103092507.GD13930@artemis.corp","threadId":"16104","inReplyTo":"7v3ai9226q.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-03T09:25:07Z","receivedAt":"2008-11-03T09:25:07Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Nov 02, 2008 at 10:27:57PM +0000, Junio C Hamano wrote:\n> Jeff King writes:\n> \n> >> + * 'git push --matching' does what 'git push' does today (without\n> >> + explicit configuration)\n> >\n> > I think this is reasonable even without other changes, just to override\n> > any configuration.\n> \n> I don't. Can't you say \"git push $there HEAD\" these days? I vaguely\n> recall that there is a way to configure push that way for people too lazy\n> to type \"origin HEAD\" after \"git push\".\n\nYes, but it's broken in the sense that if you're in a non matching\nbranch it creates it remotely. The way to configure it is to say\nremote.push = HEAD in your .gitconfig or sth similar. I removed it\nbecause I've created 2 times a new branch remotely that I didn't want to\nbecause I was tired and forgot to checkout and merge into the proper\none.\n\nI rarely do mistakes with git, but something like more than half of my\nmistakes are with push. I've argued that in the past, I know most of the\nother core git developers disagree with the fact that git-push UI is not\nhelping users to not shoot themselves in the foot, I disagree, but there\nis not much I can do if I'm 1:10 to think that ;)\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"94739","messageId":"gemhdp$lev$1@ger.gmane.org","threadId":"16104","inReplyTo":"1225691960.20883.41.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-03T09:48:41Z","receivedAt":"2008-11-03T09:48:41Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sam Vilain wrote:\n> On Sun, 2008-11-02 at 14:27 -0800, Junio C Hamano wrote:\n>> Jeff King writes:\n>> \n>>>> + * 'git push --matching' does what 'git push' does today (without\n>>>> + explicit configuration)\n>>>\n>>> I think this is reasonable even without other changes, just to override\n>>> any configuration.\n>> \n>> I don't. Can't you say \"git push $there HEAD\" these days? I vaguely\n>> recall that there is a way to configure push that way for people too lazy\n>> to type \"origin HEAD\" after \"git push\".\n> \n> I don't think it's about laziness, it's more about making sure that\n> without specifying behaviour, the action of the command is conservative.\n> Pushing all matching refs is not conservative; it's \"magic\". And in my\n> experience, people get bitten by it, because they think, \"ok, time to\n> push this branch\", type \"git push\" and then a lot more than they\n> expected gets pushed.\n> \n> I can see that some people want this behaviour by default; but to me\n> \"push the current branch back to where it came from\" seems like far more\n> a rational default for at least 90% of users.\n\n\"git remote push\" for push matching?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"94741","messageId":"bd6139dc0811030153o669a2cfax6fb9ef5e6d3e294e@mail.gmail.com","threadId":"16104","inReplyTo":"gemhdp$lev$1@ger.gmane.org","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-11-03T09:53:01Z","receivedAt":"2008-11-03T09:53:01Z","isPatch":true,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Mon, Nov 3, 2008 at 10:48, Jakub Narebski wrote:\n> \"git remote push\" for push matching?\n\nNot another command that is made to perform yet another piece of\nfuncionality. Let's let remote handle (configuring, and maintaining\nof) remote related things, not also make it do push stuff.\nUnless ofcourse, you mean that \"git remote push \" (certainly\nnot the other way around) is for configuration only.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"94824","messageId":"7v4p2ov0zt.fsf@gitster.siamese.dyndns.org","threadId":"16104","inReplyTo":"20081103092507.GD13930@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-03T23:33:10Z","receivedAt":"2008-11-03T23:33:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pierre Habouzit writes:\n\n> On Sun, Nov 02, 2008 at 10:27:57PM +0000, Junio C Hamano wrote:\n>> Jeff King writes:\n>> \n>> >> + * 'git push --matching' does what 'git push' does today (without\n>> >> + explicit configuration)\n>> >\n>> > I think this is reasonable even without other changes, just to override\n>> > any configuration.\n>> \n>> I don't. Can't you say \"git push $there HEAD\" these days? I vaguely\n>> recall that there is a way to configure push that way for people too lazy\n>> to type \"origin HEAD\" after \"git push\".\n>\n> Yes, but it's broken in the sense that if you're in a non matching\n> branch it creates it remotely.\n\nOk, I agree that may be a problem.\n\nBut that would not change if you only changed the default behaviour from\nmatching to _this branch_. You need to also teach a new mode of operation\nto send-pack/receive-pack pair, which is to \"update the same branch as the\none I am on locally, but do not do anything if there is no such branch\nover there\". I do not think we have such a mode of operation currently.\n\nBy the way, didn't we add a feature to let you say \"git push $there :\"\nwhich is to do what \"git push --matching $there\" would do?\n"},{"id":"94828","messageId":"20081104000207.GA29458@artemis.corp","threadId":"16104","inReplyTo":"7v4p2ov0zt.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-04T00:02:07Z","receivedAt":"2008-11-04T00:02:07Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Mon, Nov 03, 2008 at 11:33:10PM +0000, Junio C Hamano wrote:\n> Pierre Habouzit writes:\n> \n> > On Sun, Nov 02, 2008 at 10:27:57PM +0000, Junio C Hamano wrote:\n> >> Jeff King writes:\n> >> \n> >> >> + * 'git push --matching' does what 'git push' does today (without\n> >> >> + explicit configuration)\n> >> >\n> >> > I think this is reasonable even without other changes, just to override\n> >> > any configuration.\n> >> \n> >> I don't. Can't you say \"git push $there HEAD\" these days? I vaguely\n> >> recall that there is a way to configure push that way for people too lazy\n> >> to type \"origin HEAD\" after \"git push\".\n> >\n> > Yes, but it's broken in the sense that if you're in a non matching\n> > branch it creates it remotely.\n> \n> Ok, I agree that may be a problem.\n> \n> But that would not change if you only changed the default behaviour from\n> matching to _this branch_. You need to also teach a new mode of operation\n> to send-pack/receive-pack pair, which is to \"update the same branch as the\n> one I am on locally, but do not do anything if there is no such branch\n> over there\". I do not think we have such a mode of operation currently.\n\nYou're right.\n\n> By the way, didn't we add a feature to let you say \"git push $there :\"\n> which is to do what \"git push --matching $there\" would do?\n\nI don't know, I thought git push --matching $remote would be the same as\ngit push $remote ?\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"94832","messageId":"7vljw0tj49.fsf@gitster.siamese.dyndns.org","threadId":"16104","inReplyTo":"20081104000207.GA29458@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-04T00:44:38Z","receivedAt":"2008-11-04T00:44:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pierre Habouzit writes:\n\n>> Ok, I agree that may be a problem.\n>> \n>> But that would not change if you only changed the default behaviour from\n>> matching to _this branch_. You need to also teach a new mode of operation\n>> to send-pack/receive-pack pair, which is to \"update the same branch as the\n>> one I am on locally, but do not do anything if there is no such branch\n>> over there\". I do not think we have such a mode of operation currently.\n>\n> You're right.\n\nPerhaps \"git push --no-create\"?\n\nIn hindsight, _if_ we did not have to worry about backward compatibility\nat all, I might agree that the way \"git push\" ought to work with least\nsurprise would be:\n\n * \"git push\" is the same as \"git push origin\" (override 'origin' with\n branch.$current_branch.remote);\n\n * \"git push $remote\" is the same as \"git push --no-create $remote HEAD\"\n (override 'HEAD' with remote.$remote.push);\n\n * \"git push $remote $any_non_empty_refspec\" does what it is told without\n configuration interfering.\n\nCurrent behaviour satisfies the first one and the third one. Instead of\nthe second, the current behaviour is:\n\n * \"git push $remote\" is the same as \"git push $remote :\" (override ':'\n with remote.$remote.push).\n\n>> By the way, didn't we add a feature to let you say \"git push $there :\"\n>> which is to do what \"git push --matching $there\" would do?\n>\n> I don't know, I thought git push --matching $remote would be the same as\n> git push $remote ?\n\nI think the point of \"push --matching\" (or an explicit \"push $there :\") is\nso that you can defeat what you configured. For example, you could have:\n\n\t[branch \"master\"]\n \tremote = gitster\n\t[remote \"gitster\"]\n \turl = gitster:/pub/git/git.git/\n push = HEAD\n\nAnd with such a configuration, \"git push\" or \"git push gitster\" would only\npush to the current branch.\n\nYou can countermand with \"push gitster master next\", of course, but you\nwould need a way to ask for the matching from the command line without\nlisting all the names, hence you would say \"push gitster :\".\n\nI think you meant to give the --matching option the same efffect. My\ncomment is that you do not need a new option, as we already have that\nfeature.\n"},{"id":"94854","messageId":"20081104052024.GE31276@coredump.intra.peff.net","threadId":"16104","inReplyTo":"7v4p2ov0zt.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-04T05:20:24Z","receivedAt":"2008-11-04T05:20:24Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 03, 2008 at 03:33:10PM -0800, Junio C Hamano wrote:\n\n> By the way, didn't we add a feature to let you say \"git push $there :\"\n> which is to do what \"git push --matching $there\" would do?\n\nOh, indeed: a83619d (add special \"matching refs\" refspec) from April.\nSo given that, I think my arguments for \"--matching\" are pointless.\n\n-Peff\n"},{"id":"94878","messageId":"20081104091800.GB24100@dpotapov.dyndns.org","threadId":"16104","inReplyTo":"1225691960.20883.41.camel@maia.lan","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-11-04T09:18:00Z","receivedAt":"2008-11-04T09:18:00Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Nov 03, 2008 at 06:59:20PM +1300, Sam Vilain wrote:\n> \n> I can see that some people want this behaviour by default; but to me\n> \"push the current branch back to where it came from\" seems like far more\n> a rational default for at least 90% of users.\n\nI think it depends on one's workflow. If you use a centralized workflow\nas with CVS then yes, 90% cases you want to push the current branch. On\nthe other hand, if people push their changes to the server only for\nreview, it means that accidentally pushing more than one intended is not\na big deal. The only one who does publishing to the official repository\nis the maintainer, and the maintainer is most likely to run some tests\nafter merging all changes, which takes some time. So, it is rarely push\nthe current branch, it is usually the branch that has been tested, so\nthe name of the branch should be specified explicitly anyway.\n\nDmitry\n"},{"id":"94909","messageId":"1225822231.6722.3.camel@maia.lan","threadId":"16104","inReplyTo":"20081104091800.GB24100@dpotapov.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-04T18:10:31Z","receivedAt":"2008-11-04T18:10:31Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Tue, 2008-11-04 at 12:18 +0300, Dmitry Potapov wrote:\n> > I can see that some people want this behaviour by default; but to me\n> > \"push the current branch back to where it came from\" seems like far more\n> > a rational default for at least 90% of users.\n> \n> I think it depends on one's workflow. If you use a centralized workflow\n> as with CVS then yes, 90% cases you want to push the current branch. On\n> the other hand, if people push their changes to the server only for\n> review, it means that accidentally pushing more than one intended is not\n> a big deal.\n\nPerhaps not, but it was still unintended. I really can't understand the\nopposition to making this command make many people less angry at it.\n\n> The only one who does publishing to the official repository\n> is the maintainer, and the maintainer is most likely to run some tests\n> after merging all changes, which takes some time. So, it is rarely push\n> the current branch, it is usually the branch that has been tested, so\n> the name of the branch should be specified explicitly anyway.\n\nWhy is that relevant? That person can still use the explicit version of\nthe command.\n\nSam.\n"},{"id":"94912","messageId":"7vr65rqnoj.fsf@gitster.siamese.dyndns.org","threadId":"16104","inReplyTo":"1225822231.6722.3.camel@maia.lan","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-04T19:46:36Z","receivedAt":"2008-11-04T19:46:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sam Vilain writes:\n\n> On Tue, 2008-11-04 at 12:18 +0300, Dmitry Potapov wrote:\n> ...\n>> The only one who does publishing to the official repository\n>> is the maintainer, and the maintainer is most likely to run some tests\n>> after merging all changes, which takes some time. So, it is rarely push\n>> the current branch, it is usually the branch that has been tested, so\n>> the name of the branch should be specified explicitly anyway.\n>\n> Why is that relevant? That person can still use the explicit version of\n> the command.\n\nBack when \"git push $there :\" were not available, the default matching\nbehaviour was the _only_ way to say \"I know the set of branches I want to\npublish, and I have many more private branches in my primary work\nrepository. I do not want to list the set of branches to publish every\ntime when I type 'git push', nor I want to configure it --- Heck, I\nshouldn't have to list them, the public repository I am pushing to already\nhas that list, and it is the set of branches that exist there\".\n\nThese days, people who would want the maching behaviour can explicitly ask\nfor it, so there is one less reason to resist changing the default\n(i.e. earlier explicitly askinf for \"matching\" was impossible, but now we\ncan). The remaining reason of resistance is pure inertia (i.e. not\nchanging the behaviour of the command only because you upgraded your git),\nand the only way to address it is to start issuing the warning when \"git\npush\" or \"git push $there\" is used and the matching behaviour was chosen\nwithout configuration (i.e. no \"remote..push = :\"), and keep it\nthat way for two release cycles, and finally change the default.\n"},{"id":"94951","messageId":"20081105030525.GC20907@coredump.intra.peff.net","threadId":"16104","inReplyTo":"7vr65rqnoj.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-05T03:05:25Z","receivedAt":"2008-11-05T03:05:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 04, 2008 at 11:46:36AM -0800, Junio C Hamano wrote:\n\n> These days, people who would want the maching behaviour can explicitly ask\n> for it, so there is one less reason to resist changing the default\n> (i.e. earlier explicitly askinf for \"matching\" was impossible, but now we\n> can). The remaining reason of resistance is pure inertia (i.e. not\n> changing the behaviour of the command only because you upgraded your git),\n> and the only way to address it is to start issuing the warning when \"git\n> push\" or \"git push $there\" is used and the matching behaviour was chosen\n> without configuration (i.e. no \"remote..push = :\"), and keep it\n> that way for two release cycles, and finally change the default.\n\nHmm. It really seems to me that there are two desires for push behavior,\nbased on particular workflows. I.e., some people seem to want the\nmatching behavior by default, and others want to push the current\nbranch.\n\nAnd we already can control that via configuration of the refspec. So any\nargument that \"git push should do the same thing even on somebody else's\nsetup\" is already wrong. But I do think Junio has a good point, which is\nthat there is going to be confusion if upgrading git suddenly causes\n\"git push\" to do something else.\n\nSo why not take one step back in the behavior change? We can set up the\n\"push just this branch\" refspec during clone, which will leave existing\nrepositories untouched. And to make things even gentler, we can start\nwith opt-in to the clone feature, notify users via the release notes\n(which, as we have established, EVERYONE reads), and then decide if and\nwhen to switch the option on by default.\n\nSo something like a \"remote.push\" config option, the value of which gets\nadded to newly created remotes (including those created on clone). It\nwould default to \":\", but you could easily set \"git config remote.push\nHEAD\" to get the other behavior.\n\nNo, this doesn't get rid of the eventual need to choose whether to\nswitch the default. But I think it eases us into it a little more. And I\nthink such an option is a lot more generally applicable than a \"default\npush to matching versus HEAD\" option.\n\n-Peff\n"},{"id":"94962","messageId":"7vprlan09a.fsf@gitster.siamese.dyndns.org","threadId":"16104","inReplyTo":"20081105030525.GC20907@coredump.intra.peff.net","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-05T06:40:49Z","receivedAt":"2008-11-05T06:40:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> So why not take one step back in the behavior change? We can set up the\n> \"push just this branch\" refspec during clone, which will leave existing\n> repositories untouched.\n\nThat is not good enough.\n\nPeople who (think) know what an unconfigured \"git push\" would do would\nsuddenly see \"git push\" start misbehaving in their new repositories.\n\nHere is a patch to do what I suggested earlier. It\n\n * Adds \"--matching\" option; if we ever change the default to \"current\n branch only\", then \"git push $there :\" forces people to type $there.\n \"git push --matching\" allows us to honor \"branch..remote\".\n\n * Issues a deprecation warning when \"git push\" and \"git push $there\" is\n used to trigger the \"matching\" behaviour, without configuration or\n explicit command line refspec \":\".\n\nWhoever wants to change the default to \"current branch only\" can change\nthe part that calls push_deprecation_warning().\n\nI'll leave it up to people who want to change the default to implement the\nsame for non native transports and document the transition plan, as I am\nnot very keen on changing the default myself.\n\n---\n\n builtin-push.c | 11 +++++++----\n builtin-send-pack.c | 2 ++\n remote.c | 8 ++++++++\n remote.h | 1 +\n send-pack.h | 1 +\n transport.c | 1 +\n transport.h | 1 +\n 7 files changed, 21 insertions(+), 4 deletions(-)\n\ndiff --git c/builtin-push.c w/builtin-push.c\nindex 122fdcf..21418ab 100644\n--- c/builtin-push.c\n+++ w/builtin-push.c\n@@ -10,7 +10,7 @@\n #include \"parse-options.h\"\n \n static const char * const push_usage[] = {\n-\t\"git push [--all | --mirror] [--dry-run] [--tags] [--receive-pack=] [--repo=] [-f | --force] [-v] [ ...]\",\n+\t\"git push [--all | --mirror] [--dry-run] [--matching] [--tags] [--receive-pack=] [--repo=] [-f | --force] [-v] [ ...]\",\n \tNULL,\n };\n \n@@ -71,9 +71,11 @@ static int do_push(const char *repo, int flags)\n \t\treturn error(\"--mirror can't be combined with refspecs\");\n \t}\n \n-\tif ((flags & (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) ==\n-\t\t\t\t(TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) {\n-\t\treturn error(\"--all and --mirror are incompatible\");\n+\tif (HAS_MULTI_BITS(flags &\n+\t\t\t (TRANSPORT_PUSH_ALL|\n+\t\t\t TRANSPORT_PUSH_MIRROR|\n+\t\t\t TRANSPORT_PUSH_MATCHING))) {\n+\t\treturn error(\"--all, --mirror, --matching are incompatible\");\n \t}\n \n \tif (!refspec\n@@ -123,6 +125,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \t\tOPT_BOOLEAN( 0 , \"tags\", &tags, \"push tags\"),\n \t\tOPT_BIT( 0 , \"dry-run\", &flags, \"dry run\", TRANSPORT_PUSH_DRY_RUN),\n \t\tOPT_BIT('f', \"force\", &flags, \"force updates\", TRANSPORT_PUSH_FORCE),\n+\t\tOPT_BIT( 0 , \"matching\", &flags, \"push matching\", TRANSPORT_PUSH_MATCHING),\n \t\tOPT_BOOLEAN( 0 , \"thin\", &thin, \"use thin pack\"),\n \t\tOPT_STRING( 0 , \"receive-pack\", &receivepack, \"receive-pack\", \"receive pack program\"),\n \t\tOPT_STRING( 0 , \"exec\", &receivepack, \"receive-pack\", \"receive pack program\"),\ndiff --git c/builtin-send-pack.c w/builtin-send-pack.c\nindex d68ce2d..f5dda88 100644\n--- c/builtin-send-pack.c\n+++ w/builtin-send-pack.c\n@@ -402,6 +402,8 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest\n \t\tflags |= MATCH_REFS_ALL;\n \tif (args.send_mirror)\n \t\tflags |= MATCH_REFS_MIRROR;\n+\tif (args.send_matching)\n+\t\tflags |= MATCH_REFS_MATCHING;\n \n \t/* No funny business with the matcher */\n \tremote_tail = get_remote_heads(in, &remote_refs, 0, NULL, REF_NORMAL,\ndiff --git c/remote.c w/remote.c\nindex e530a21..ce4f54c 100644\n--- c/remote.c\n+++ w/remote.c\n@@ -1017,6 +1017,12 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,\n \t\treturn NULL;\n }\n \n+static void push_deprecation_warning(void)\n+{\n+\twarning(\"'git push [$remote]' will stop pushing 'matching refs' in a future release\");\n+\twarning(\"please train your fingers to say 'git push --matching' instead.\");\n+}\n+\n /*\n * Note. This is used only by \"push\"; refspec matching rules for\n * push and fetch are subtly different, so do not try to reuse it\n@@ -1031,6 +1037,8 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,\n \tstatic const char *default_refspec[] = { \":\", 0 };\n \n \tif (!nr_refspec) {\n+\t\tif (!(flags & MATCH_REFS_MATCHING))\n+\t\t\tpush_deprecation_warning();\n \t\tnr_refspec = 1;\n \t\trefspec = default_refspec;\n \t}\ndiff --git c/remote.h w/remote.h\nindex d2e170c..2a702cb 100644\n--- c/remote.h\n+++ w/remote.h\n@@ -124,6 +124,7 @@ enum match_refs_flags {\n \tMATCH_REFS_NONE\t\t= 0,\n \tMATCH_REFS_ALL \t\t= (1 << 0),\n \tMATCH_REFS_MIRROR\t= (1 << 1),\n+\tMATCH_REFS_MATCHING\t= (1 << 2),\n };\n \n /* Reporting of tracking info */\ndiff --git c/send-pack.h w/send-pack.h\nindex 8ff1dc3..133cb67 100644\n--- c/send-pack.h\n+++ w/send-pack.h\n@@ -6,6 +6,7 @@ struct send_pack_args {\n \tunsigned verbose:1,\n \t\tsend_all:1,\n \t\tsend_mirror:1,\n+\t\tsend_matching:1,\n \t\tforce_update:1,\n \t\tuse_thin_pack:1,\n \t\tdry_run:1;\ndiff --git c/transport.c w/transport.c\nindex 56831c5..4057d27 100644\n--- c/transport.c\n+++ w/transport.c\n@@ -680,6 +680,7 @@ static int git_transport_push(struct transport *transport, int refspec_nr, const\n \targs.receivepack = data->receivepack;\n \targs.send_all = !!(flags & TRANSPORT_PUSH_ALL);\n \targs.send_mirror = !!(flags & TRANSPORT_PUSH_MIRROR);\n+\targs.send_matching = !!(flags & TRANSPORT_PUSH_MATCHING);\n \targs.force_update = !!(flags & TRANSPORT_PUSH_FORCE);\n \targs.use_thin_pack = data->thin;\n \targs.verbose = !!(flags & TRANSPORT_PUSH_VERBOSE);\ndiff --git c/transport.h w/transport.h\nindex 6bbc1a8..fb98128 100644\n--- c/transport.h\n+++ w/transport.h\n@@ -34,6 +34,7 @@ struct transport {\n #define TRANSPORT_PUSH_DRY_RUN 4\n #define TRANSPORT_PUSH_MIRROR 8\n #define TRANSPORT_PUSH_VERBOSE 16\n+#define TRANSPORT_PUSH_MATCHING 32\n \n /* Returns a transport suitable for the url */\n struct transport *transport_get(struct remote *, const char *);\n"},{"id":"95012","messageId":"20081105225327.GD24100@dpotapov.dyndns.org","threadId":"16104","inReplyTo":"1225822231.6722.3.camel@maia.lan","subject":"Re: [PATCH] Documentation: add a planning document for the next CLI revamp","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-11-05T22:53:27Z","receivedAt":"2008-11-05T22:53:27Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Nov 05, 2008 at 07:10:31AM +1300, Sam Vilain wrote:\n> On Tue, 2008-11-04 at 12:18 +0300, Dmitry Potapov wrote:\n> > > I can see that some people want this behaviour by default; but to me\n> > > \"push the current branch back to where it came from\" seems like far more\n> > > a rational default for at least 90% of users.\n> > \n> > I think it depends on one's workflow. If you use a centralized workflow\n> > as with CVS then yes, 90% cases you want to push the current branch. On\n> > the other hand, if people push their changes to the server only for\n> > review, it means that accidentally pushing more than one intended is not\n> > a big deal.\n> \n> Perhaps not, but it was still unintended.\n\nEven if it were unintended, it will be noticed and corrected immediately,\nwhile forgetting to push some changes is not so obvious... Anyway, your\nworkflow assumes that one wants to push changes immediately before\nswitching to another branch, while there are many people who do that\nlater (after some additional testing or just at the end of their workday).\n\n> I really can't understand the\n> opposition to making this command make many people less angry at it.\n\nBecause it breaks how this command works now. So I don't think it is a\ngood idea to make some people less angry while enraging many others over\nbreaking their workflow. Compatibility should not be taken lightly.\n\nDmitry\n"}]}