# Re: [PATCH] Documentation: add a planning document for the next CLI revamp 49 messages from 2008-10-30 to 2008-11-03. 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. Thread: https://gitlist.dev/t/16093 ## Sam Vilain, 2008-10-30 03:48 Subject: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <1225338485-11046-1-git-send-email-sam@vilain.net> URL: https://gitlist.dev/e/1225338485-11046-1-git-send-email-sam%40vilain.net ``` From: Sam Vilain For cross-command CLI changes to be effective, they need to be cohesively planned. Add a planning document for this next set of changes. Signed-off-by: Sam Vilain --- Some suggestions, which have been briefly scanned over by some of the (remaining @4pm) GitTogether attendees. Please keep it constructive! :) Documentation/cli-revamp.txt | 135 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 135 insertions(+), 0 deletions(-) create mode 100644 Documentation/cli-revamp.txt diff --git a/Documentation/cli-revamp.txt b/Documentation/cli-revamp.txt new file mode 100644 index 0000000..980ea07 --- /dev/null +++ b/Documentation/cli-revamp.txt @@ -0,0 +1,135 @@ +GIT command line revamp +======================= + +This design document is designed for review and critique over planned +direction for changing the command set used by git, rather than +reviewing and critiquing individual changes. + +In general, old commands will be grandfathered for a year or longer, +and all plumbing commands will still work as originally designed. + +Please bear in mind when critiquing that each of these changes might +themselves have a progressive implementation, for instance the new +behaviour being optional initially. + +Please try to be positive with your comments; let's try to come up +with solutions and not argue about the details of the solutions +presented until those details are submitted. In particular, critical +comments that do not acknowledge the presence of a problem are +worthless at this stage. + +Add/rm/reset/checkout/revert +---------------------------- + +Many find these confusing. + + * 'git stage' would do what 'git add' does now. + + * 'git unstage' would do what 'git reset --' does now + + * 'git status' would encourage the user to use + 'git diff --staged' to see staged changes as a patch + + * 'git commit' with no changes should give useful information about + using 'git stage', 'git commit -a' or 'git commit filename ...' + + * 'git add' and 'git rm': no change + + * 'git update-index' considered plumbing, not changed + + * 'git revert' deprecated in favour of 'git cherry-pick --revert' + + * 'git undo' would do what 'git checkout HEAD --' does now + + * 'git checkout branch' would, if there is a remote branch called + 'branch' on exactly one remote, do what + 'git checkout -b branch thatremote/branch' does now. If it is + ambiguous, it would be an error, forcing the explicit notation. + + * 'git branch --switch' : alternative to checkout + + +Push/pull +--------- + +These commands are asymmetric, and this seems mostly historical. + + * 'git push --matching' does what 'git push' does today (without + explicit configuration) + + * 'git push' with no ref args and no 'push =' configuration does + what: + 'git push origin $(git symbolic-ref HEAD | sed "s!refs/heads/!!")' + does today. ie, it only pushes the current branch. + If a branch was defined in branch..push, push to that ref + instead of the matching one. If there is no matching ref, and + there is a branch..merge, push back there. + + * 'git pull' behaviour unchanged + + * 'git push' to checked out branch of non-bare repository not + allowed without special configuration. Configuration available + that allows working directory to be updated, known caveats + notwithstanding. Ideally, it would refuse only in situations + where a broken working copy would be left (because you couldn't + fix it), and work when it can be known to be safe. + + +Informational +------------- + + * 'git branch' should default to '--color=auto -v' + + * 'git tag -l' should show more information + + +Working with patches +-------------------- + + * 'git send-email' should prompt for all SMTP-related information + about sending e-mail when it is running with no configuration. + Because these days /usr/lib/sendmail is rarely configured + correctly. + + * other git send-email functionality which has bitten people - + particularly building the recipient list - should prompt for + confirmation until configured to be automatic. + + * 'git am -3' the default; with global option to make it not the + default for those that prefer the speed of -2 + + +Submodules +---------- + + * submodules should be able to refer to symbolic ref names, svn + style - in the .gitmodules file. The actual commit used is still + recorded in the index. + + * when switching branches, if the checked out revision of a submodule + changes, then it should be switched as well + + * 'git submodule update' should be able to be triggered when + switching branches (but not be the default behaviour) + + +Others +------ + + * 'git export' command that does what + 'git archive --format=tar --prefix=dir | tar x' does now + + * conflicted merges should point the user immediately to + 'git mergetool' and mention you need to use 'git stage' to mark + resolved files and 'git commit' when done. + + * 'git init --server' (or similar) should do everything required for + exporting:: +---- +chmod -R a+rX +touch git-daemon-export-ok +git gc +git update-server-info +chmod u+x .git/hooks/post-update +git config core.sharedrepository=1 +---- -- debian.1.5.6.1 ``` ## Stefan Karpinski, 2008-10-30 10:55 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: URL: https://gitlist.dev/e/d4bc1a2a0810300355q42b35a35p2ba0e778691a0ab6%40mail.gmail.com In-Reply-To: <1225338485-11046-1-git-send-email-sam@vilain.net> ``` These proposed changes look great. On Wed, Oct 29, 2008 at 8:48 PM, Sam Vilain wrote: > + * 'git unstage' would do what 'git reset --' does now Would it make sense to deprecate using "git reset --" for this then? It's always seemed confusing to me to have such disparate functionality in the reset command. > + * 'git export' command that does what > + 'git archive --format=tar --prefix=dir | tar x' does now It would be nice if the "git export" command could "checkout" a non-repo copy of a remote repo at a specific version. This would be as simple as calling archive on the remote size and then unarchiving it locally. But would of course take care of all the plumbing. (Sorry for the resend, Sam.) ``` ## Pierre Habouzit, 2008-10-30 13:24 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <20081030132453.GB24098@artemis.corp> URL: https://gitlist.dev/e/20081030132453.GB24098%40artemis.corp In-Reply-To: <1225338485-11046-1-git-send-email-sam@vilain.net> ``` On Thu, Oct 30, 2008 at 03:48:05AM +0000, Sam Vilain wrote: > +Add/rm/reset/checkout/revert > +---------------------------- > + > +Many find these confusing. > + > + * 'git stage' would do what 'git add' does now. -> git stage -i/-p shall do what git add -i/-p does. > + > + * 'git unstage' would do what 'git reset --' does now -> likely we need a git unstage -i/-p to interactively unstage some bits. * 'git track' would do what git add -N does now. * 'git untrack' would do what 'git rm --cached' does now. > + * 'git undo' would do what 'git checkout HEAD --' does now I'm not really a fan of this one. Undo is too unspecific (I know at least 2 people using that for git reset --hard HEAD~1 and 1 other for an alias to git reset --hard HEAD@{1}). I have no constructive proposal to replace it though, but I believe git undo would cause lots of harm. Would it be for another command, it wouldn't be a problem, but git undo *LOSES* information by design (the local changes on a file), and it would override aliases that people could have done on it. Choosing it has consequences. > +Working with patches > +-------------------- > + > + * 'git send-email' should prompt for all SMTP-related information > + about sending e-mail when it is running with no configuration. > + Because these days /usr/lib/sendmail is rarely configured > + correctly. And when the user answer them, it should set them (a bit like zsh does when it's run from the first time e.g.) > + > + * other git send-email functionality which has bitten people - > + particularly building the recipient list - should prompt for > + confirmation until configured to be automatic. > + * git-send-email should be either more interactive, or less: either just use the damn configuration, or propose a mode where it spawns an editor for each patch so that you can add further comments. * git-send-email should be able to format-patches by himself (IOW accept most of format-patch arguments and deal with the patch list by himself, which is usable if the previous point is implemented). > + * 'git am -3' the default; with global option to make it not the > + default for those that prefer the speed of -2 > + > + > +Submodules > +---------- > + > + * submodules should be able to refer to symbolic ref names, svn > + style - in the .gitmodules file. The actual commit used is still > + recorded in the index. > + > + * when switching branches, if the checked out revision of a submodule > + changes, then it should be switched as well > + > + * 'git submodule update' should be able to be triggered when > + switching branches (but not be the default behaviour) Actually on this one, I'd say that a submodule is either non initialized (in which case we don't care) or it is. If it is, switching branches should probably trigger a submodule update if the switch isn't possible (because the dereferenced sha1 doesn't exists). Or alternatively it should make the whole branch switch fail. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org ``` ## Nicolas Pitre, 2008-10-30 14:34 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: URL: https://gitlist.dev/e/alpine.LFD.2.00.0810301024300.13034%40xanadu.home In-Reply-To: <1225338485-11046-1-git-send-email-sam@vilain.net> ``` On Wed, 29 Oct 2008, Sam Vilain wrote: > From: Sam Vilain > > For cross-command CLI changes to be effective, they need to be > cohesively planned. Add a planning document for this next set of > changes. > > Signed-off-by: Sam Vilain [...] > + * 'git checkout branch' would, if there is a remote branch called > + 'branch' on exactly one remote, do what > + 'git checkout -b branch thatremote/branch' does now. If it is > + ambiguous, it would be an error, forcing the explicit notation. I can't do otherwise but disagree with this. Currently, when a remote branch is checked out, the commit corresponding to that remote branch is put on a detached head which is IMHO completely sane and coherent. It even tells you how to create a local branch from there if that's what you wanted to do. So if it is still too confusing at that point then more explanations are needed and not the removal of a perfectly fine feature. Please don't change that behavior. Nicolas ``` ## Theodore Tso, 2008-10-30 14:39 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <20081030143918.GB14744@mit.edu> URL: https://gitlist.dev/e/20081030143918.GB14744%40mit.edu In-Reply-To: <1225338485-11046-1-git-send-email-sam@vilain.net> ``` On Wed, Oct 29, 2008 at 08:48:05PM -0700, Sam Vilain wrote: > From: Sam Vilain > > For cross-command CLI changes to be effective, they need to be > cohesively planned. Add a planning document for this next set of > changes. Here are my favorites: * Add the command "git revert-file " which is syntactic sugar for: git checkout HEAD -- Rationale: Many other SCM's have a way of undoing local edits to a file very simply, i.e."hg revert " or "svn revert ", and for many developers's workflow, it's useful to be able to undo local edits to a single file, but not to everything else in the working directory. And "git checkout HEAD -- " is rather cumbersome to type, and many beginning users don't find it intuitive to look in the "git-checkout" man page for instructions on how to revert a local file. * Change the argument handling for "git format-patch" so it is consistent with everything else which takes a set of commits. Yes, it means that where people have gotten used to typing "git format-patch origin", they'll have to type instead: "git format-patch origin..", but's much more consistent. We've done the best we can by documenting the existing behavior, but if'we re going to make major, potentially incompatible, CLI changes, this is something to at least consider. Maybe with a config file for people who really don't want to retrain their fingers to type the two extra periods? - Ted ``` ## Pierre Habouzit, 2008-10-30 14:43 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <20081030144321.GF24098@artemis.corp> URL: https://gitlist.dev/e/20081030144321.GF24098%40artemis.corp In-Reply-To: <20081030143918.GB14744@mit.edu> ``` On Thu, Oct 30, 2008 at 02:39:18PM +0000, Theodore Tso wrote: > On Wed, Oct 29, 2008 at 08:48:05PM -0700, Sam Vilain wrote: > > From: Sam Vilain > > > > For cross-command CLI changes to be effective, they need to be > > cohesively planned. Add a planning document for this next set of > > changes. > > Here are my favorites: > > * Add the command "git revert-file " which is syntactic sugar for: > > git checkout HEAD -- > > Rationale: Many other SCM's have a way of undoing local edits to a > file very simply, i.e."hg revert " or "svn revert ", and > for many developers's workflow, it's useful to be able to undo local > edits to a single file, but not to everything else in the working > directory. And "git checkout HEAD -- " is rather cumbersome > to type, and many beginning users don't find it intuitive to look in > the "git-checkout" man page for instructions on how to revert a > local file. This is what is currently proposed for undo, but yeah, revert-file or maybe rather revert-changes may be suitable. > * Change the argument handling for "git format-patch" so it is > consistent with everything else which takes a set of commits. Yes, > it means that where people have gotten used to typing "git > format-patch origin", they'll have to type instead: "git > format-patch origin..", but's much more consistent. We've done the > best we can by documenting the existing behavior, but if'we re going > to make major, potentially incompatible, CLI changes, this is > something to at least consider. Maybe with a config file for people > who really don't want to retrain their fingers to type the two extra > periods? git format-patch origin/next.. works already. I'm used to the asymetric git format-patch origin/next syntax, and I would be sorry if it disappeared though, and I see no really good reason to get rid of it. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org ``` ## Shawn O. Pearce, 2008-10-30 14:52 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <20081030145253.GK14786@spearce.org> URL: https://gitlist.dev/e/20081030145253.GK14786%40spearce.org In-Reply-To: ``` Nicolas Pitre wrote: > On Wed, 29 Oct 2008, Sam Vilain wrote: > > From: Sam Vilain > > > > For cross-command CLI changes to be effective, they need to be > > cohesively planned. Add a planning document for this next set of > > changes. > > > > Signed-off-by: Sam Vilain > [...] > > > + * 'git checkout branch' would, if there is a remote branch called > > + 'branch' on exactly one remote, do what > > + 'git checkout -b branch thatremote/branch' does now. If it is > > + ambiguous, it would be an error, forcing the explicit notation. > > I can't do otherwise but disagree with this. Currently, when a remote > branch is checked out, the commit corresponding to that remote branch is > put on a detached head which is IMHO completely sane and coherent. It > even tells you how to create a local branch from there if that's what > you wanted to do. So if it is still too confusing at that point then > more explanations are needed and not the removal of a perfectly fine > feature. Please don't change that behavior. +1 to Nico's NAK. Although I was at the GitTogether I don't remember this change to checkout being discussed. I must have been asleep reading email or something. I am _NOT_ in favor of this change; I think the current behavior of "git checkout origin/master" is correct and as sane as we can make it. -- Shawn. ``` ## Mike Hommey, 2008-10-30 14:59 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <20081030145928.GA21707@glandium.org> URL: https://gitlist.dev/e/20081030145928.GA21707%40glandium.org In-Reply-To: <20081030145253.GK14786@spearce.org> ``` On Thu, Oct 30, 2008 at 07:52:53AM -0700, Shawn O. Pearce wrote: > Nicolas Pitre wrote: > > On Wed, 29 Oct 2008, Sam Vilain wrote: > > > From: Sam Vilain > > > > > > For cross-command CLI changes to be effective, they need to be > > > cohesively planned. Add a planning document for this next set of > > > changes. > > > > > > Signed-off-by: Sam Vilain > > [...] > > > > > + * 'git checkout branch' would, if there is a remote branch called > > > + 'branch' on exactly one remote, do what > > > + 'git checkout -b branch thatremote/branch' does now. If it is > > > + ambiguous, it would be an error, forcing the explicit notation. > > > > I can't do otherwise but disagree with this. Currently, when a remote > > branch is checked out, the commit corresponding to that remote branch is > > put on a detached head which is IMHO completely sane and coherent. It > > even tells you how to create a local branch from there if that's what > > you wanted to do. So if it is still too confusing at that point then > > more explanations are needed and not the removal of a perfectly fine > > feature. Please don't change that behavior. > > +1 to Nico's NAK. > > Although I was at the GitTogether I don't remember this change to > checkout being discussed. I must have been asleep reading email > or something. I am _NOT_ in favor of this change; I think the > current behavior of "git checkout origin/master" is correct and as > sane as we can make it. Except he was talking about 'git checkout branch', not 'git checkout origin/branch'. And I would be fine with 'git checkout branch' doing what 'git checkout -b branch $remote/branch' does if $remote is unique (i.e. there is no other 'branch' branch in any other remote) and the 'branch' branch doesn't already exist. Mike ``` ## Pierre Habouzit, 2008-10-30 15:01 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <20081030150135.GG24098@artemis.corp> URL: https://gitlist.dev/e/20081030150135.GG24098%40artemis.corp In-Reply-To: <20081030145928.GA21707@glandium.org> ``` On Thu, Oct 30, 2008 at 02:59:28PM +0000, Mike Hommey wrote: > On Thu, Oct 30, 2008 at 07:52:53AM -0700, Shawn O. Pearce wrote: > > +1 to Nico's NAK. > > > > Although I was at the GitTogether I don't remember this change to > > checkout being discussed. I must have been asleep reading email > > or something. I am _NOT_ in favor of this change; I think the > > current behavior of "git checkout origin/master" is correct and as > > sane as we can make it. > > Except he was talking about 'git checkout branch', not 'git checkout > origin/branch'. And I would be fine with 'git checkout branch' doing > what 'git checkout -b branch $remote/branch' does if $remote is unique > (i.e. there is no other 'branch' branch in any other remote) and the > 'branch' branch doesn't already exist. Seconded. Having git-checkout $foo being a shorthand for git checkout -b $foo origin/$foo when origin/$foo exists and $foo doesn't is definitely handy. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org ``` ## Andreas Ericsson, 2008-10-30 15:02 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <4909CC85.1080803@op5.se> URL: https://gitlist.dev/e/4909CC85.1080803%40op5.se In-Reply-To: <20081030143918.GB14744@mit.edu> ``` Theodore Tso wrote: > On Wed, Oct 29, 2008 at 08:48:05PM -0700, Sam Vilain wrote: >> From: Sam Vilain >> >> For cross-command CLI changes to be effective, they need to be >> cohesively planned. Add a planning document for this next set of >> changes. > > Here are my favorites: > > * Add the command "git revert-file " which is syntactic sugar for: > > git checkout HEAD -- > > Rationale: Many other SCM's have a way of undoing local edits to a > file very simply, i.e."hg revert " or "svn revert ", and > for many developers's workflow, it's useful to be able to undo local > edits to a single file, but not to everything else in the working > directory. And "git checkout HEAD -- " is rather cumbersome > to type, and many beginning users don't find it intuitive to look in > the "git-checkout" man page for instructions on how to revert a > local file. > I like it, although I guess one would have to add a "--staged" flag to git revert-file to be able to checkout files from index as well, or people will wonder why that can't be done. > * Change the argument handling for "git format-patch" so it is > consistent with everything else which takes a set of commits. Yes, > it means that where people have gotten used to typing "git > format-patch origin", they'll have to type instead: "git > format-patch origin..", but's much more consistent. We've done the > best we can by documenting the existing behavior, but if'we re going > to make major, potentially incompatible, CLI changes, this is > something to at least consider. Maybe with a config file for people > who really don't want to retrain their fingers to type the two extra > periods? > "git format-patch" does exactly the same thing as other commit-range handling commands do, which is assume that the missing commit end-point is HEAD, so it actually is consistent, although it doesn't quite look as if it is. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ``` ## Matthieu Moy, 2008-10-30 15:20 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: URL: https://gitlist.dev/e/vpqmygmw1mr.fsf%40bauges.imag.fr In-Reply-To: <20081030143918.GB14744@mit.edu> ``` Theodore Tso writes: > * Add the command "git revert-file " which is syntactic sugar for: > > git checkout HEAD -- I don't think "revert-file" is a good name for this: although other SCM often call this "revert", what Git calls "revert" is about reverting an existing commit (it's "backout" in hg for example). The terminology to revert the working tree to the last commited version is already here in Git, it's "reset". I've already argued in favor of allowing "git reset --hard ", which is consistant with existing terminology and doesn't add an extra command, but without success. -- Matthieu ``` ## Julian Phillips, 2008-10-30 15:25 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: URL: https://gitlist.dev/e/alpine.LNX.2.00.0810301518300.13964%40reaper.quantumfyre.co.uk In-Reply-To: <20081030132453.GB24098@artemis.corp> ``` On Thu, 30 Oct 2008, Pierre Habouzit wrote: > On Thu, Oct 30, 2008 at 03:48:05AM +0000, Sam Vilain wrote: >> +Working with patches >> +-------------------- >> + >> + * 'git send-email' should prompt for all SMTP-related information >> + about sending e-mail when it is running with no configuration. >> + Because these days /usr/lib/sendmail is rarely configured >> + correctly. > > And when the user answer them, it should set them (a bit like zsh does > when it's run from the first time e.g.) > >> + >> + * other git send-email functionality which has bitten people - >> + particularly building the recipient list - should prompt for >> + confirmation until configured to be automatic. >> + > > * git-send-email should be either more interactive, or less: either > just use the damn configuration, or propose a mode where it spawns > an editor for each patch so that you can add further comments. > > * git-send-email should be able to format-patches by himself (IOW > accept most of format-patch arguments and deal with the patch list > by himself, which is usable if the previous point is implemented). This gets my vote ... These are two of the reasons that I ended up ignoring git-send-email and writing my own replacement. I found the whole format-patch/send-email dance too cumbersome and confusing - particularly for sending a single patch. To send a single patch I ended up with the command: git mail-commmits --edit HEAD~1 It would be nice if I could replace this with: git send-email --edit HEAD~1 ;) > >> + * 'git am -3' the default; with global option to make it not the >> + default for those that prefer the speed of -2 >> + >> + -- Julian --- Blessed be those who initiate lively discussions with the hopelessly mute, for they shall be know as Dentists. ``` ## Theodore Tso, 2008-10-30 16:30 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <20081030163056.GA8899@mit.edu> URL: https://gitlist.dev/e/20081030163056.GA8899%40mit.edu In-Reply-To: <20081030144321.GF24098@artemis.corp> ``` On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote: > > git format-patch origin/next.. works already. I'm used to the asymetric > git format-patch origin/next syntax, and I would be sorry if it > disappeared though, and I see no really good reason to get rid of it. The reason why it annoys me is because I often what to cherry-pick a single patch to send to someone, and so while "git show 332d2e78" shows me the patch, but if I want to use git-send-email for that particular patch, "git format-patch 332d2e78" doesn't DTRT. I have to type "git format-patch 332d2e78^..332d2e78" instead. I've learned to live with it, but it's annoying each time I have to do it. More generally, the fact that the CLI has different ways the same set of arguments can be decoded can be quite confusing. The most obvious way this turns up is to consider which set of commits are displayed/formatted via these three commands: git format-patch 332d2e78 git show 332d2e78 git log -p 332d2e78 The first formats all patches that follow commit 332d2e78 (not including commit 332d2e78), the second shows just commit 332d2e78, and the last prints all commits starting at 332d2e78 and before it. For many workflows, the default way a single commit-id is interpreted makes a lot of sense. But for a newcomer, it's very confusing. I'm not saying that we should collapse everything down to a single way of doing things, but git format-patch is an exception, and I don't think anything else actually works that way; looking at the man page makes it clear that it treats its argument as a revision range EXCEPT when only a single commit is specified. It can be justified, and maybe it's convenient enough that this is one of those places where tutorials should just explicitly call this out as one of those exceptions that make sense given common workflows. But just as English can be heard to learn because "though", "through", "plough", "cough", and "tough" don't rhyme even though they look like they should (even though native speakers have no problem with it), similarly this is one of those inconsistencies that makes git hard to learn. (And I get annoyed when I want to run git format-patch on a single patch not at the tip of the tree; but if it's just me, I can write a "git format-single-patch" wrapper script to get around it.) - Ted ``` ## Pierre Habouzit, 2008-10-30 16:43 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <20081030164357.GJ24098@artemis.corp> URL: https://gitlist.dev/e/20081030164357.GJ24098%40artemis.corp In-Reply-To: <20081030163056.GA8899@mit.edu> ``` On Thu, Oct 30, 2008 at 04:30:56PM +0000, Theodore Tso wrote: > On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote: > > > > git format-patch origin/next.. works already. I'm used to the asymetric > > git format-patch origin/next syntax, and I would be sorry if it > > disappeared though, and I see no really good reason to get rid of it. > > The reason why it annoys me is because I often what to cherry-pick a > single patch to send to someone, and so while "git show 332d2e78" > shows me the patch, but if I want to use git-send-email for that > particular patch, "git format-patch 332d2e78" doesn't DTRT. I have to > type "git format-patch 332d2e78^..332d2e78" instead. I've learned to > live with it, but it's annoying each time I have to do it. [...] > (And I get annoyed when I want to run git format-patch on a single > patch not at the tip of the tree; but if it's just me, I can write a > "git format-single-patch" wrapper script to get around it.) In fact I believe that what we lack is a shorthand for: $sha1^..$sha1 because that would solve both of your issues, and it's something that has bothered me in the past too for other commands. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org ``` ## Nicolas Pitre, 2008-10-30 16:53 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: URL: https://gitlist.dev/e/alpine.LFD.2.00.0810301105350.13034%40xanadu.home In-Reply-To: <20081030150135.GG24098@artemis.corp> ``` On Thu, 30 Oct 2008, Pierre Habouzit wrote: > On Thu, Oct 30, 2008 at 02:59:28PM +0000, Mike Hommey wrote: > > On Thu, Oct 30, 2008 at 07:52:53AM -0700, Shawn O. Pearce wrote: > > > +1 to Nico's NAK. > > > > > > Although I was at the GitTogether I don't remember this change to > > > checkout being discussed. I must have been asleep reading email > > > or something. I am _NOT_ in favor of this change; I think the > > > current behavior of "git checkout origin/master" is correct and as > > > sane as we can make it. > > > > Except he was talking about 'git checkout branch', not 'git checkout > > origin/branch'. And I would be fine with 'git checkout branch' doing > > what 'git checkout -b branch $remote/branch' does if $remote is unique > > (i.e. there is no other 'branch' branch in any other remote) and the > > 'branch' branch doesn't already exist. > > Seconded. > > Having git-checkout $foo being a shorthand for git checkout -b $foo > origin/$foo when origin/$foo exists and $foo doesn't is definitely handy. No. This is only the first step towards insanity. In many cases origin/$foo == origin/master so this can't work in that case which is, after all, the common case. Therefore I think this is wrong to add magic operations which are not useful for the common case and actively _hide_ how git actually works. Not only will you have to explain how git works anyway for that common origin/master case, but you'll also have to explain why sometimes the magic works and sometimes not. Please keep such convenience shortcuts for your own scripts and/or aliases. Nicolas ``` ## Nicolas Pitre, 2008-10-30 17:00 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: URL: https://gitlist.dev/e/alpine.LFD.2.00.0810301259130.13034%40xanadu.home In-Reply-To: ``` On Thu, 30 Oct 2008, Matthieu Moy wrote: > I've already argued in favor of allowing "git reset --hard ", > which is consistant with existing terminology and doesn't add an extra > command, but without success. If you have a file argument, the --hard option is redundant, isn't it? So what about simply "git reset " ? Nicolas ``` ## Nicolas Pitre, 2008-10-30 17:03 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: URL: https://gitlist.dev/e/alpine.LFD.2.00.0810301301510.13034%40xanadu.home In-Reply-To: <20081030163056.GA8899@mit.edu> ``` On Thu, 30 Oct 2008, Theodore Tso wrote: > On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote: > > > > git format-patch origin/next.. works already. I'm used to the asymetric > > git format-patch origin/next syntax, and I would be sorry if it > > disappeared though, and I see no really good reason to get rid of it. > > The reason why it annoys me is because I often what to cherry-pick a > single patch to send to someone, and so while "git show 332d2e78" > shows me the patch, but if I want to use git-send-email for that > particular patch, "git format-patch 332d2e78" doesn't DTRT. I have to > type "git format-patch 332d2e78^..332d2e78" instead. try: git show --pretty=email 332d2e78 Nicolas ``` ## Pierre Habouzit, 2008-10-30 17:03 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <20081030170329.GK24098@artemis.corp> URL: https://gitlist.dev/e/20081030170329.GK24098%40artemis.corp In-Reply-To: ``` On Thu, Oct 30, 2008 at 05:00:18PM +0000, Nicolas Pitre wrote: > On Thu, 30 Oct 2008, Matthieu Moy wrote: > > > I've already argued in favor of allowing "git reset --hard ", > > which is consistant with existing terminology and doesn't add an extra > > command, but without success. > > If you have a file argument, the --hard option is redundant, isn't it? > So what about simply "git reset " ? errrrm, git reset resets the index notion of the file to its status in HEAD... which I'm sure is *somehow* useful to "some" people ;P -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org ``` ## Nicolas Pitre, 2008-10-30 17:17 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: URL: https://gitlist.dev/e/alpine.LFD.2.00.0810301316220.13034%40xanadu.home In-Reply-To: <20081030170329.GK24098@artemis.corp> ``` On Thu, 30 Oct 2008, Pierre Habouzit wrote: > On Thu, Oct 30, 2008 at 05:00:18PM +0000, Nicolas Pitre wrote: > > On Thu, 30 Oct 2008, Matthieu Moy wrote: > > > > > I've already argued in favor of allowing "git reset --hard ", > > > which is consistant with existing terminology and doesn't add an extra > > > command, but without success. > > > > If you have a file argument, the --hard option is redundant, isn't it? > > So what about simply "git reset " ? > > errrrm, git reset resets the index notion of the file to its status > in HEAD... which I'm sure is *somehow* useful to "some" people ;P Too bad... Nicolas ``` ## Sam Vilain, 2008-10-30 17:31 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <1225387882.19891.9.camel@maia.lan> URL: https://gitlist.dev/e/1225387882.19891.9.camel%40maia.lan In-Reply-To: ``` On Thu, 2008-10-30 at 12:53 -0400, Nicolas Pitre wrote: > > Seconded. > > > > Having git-checkout $foo being a shorthand for git checkout -b $foo > > origin/$foo when origin/$foo exists and $foo doesn't is definitely handy. > > No. This is only the first step towards insanity. > > In many cases origin/$foo == origin/master so this can't work in that > case which is, after all, the common case. I don't understand that argument at all, can you explain further? > Therefore I think this is > wrong to add magic operations which are not useful for the common case > and actively _hide_ how git actually works. Not only will you have to > explain how git works anyway for that common origin/master case, but > you'll also have to explain why sometimes the magic works and sometimes > not. Please keep such convenience shortcuts for your own scripts and/or > aliases. It's not about magic, it's about sensible defaults. Currently this use case is an error, and the resultant command is very long to type, and involves typing the branch name twice. I end up writing things like: git checkout -b {,origin/}wr34251-do-something For the user who doesn't know to use the ksh-style {} blocks this is voodoo. The longer form is cumbersome. For the case where the thing you type is a resolvable reference, it would just check it out, as now. Sam. ``` ## Sam Vilain, 2008-10-30 17:44 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <1225388666.19891.22.camel@maia.lan> URL: https://gitlist.dev/e/1225388666.19891.22.camel%40maia.lan In-Reply-To: <20081030164357.GJ24098@artemis.corp> ``` On Thu, 2008-10-30 at 17:43 +0100, Pierre Habouzit wrote: > In fact I believe that what we lack is a shorthand for: > > $sha1^..$sha1 because that would solve both of your issues, and it's > something that has bothered me in the past too for other commands. There is already a shorthand for that; $sha1^! Indeed passing that to git-format-patch has the intended effect; it causes it to save a patch for just the commit in question. I agree that it would make more sense for the current behaviour to be changed; git format-patch origin/master.. Isn't that much more to type than: git format-patch origin/master And it makes the case where you just want to format a single patch work better. However, I worry about the backwards incompatibility. The other changes I listed didn't really violate existing expectations. That being said, the case where a single commit reference is passed, with no range, should be relatively easy to detect. In this situation it could return an error, and encourage the user to use "--since" or "--only"; or to configure one of those to be the default. I'm wondering whether it's worth building some kind of mechanism to notice that settings like this have not been set, and to print a warning like "warning: you are using a git that introduced minor command changes; use 'git config --new' to pick your defaults" - that way, changes to command operation could be introduced that would not annoy older users so much. Sam. ``` ## Sam Vilain, 2008-10-30 17:51 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <1225389068.19891.28.camel@maia.lan> URL: https://gitlist.dev/e/1225389068.19891.28.camel%40maia.lan In-Reply-To: <20081030143918.GB14744@mit.edu> ``` On Thu, 2008-10-30 at 10:39 -0400, Theodore Tso wrote: > * Add the command "git revert-file " which is syntactic sugar for: > > git checkout HEAD -- > > Rationale: Many other SCM's have a way of undoing local edits to a > file very simply, i.e."hg revert " or "svn revert ", and > for many developers's workflow, it's useful to be able to undo local > edits to a single file, but not to everything else in the working > directory. And "git checkout HEAD -- " is rather cumbersome > to type, and many beginning users don't find it intuitive to look in > the "git-checkout" man page for instructions on how to revert a > local file. Well, I don't have strong feelings on the exact command name used; I suggested "undo", probably also ambiguous. But still, a significant number of users are surprised when they type 'git revert' and they get a backed out patch. It's such an uncommon operation, it doesn't deserve to be triggered so easily. And reverting files to the state in the index and/or HEAD is a common operation that deserves being short to type. Making it plain "revert" would violate expectations of existing users; it seems a better idea to just deprecate it, and point the users to the new method - cherry-pick --revert - or the command they might have meant - whatever that becomes. Sam. ``` ## Sam Vilain, 2008-10-30 18:06 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <1225390018.19891.38.camel@maia.lan> URL: https://gitlist.dev/e/1225390018.19891.38.camel%40maia.lan In-Reply-To: ``` On Thu, 2008-10-30 at 13:17 -0400, Nicolas Pitre wrote: > > errrrm, git reset resets the index notion of the file to its status > > in HEAD... which I'm sure is *somehow* useful to "some" people ;P > > Too bad... The changes need to not unnecessarily break scripts or let down people's expectations. I'd be happy to deprecate the use of reset with file arguments, to keep 'reset' focused on resetting the current HEAD and not concerned with files; but changing its behaviour on a subtle level like this is sure to annoy... Sam. ``` ## Nicolas Pitre, 2008-10-30 18:28 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: URL: https://gitlist.dev/e/alpine.LFD.2.00.0810301423520.13034%40xanadu.home In-Reply-To: <1225387882.19891.9.camel@maia.lan> ``` On Thu, 30 Oct 2008, Sam Vilain wrote: > On Thu, 2008-10-30 at 12:53 -0400, Nicolas Pitre wrote: > > > Seconded. > > > > > > Having git-checkout $foo being a shorthand for git checkout -b $foo > > > origin/$foo when origin/$foo exists and $foo doesn't is definitely handy. > > > > No. This is only the first step towards insanity. > > > > In many cases origin/$foo == origin/master so this can't work in that > > case which is, after all, the common case. > > I don't understand that argument at all, can you explain further? By default, git creates a branch called "master. Hence, by default, if you clone that repository, this branch will be called origin/master. So by default $foo is already ambiguous. > > Therefore I think this is > > wrong to add magic operations which are not useful for the common case > > and actively _hide_ how git actually works. Not only will you have to > > explain how git works anyway for that common origin/master case, but > > you'll also have to explain why sometimes the magic works and sometimes > > not. Please keep such convenience shortcuts for your own scripts and/or > > aliases. > > It's not about magic, it's about sensible defaults. Currently this use > case is an error, and the resultant command is very long to type, and > involves typing the branch name twice. I end up writing things like: > > git checkout -b {,origin/}wr34251-do-something > > For the user who doesn't know to use the ksh-style {} blocks this is > voodoo. The longer form is cumbersome. This is no excuse for promoting semantics only useful in such special cases. > For the case where the thing you type is a resolvable reference, it > would just check it out, as now. As long as it checks it out with a detached head if it is a remote branch then I have no issue. Nicolas ``` ## Yann Dirson, 2008-10-30 22:46 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <20081030224625.GA4030@nan92-1-81-57-214-146.fbx.proxad.net> URL: https://gitlist.dev/e/20081030224625.GA4030%40nan92-1-81-57-214-146.fbx.proxad.net In-Reply-To: ``` On Thu, Oct 30, 2008 at 02:28:35PM -0400, Nicolas Pitre wrote: > > It's not about magic, it's about sensible defaults. Currently this use > > case is an error, and the resultant command is very long to type, and > > involves typing the branch name twice. I end up writing things like: > > > > git checkout -b {,origin/}wr34251-do-something > > > > For the user who doesn't know to use the ksh-style {} blocks this is > > voodoo. The longer form is cumbersome. > > This is no excuse for promoting semantics only useful in such special > cases. It is really not so rare to have an upstream repo with branches such as "stable", "next" and the like. This syntax extension would make is as straightforward to work on "stable" as it is on remote HEAD (usually master, which has already been magically setup for you). BTW this use case reminds me that the remote HEAD has its own special treatment for "clone", which AFAIK cannot be overriden from command-line (I still sometimes lack what cogito provided as "cg clone URL#branch"). > As long as it checks it out with a detached head if it is a remote > branch then I have no issue. Yes it is possible, but that does not necessarily make a UI improvement worthless. Best regards, -- Yann ``` ## Theodore Tso, 2008-10-30 23:27 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <20081030232717.GB10779@mit.edu> URL: https://gitlist.dev/e/20081030232717.GB10779%40mit.edu In-Reply-To: <1225389068.19891.28.camel@maia.lan> ``` On Thu, Oct 30, 2008 at 10:51:08AM -0700, Sam Vilain wrote: > > Well, I don't have strong feelings on the exact command name used; I > suggested "undo", probably also ambiguous. But still, a significant > number of users are surprised when they type 'git revert' and they get a > backed out patch. Yeah, that's why I suggested "git revert-file". It's less ambiguous than "undo", and it's easier for people used to "hg revert" and "svn revert" to find "git revert-file". And, it won't be run accidentally by old-timers who are used to the old (to be deprecated) "git revert". But I'm not that picky about the name; I just missed the "git undo" proposal in your patch. > Making it plain "revert" would violate expectations of existing users; > it seems a better idea to just deprecate it, and point the users to the > new method - cherry-pick --revert - or the command they might have meant > - whatever that becomes. Yup, I agree; that's why I suggested "git revert-file". - Ted ``` ## Sam Vilain, 2008-10-30 23:28 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <1225409309.6765.5.camel@maia.lan> URL: https://gitlist.dev/e/1225409309.6765.5.camel%40maia.lan In-Reply-To: ``` On Thu, 2008-10-30 at 14:28 -0400, Nicolas Pitre wrote: > > For the case where the thing you type is a resolvable reference, it > > would just check it out, as now. > As long as it checks it out with a detached head if it is a remote > branch then I have no issue. Absolutely - if you've already got a branch "master", then "git checkout master" should definitely give it to you. If you go "git checkout origin/master", you get a floating head. But I quite often find myself wanting to check out a remote branch, and give it a name just like on the remote. I want "git checkout blah" to assume that's what I mean, until I make a local branch "blah". > By default, git creates a branch called "master. Hence, by default, if > you clone that repository, this branch will be called origin/master. So > by default $foo is already ambiguous. Right - 'master' in this case resolves to something. The ambiguity is resolved by defaulting to the thing that resolves. The fall-back behaviour is only triggered if you asked for something that is currently an error. Because breaking expectations sucks. Sam. ``` ## Jakub Narebski, 2008-10-30 23:55 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: URL: https://gitlist.dev/e/gedhh6%24urq%241%40ger.gmane.org In-Reply-To: <1225387882.19891.9.camel@maia.lan> ``` Sam Vilain wrote: > It's not about magic, it's about sensible defaults.  Currently this use > case is an error, and the resultant command is very long to type, and > involves typing the branch name twice.  I end up writing things like: > >   git checkout -b {,origin/}wr34251-do-something Can't you use currently git checkout --track origin/wr34251-do-something P.S. Somehow I don't see first message in this thread on GMane... -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Jeff King, 2008-10-31 00:34 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <20081031003413.GB5745@sigill.intra.peff.net> URL: https://gitlist.dev/e/20081031003413.GB5745%40sigill.intra.peff.net In-Reply-To: <20081030132453.GB24098@artemis.corp> ``` On Thu, Oct 30, 2008 at 02:24:53PM +0100, Pierre Habouzit wrote: > > + * 'git stage' would do what 'git add' does now. > -> git stage -i/-p shall do what git add -i/-p does. Yes, and that is obviously easy. > > + * 'git unstage' would do what 'git reset --' does now > -> likely we need a git unstage -i/-p to interactively unstage some > bits. Agreed, though this is a bit harder. But I think this should go hand in hand with "git stash -i" and "git stash apply -i" (as I mentioned in my other mail in this thread). -Peff ``` ## Sam Vilain, 2008-10-31 06:51 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <1225435899.20883.25.camel@maia.lan> URL: https://gitlist.dev/e/1225435899.20883.25.camel%40maia.lan In-Reply-To: ``` On Fri, 2008-10-31 at 00:55 +0100, Jakub Narebski wrote: > > involves typing the branch name twice. I end up writing things like: > > > > git checkout -b {,origin/}wr34251-do-something > > Can't you use currently > > git checkout --track origin/wr34251-do-something Ah, that's a new feature. Still, I think it's poorly Huffman coded; far too verbose. But let's resume this discussion after I dig up the old thread about pushing and pulling too... I think it makes sense to look at this as a whole. Cheers, Sam. ``` ## Jakub Narebski, 2008-10-31 07:36 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <200810310836.02908.jnareb@gmail.com> URL: https://gitlist.dev/e/200810310836.02908.jnareb%40gmail.com In-Reply-To: <1225435899.20883.25.camel@maia.lan> ``` Dnia piątek 31. października 2008 07:51, Sam Vilain napisał: > On Fri, 2008-10-31 at 00:55 +0100, Jakub Narebski wrote: > > > involves typing the branch name twice. I end up writing things like: > > > > > > git checkout -b {,origin/}wr34251-do-something > > > > Can't you use currently > > > > git checkout --track origin/wr34251-do-something > > Ah, that's a new feature. Still, I think it's poorly Huffman coded; far > too verbose. Well, either you have a little bit more verbose, or you have to have some DWIM-mery, which (as usual with DWIM) can go wrong. -- Jakub Narebski Poland ``` ## Kyle Moffett, 2008-10-31 11:38 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: URL: https://gitlist.dev/e/f73f7ab80810310438k3282639eta90f2a0589a12c1%40mail.gmail.com In-Reply-To: ``` On Thu, Oct 30, 2008 at 6:55 AM, Stefan Karpinski wrote: > On Wed, Oct 29, 2008 at 8:48 PM, Sam Vilain wrote: >> + * 'git export' command that does what >> + 'git archive --format=tar --prefix=dir | tar x' does now > > It would be nice if the "git export" command could "checkout" a > non-repo copy of a remote repo at a specific version. This would be as > simple as calling archive on the remote size and then unarchiving it > locally. But would of course take care of all the plumbing. I'm not sure whether the "git archive | tar" or the following is more efficient: export GIT_INDEX_FILE="$(mktemp .git/export-index.XXXXXX)" git read-tree -i "$1" git checkout-index -f -a --prefix="$2/" Cheers, Kyle Moffett ``` ## Johannes Schindelin, 2008-11-01 00:37 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0811010137020.22125%40pacific.mpi-cbg.de.mpi-cbg.de In-Reply-To: <20081030150135.GG24098@artemis.corp> ``` Hi, On Thu, 30 Oct 2008, Pierre Habouzit wrote: > On Thu, Oct 30, 2008 at 02:59:28PM +0000, Mike Hommey wrote: > > On Thu, Oct 30, 2008 at 07:52:53AM -0700, Shawn O. Pearce wrote: > > > +1 to Nico's NAK. > > > > > > Although I was at the GitTogether I don't remember this change to > > > checkout being discussed. I must have been asleep reading email > > > or something. I am _NOT_ in favor of this change; I think the > > > current behavior of "git checkout origin/master" is correct and as > > > sane as we can make it. > > > > Except he was talking about 'git checkout branch', not 'git checkout > > origin/branch'. And I would be fine with 'git checkout branch' doing > > what 'git checkout -b branch $remote/branch' does if $remote is unique > > (i.e. there is no other 'branch' branch in any other remote) and the > > 'branch' branch doesn't already exist. > > Seconded. > > Having git-checkout $foo being a shorthand for git checkout -b $foo > origin/$foo when origin/$foo exists and $foo doesn't is definitely handy. Have you guys actually checked out what git checkout -t origin/foo does? Ciao, Dscho ``` ## Elijah Newren, 2008-11-01 18:36 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <51419b2c0811011136uabb544g87e156631d025d33@mail.gmail.com> URL: https://gitlist.dev/e/51419b2c0811011136uabb544g87e156631d025d33%40mail.gmail.com In-Reply-To: <1225338485-11046-1-git-send-email-sam@vilain.net> ``` Hi, Good list.. I agree with others that the 'undo' name doesn't sound right (and will discuss other issues with it in response to another email) but otherwise nice work. On Wed, Oct 29, 2008 at 9:48 PM, Sam Vilain wrote: > + * 'git push' to checked out branch of non-bare repository not > + allowed without special configuration. Configuration available > + that allows working directory to be updated, known caveats > + notwithstanding. Ideally, it would refuse only in situations > + where a broken working copy would be left (because you couldn't > + fix it), and work when it can be known to be safe. Configuration of remote repository, special command-line override, or both? Some food for thought: One thing I did in EasyGit was to disallow pushes to non-bare repositories* unless both source and destinations references were explicitly specified. For example: $ eg push origin master # or 'eg push', in this case Aborting: You are trying to push to a repository with an associated working copy, which will leave its working copy out of sync with its repository. Rather than pushing changes to that repository, you should go to where that repository is located and pull changes into it (using eg pull). If you know what you are doing and know how to deal with the consequences, you can override this check by explicitly specifying source and destination references, e.g. eg push REMOTE BRANCH:REMOTE_BRANCH Please refer to eg help topic refspecs to learn what this syntax means and what the consequences of overriding this check are. $ eg push origin master:master Counting objects: 5, done. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 260 bytes, done. Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/newren/testing/dumb/.git 852ffee..f5596e4 master -> master This seems to prevent errors for new users, while still allowing people to work around firewall issues. * The big problem was that I was only able to detect if a remote repository was bare or not if it was accessed via the local filesystem or via ssh; for git:// (or rsync://) repositories I didn't know how to perform such a check and so I simply omitted it. Elijah ``` ## Elijah Newren, 2008-11-01 19:26 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <51419b2c0811011226p3369b7f7t37b98032ca8dd9ac@mail.gmail.com> URL: https://gitlist.dev/e/51419b2c0811011226p3369b7f7t37b98032ca8dd9ac%40mail.gmail.com In-Reply-To: <20081030143918.GB14744@mit.edu> ``` Hi, On Thu, Oct 30, 2008 at 8:39 AM, Theodore Tso wrote: > Here are my favorites: > > * Add the command "git revert-file " which is syntactic sugar for: > > git checkout HEAD -- > > Rationale: Many other SCM's have a way of undoing local edits to a > file very simply, i.e."hg revert " or "svn revert ", and > for many developers's workflow, it's useful to be able to undo local > edits to a single file, but not to everything else in the working > directory. And "git checkout HEAD -- " is rather cumbersome > to type, and many beginning users don't find it intuitive to look in > the "git-checkout" man page for instructions on how to revert a > local file. I agree with the rationale, but the suggested implementation (as with the original suggestion for "git undo") is somewhat problematic. I have a write-up somewhere documenting the ways various individual git commands fail to be an appropriate replacement for svn/hg/bzr revert[1], but in short the "git checkout HEAD -- " implementation for svn/hg/bzr-like revert fails in the following ways: * It does not work for the initial commit * It won't untrack or remove files (this is related to the previous and following items) * It doesn't allow reverting a file or directory to a revision prior to HEAD (making it like svn; note though that both bzr and hg have such an option and I have found it handy a few times) * It's inappropriate to use during an incomplete merge. The incomplete merge case is particularly interesting. If the user specifies a file or subdirectory, they should also specify a branch to revert relative to (and it should be an error if they don't). If the user specifies "." then there's the question of whether they are attempting to undo the merge (meaning that .git/MERGE_MSG and .git/MERGE_HEAD should be removed). Just as food for thought, here's what eg does in the incomplete merge case: $ eg revert foo Aborting: Cannot revert the changes since the last commit, since you are in the middle of a merge and there are multiple last commits. Please add --since BRANCH to your flags to eg revert, where BRANCH is one of master, devel If you simply want to abort your merge and undo its conflicts, run eg revert --since HEAD There's a couple more issues here that I could go on about, but I'll mention just one more thing for this email: Since users often get confused between different kinds of "reverting" or "undoing", a plain 'eg revert' is also pretty helpful in a wide variety of circumstances (it always aborts with an error message, but one that detects what the user might want and suggests appropriate commands in the various cases.) Elijah [1] There are a number of different commands that people suggest for new users to replace other systems' revert behavior, but each has areas in which it will fail to do what users expect or do additional things users don't want (including discarding data) Interestingly, I've tried four different alternative git porcelains and each one implemented their svn/hg/bzr-like revert incorrectly. One of these was EasyGit, in which I got it wrong not once but three separate times. (And if alternative porcelain authors can't easily get it right, we clearly can't expect normal users to know how to do so; I think this is a pretty good argument for providing a function for this behavior in core git.) I think I finally have it implemented correctly now in EasyGit, after my fourth try... ``` ## Elijah Newren, 2008-11-01 19:42 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <51419b2c0811011242k439c1504ve15dc2faff262224@mail.gmail.com> URL: https://gitlist.dev/e/51419b2c0811011242k439c1504ve15dc2faff262224%40mail.gmail.com In-Reply-To: ``` Hi, On Thu, Oct 30, 2008 at 9:20 AM, Matthieu Moy wrote: > Theodore Tso writes: > >> * Add the command "git revert-file " which is syntactic sugar for: >> >> git checkout HEAD -- > > I don't think "revert-file" is a good name for this: although other > SCM often call this "revert", what Git calls "revert" is about > reverting an existing commit (it's "backout" in hg for example). The > terminology to revert the working tree to the last commited version is > already here in Git, it's "reset". git's reset is _not_ the same as svn/bzr/hg's revert; and it's overlap in functionality is smaller than you realize. > I've already argued in favor of allowing "git reset --hard ", > which is consistant with existing terminology and doesn't add an extra > command, but without success. Such a command would * delete newly added files instead of simply untracking them. That's the right thing for reset, but not for a svn/bzr/hg-like revert (and unfortunately means unintended data loss.) * doesn't make sense during an incomplete merge, unless you add some way of specifying which branch users want to revert their files back to. Aren't there enough confusing flags for reset already? (One surprisingly common comment I get about eg is that git reset is too hard to understand and eg reset fixes it -- despite the fact that I merely renamed two flags and hid the second form of the command.) * doesn't work for the initial commit * provides no way to revert files or subdirectories back to their state at some previous revision (hg and bzr revert have a flag to provide this; it's not useful all the time but is on occasion) Also, if users try to modify their command slightly to get such behavior, say 'git reset --hard REVISION' instead of 'git reset --hard .', then they're in trouble. (Recoverable, but they need an 'expert' to help them now.) Also, there's three different kinds of "undo": switching to an old revision (git checkout REVISION, or svn/hg update -r, etc.), forgetting or discarding commits/merges/rebases (git reset), and modifying files to undo previous modifications without touching HEAD (svn/bzr/hg revert). Users get confused enough between these different kinds of undo; overloading them further would be really bad, IMO. (Part of the reason for users getting confused between these kinds of undo is the fact that git doesn't implemented svn/bzr/hg-like revert, and tends to steer them towards git checkout and git reset, which are commands typically meant for the *other* kinds of undo.) Just my $0.02, Elijah ``` ## Elijah Newren, 2008-11-01 19:57 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <51419b2c0811011257v74a75053la59755e7dabe2f09@mail.gmail.com> URL: https://gitlist.dev/e/51419b2c0811011257v74a75053la59755e7dabe2f09%40mail.gmail.com In-Reply-To: <4909CC85.1080803@op5.se> ``` Hi, On Thu, Oct 30, 2008 at 9:02 AM, Andreas Ericsson wrote: > I like it, although I guess one would have to add a "--staged" flag to > git revert-file to be able to checkout files from index as well, or people > will wonder why that can't be done. Ew. 'git revert-file --staged foo'? If you want to revert the *unstaged* changes of a file, it should be 'git revert-file --unstaged foo'. I would expect 'git revert-file --staged foo' to revert the staged changes in foo, i.e. it should do what 'git reset -- foo' does (except that it should also work for the initial commit). Thus, there'd be little need for a --staged flag to revert-file, unless we allowed reverting individual files back to some revision prior to HEAD (like bzr and hg do)... ``` ## Elijah Newren, 2008-11-01 20:27 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <51419b2c0811011327j492b520dq2388fc8972b48cab@mail.gmail.com> URL: https://gitlist.dev/e/51419b2c0811011327j492b520dq2388fc8972b48cab%40mail.gmail.com In-Reply-To: <1225389068.19891.28.camel@maia.lan> ``` Hi, (Sorry for sending so many emails, and being late to the conversation. There's a couple others that I wanted to respond to but I'll wait off on those and finish with this email to avoid spamming everyone any more right now.) On Thu, Oct 30, 2008 at 11:51 AM, Sam Vilain wrote: > Well, I don't have strong feelings on the exact command name used; I > suggested "undo", probably also ambiguous. But still, a significant > number of users are surprised when they type 'git revert' and they get a > backed out patch. It's such an uncommon operation, it doesn't deserve > to be triggered so easily. And reverting files to the state in the > index and/or HEAD is a common operation that deserves being short to > type. > > Making it plain "revert" would violate expectations of existing users; > it seems a better idea to just deprecate it, and point the users to the > new method - cherry-pick --revert - or the command they might have meant > - whatever that becomes. There is another option, though it has its own problems too. There are basically two kinds of reverting here -- reverting all the changes *in* a given revision (which I'll called 'revert-in') and reverting all the changes *since* a given revision (typically HEAD; I'll call this 'revert-since'). These two operations can be supported from the same command, though their use cases are different enough that it may seem slightly weird: revert-since revert-in * is usually used in a dirty tree * is typically used in a clean tree * specific paths are usually * specific paths are not often specified specified * it is rare to want to commit * making a commit after reverting immediately after reverting is what you usually want * it is uncommon to need to specify a revision I decided to combine them in EasyGit, simply because that made things the most discoverable for both existing git and svn/bzr/hg users. The big problem here is that --commit is turned on by default when --in is specified, and --no-commit is the default when --since is specified. Anyway, some examples: eg revert REVISION => Error -- you must specify either --since or --in when specifying a revision eg revert --in REVISION => Same as git revert REVISION eg revert --since HEAD FILE1 FILE2 => Same as svn revert FILE1 FILE2 eg revert FILE1 FILE2 => shorthand for the previous command; --since HEAD is default when no revision is specified eg revert --since HEAD~3 SUBDIRECTORY => should be clear; an extension over what svn revert can do Then there's also the possibility that users only want to revert unstaged changes, or only want to revert staged changes... Anyway, just some food for thought. I've spammed the list enough in this thread, so I'll break for now. Thanks for listening. Elijah ``` ## Theodore Tso, 2008-11-02 01:06 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <20081102010634.GF8134@mit.edu> URL: https://gitlist.dev/e/20081102010634.GF8134%40mit.edu In-Reply-To: <51419b2c0811011327j492b520dq2388fc8972b48cab@mail.gmail.com> ``` On Sat, Nov 01, 2008 at 02:27:03PM -0600, Elijah Newren wrote: > > There is another option, though it has its own problems too. There > are basically two kinds of reverting here -- reverting all the changes > *in* a given revision (which I'll called 'revert-in') and reverting > all the changes *since* a given revision (typically HEAD; I'll call > this 'revert-since'). These two operations can be supported from the > same command, though their use cases are different enough that it may > seem slightly weird: In my opinion, that is a Really Bad Idea from a usability and UI design point of view. Each command should do one and only one thing, and not do different things depending on what options you give it. Git violates this rules in a number of places already, What you call "revert-since" and "revert-in" are so different that using the same subcommand is just going to horribly confuse users. Better to have "git revert" print a message explining that it is deprecated, and to tell users that they probably want either "git cherry-pick --revert" or "git revert-file", depending on whether they are an experienced git user (in which case they probably want git cherry-pick --revert"), or if that person who is familiar svn or hg's "svn revert" or "hg revert", they probably want "git revert-file". - Ted ``` ## Elijah Newren, 2008-11-02 04:41 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <51419b2c0811012141x1620f111rbebc836f816c7b4e@mail.gmail.com> URL: https://gitlist.dev/e/51419b2c0811012141x1620f111rbebc836f816c7b4e%40mail.gmail.com In-Reply-To: <20081102010634.GF8134@mit.edu> ``` On Sat, Nov 1, 2008 at 7:06 PM, Theodore Tso wrote: > In my opinion, that is a Really Bad Idea from a usability and UI > design point of view. Each command should do one and only one thing, > and not do different things depending on what options you give it. > Git violates this rules in a number of places already, What you call > "revert-since" and "revert-in" are so different that using the same > subcommand is just going to horribly confuse users. > > Better to have "git revert" print a message explining that it is > deprecated, and to tell users that they probably want either "git > cherry-pick --revert" or "git revert-file", depending on whether they > are an experienced git user (in which case they probably want git > cherry-pick --revert"), or if that person who is familiar svn or hg's > "svn revert" or "hg revert", they probably want "git revert-file". Yeah, good points. I guess I could just make --no-commit the default in all cases to remove the "magic", but then it's too much typing for the revert-in case ("eg revert --commit --in REVISION" vs. "git revert REVISION"). Two separate commands may make more sense, but then there's the naming issue (I had difficulty coming up with a different name that I liked, and it appears others are having a little trouble with the naming too). Tough nut to crack from any angle. :-( ``` ## Junio C Hamano, 2008-11-02 06:08 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <7v1vxu4q49.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7v1vxu4q49.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20081030163056.GA8899@mit.edu> ``` Theodore Tso writes: > On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote: >> >> git format-patch origin/next.. works already. I'm used to the asymetric >> git format-patch origin/next syntax, and I would be sorry if it >> disappeared though, and I see no really good reason to get rid of it. > > The reason why it annoys me is because I often what to cherry-pick a > single patch to send to someone, and so while "git show 332d2e78" > shows me the patch, but if I want to use git-send-email for that > particular patch, "git format-patch 332d2e78" doesn't DTRT. I have to > type "git format-patch 332d2e78^..332d2e78" instead. > ... > (And I get annoyed when I want to run git format-patch on a single > patch not at the tip of the tree; but if it's just me, I can write a > "git format-single-patch" wrapper script to get around it.) Huh? I am so used to "git format-patch -1 HEAD" (or "332d2e78") that I am very surprised. ``` ## Theodore Tso, 2008-11-02 10:09 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <20081102100915.GI8134@mit.edu> URL: https://gitlist.dev/e/20081102100915.GI8134%40mit.edu In-Reply-To: <7v1vxu4q49.fsf@gitster.siamese.dyndns.org> ``` On Sat, Nov 01, 2008 at 11:08:06PM -0700, Junio C Hamano wrote: > > (And I get annoyed when I want to run git format-patch on a single > > patch not at the tip of the tree; but if it's just me, I can write a > > "git format-single-patch" wrapper script to get around it.) > > Huh? I am so used to "git format-patch -1 HEAD" (or "332d2e78") that I am > very surprised. Well, the explanation is that "-" isn't in the SYNPOSIS section of 'git format-patch', and so I never knew you could do it that way. A new user of git has to paw through approximately 50 options in the OPTIONS section of the man page before finding "-"; and somehow I've always missed it. I'd suggest adding an explicit mention of - to the DESCRIPTION section, perhaps in the paragraph: A single commit, when interpreted as a expression, means "everything that leads to that commit", but if you write git format-patch , the previous rule applies to that command line and you do not get "everything since the beginning of the time". If you want to format everything since project inception to one commit, say "git format-patch --root " to make it clear that it is the latter case. Adding the sentence: If you want to format a single commit, you can do this via "git format-patch -1 " or the more esoteric and perl-ish, "git format-patch ^!" might be helpful. - Ted ``` ## Junio C Hamano, 2008-11-02 21:53 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <7vy70123rr.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vy70123rr.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20081030132453.GB24098@artemis.corp> ``` Pierre Habouzit writes: > * 'git track' would do what git add -N does now. > * 'git untrack' would do what 'git rm --cached' does now. Ok with me up to here. >> + * 'git undo' would do what 'git checkout HEAD --' does now > ... > I have no constructive proposal to replace it though, but I believe git > undo would cause lots of harm. I'm in agreement. > * git-send-email should be either more interactive, or less: either > just use the damn configuration, or propose a mode where it spawns > an editor for each patch so that you can add further comments. In principle I'd agree, but I use send-email non-interactively myself (I type Meta/SE where Meta is an independent checkout of my 'todo' branch), so I am not sure if the "just use the configuration" is an added requirement. I also have this in .git/config in the repo: [sendemail] smtpserver = /usr/bin/msmtp to = git@vger.kernel.org suppressfrom signedoffcc = false > * git-send-email should be able to format-patches by himself (IOW > accept most of format-patch arguments and deal with the patch list > by himself, which is usable if the previous point is implemented). I earlier was against this, mostly out of the "each tool to do the job it was designed to do well" principle, but with your workflow description and Peff's comment, I am open to add this kind of "run format-patch internally" wrapper behaviour to send-email which is already a Porcelain anyway. >> + * 'git am -3' the default; with global option to make it not the >> + default for those that prefer the speed of -2 I am moderately negative on this, but not because of performance concern. The --3way fall back is done only when it is necessary, and there is no "prefer the speed" involved. It is between "stop when the patch does not apply because there may be something iffy going on" and "assume it is Ok in such an iffy case to pretend that you apply the patch to the original copy and cherry-pick the result to your updated tree". IOW, it is a safety concern. ``` ## Junio C Hamano, 2008-11-02 22:01 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <7vtzap23f3.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vtzap23f3.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20081030143918.GB14744@mit.edu> ``` Theodore Tso writes: > Here are my favorites: > > * Add the command "git revert-file " which is syntactic sugar for: > > git checkout HEAD -- This is good; I do not recall offhand what we do if some of the do not appear in HEAD right now, but I have a suspicion that it would be a no-op, in which case interested parties may first want to fix checkout to remove such paths. Also I thiink you can add "git revert-commit [$committish]" as a synonym to the current "git revert [$committish]" if it makes things easier to explain to others. > * Change the argument handling for "git format-patch" so it is > consistent with everything else which takes a set of commits. Yes, > it means that where people have gotten used to typing "git > format-patch origin", they'll have to type instead: "git > format-patch origin..", but's much more consistent. I think that has already happened some time ago in the sense that you can say "origin.." and it does what you want. I do not think it merits to deprecate the original one --- if you do not like it, you do not use it nor teach it to others. ``` ## Junio C Hamano, 2008-11-02 22:17 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <7vabch22ou.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vabch22ou.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20081030170329.GK24098@artemis.corp> ``` Pierre Habouzit writes: > On Thu, Oct 30, 2008 at 05:00:18PM +0000, Nicolas Pitre wrote: > >> If you have a file argument, the --hard option is redundant, isn't it? >> So what about simply "git reset " ? > > errrrm, git reset resets the index notion of the file to its status > in HEAD... which I'm sure is *somehow* useful to "some" people ;P I'd agree that 'reset' is rather unfortunate. It very originally was all about the index (the "mixed" semantics, specifically "git reset" without any committish nor any pathspec, was the original use case) and nothing else. IOW, "I staged a wrong change, let's start over by discarding all staged changes". A logical extension to it is "git reset -- pathspec", IOW, "I know which paths I fubared, please reset only these paths, as other staged changes are Ok". So "reset " is very much useful. Then 'reset' learned to also muck with HEAD, so "reset HEAD^" (still mixed, without any pathspec) can be used to amend the latest commit but without losing the state you would eventually want to arrive at. A logical extension to this was "git reset --hard HEAD^" to nuking instead of amending the mistake, and "git reset --soft HEAD^" to save the trouble of staging the changes when the mistake you are fixing is small compared to the entire change. "checkout [$committish] $path" came much later, and the command is all about index and files, and never about resetting HEAD. "checkout $path" does "reset --hard $path" (notice there is no $committish in either one) would have done, so we stopped enhancing the "reset" command in that direction. ``` ## Sam Vilain, 2008-11-03 06:01 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <1225692071.20883.44.camel@maia.lan> URL: https://gitlist.dev/e/1225692071.20883.44.camel%40maia.lan In-Reply-To: <7vabch22ou.fsf@gitster.siamese.dyndns.org> ``` On Sun, 2008-11-02 at 14:17 -0800, Junio C Hamano wrote: > I'd agree that 'reset' is rather unfortunate. It very originally was all > about the index (the "mixed" semantics, specifically "git reset" without > any committish nor any pathspec, was the original use case) and nothing > else. IOW, "I staged a wrong change, let's start over by discarding all > staged changes". A logical extension to it is "git reset -- pathspec", > IOW, "I know which paths I fubared, please reset only these paths, as > other staged changes are Ok". > > So "reset " is very much useful. > > Then 'reset' learned to also muck with HEAD, so "reset HEAD^" (still > mixed, without any pathspec) can be used to amend the latest commit but > without losing the state you would eventually want to arrive at. A > logical extension to this was "git reset --hard HEAD^" to nuking instead > of amending the mistake, and "git reset --soft HEAD^" to save the trouble > of staging the changes when the mistake you are fixing is small compared > to the entire change. > > "checkout [$committish] $path" came much later, and the command is all > about index and files, and never about resetting HEAD. "checkout $path" > does "reset --hard $path" (notice there is no $committish in either one) > would have done, so we stopped enhancing the "reset" command in that > direction. Interesting. I'm wondering whether the important thing here is not making a new command, but simply deprecating "revert", and pointing the user to "git reset" - then making sure that you can do everything revert-like (eg, as Elijah points out) from that command. Sam. ``` ## Sam Vilain, 2008-11-03 08:43 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <1225701813.20883.85.camel@maia.lan> URL: https://gitlist.dev/e/1225701813.20883.85.camel%40maia.lan In-Reply-To: <200810310836.02908.jnareb@gmail.com> ``` On Fri, 2008-10-31 at 08:36 +0100, Jakub Narebski wrote: > > > git checkout --track origin/wr34251-do-something > > > > Ah, that's a new feature. Still, I think it's poorly Huffman coded; far > > too verbose. > > Well, either you have a little bit more verbose, or you have to have > some DWIM-mery, which (as usual with DWIM) can go wrong. That's right, you need to choose when to assume that the user meant something that they didn't write very carefully. But look at this: git checkout origin/master git checkout -t origin/master The option is called "--track", yet in this case what it actually means in the default situation where you have autosetupmerge (or whatever it's really called) set to true, is that it modifies the command to imply "-b master". So, in this situation, that is clearly what was meant. Perhaps you can give an example of why this particular piece of DWIM might not be WYM? Sam. ``` ## Jakub Narebski, 2008-11-03 12:06 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <200811031306.28615.jnareb@gmail.com> URL: https://gitlist.dev/e/200811031306.28615.jnareb%40gmail.com In-Reply-To: <1225701813.20883.85.camel@maia.lan> ``` Dnia poniedziałek 3. listopada 2008 09:43, Sam Vilain napisał: > On Fri, 2008-10-31 at 08:36 +0100, Jakub Narebski wrote: > > > > git checkout --track origin/wr34251-do-something > > > > > > Ah, that's a new feature. Still, I think it's poorly Huffman coded; far > > > too verbose. > > > > Well, either you have a little bit more verbose, or you have to have > > some DWIM-mery, which (as usual with DWIM) can go wrong. > > That's right, you need to choose when to assume that the user meant > something that they didn't write very carefully. > > But look at this: > > git checkout origin/master > > git checkout -t origin/master > > The option is called "--track", yet in this case what it actually means > in the default situation where you have autosetupmerge (or whatever it's > really called) set to true, is that it modifies the command to imply "-b > master". So, in this situation, that is clearly what was meant. > > Perhaps you can give an example of why this particular piece of DWIM > might not be WYM? I was not talking about "git checkout -t origin/master" being shortcut for "git checkout -b master -t origin/master", but about proposed DWIM-mery for "git checkout -b " which would be { git checkout -b -t / git checkout -b = { if there exists / { { git checkout -b HEAD { otherwise -- Jakub Narebski Poland ``` ## Pierre Habouzit, 2008-11-03 13:47 Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp Message-ID: <20081103134722.GF13930@artemis.corp> URL: https://gitlist.dev/e/20081103134722.GF13930%40artemis.corp In-Reply-To: <7vy70123rr.fsf@gitster.siamese.dyndns.org> ``` On Sun, Nov 02, 2008 at 09:53:44PM +0000, Junio C Hamano wrote: > Pierre Habouzit writes: > > * git-send-email should be either more interactive, or less: either > > just use the damn configuration, or propose a mode where it spawns > > an editor for each patch so that you can add further comments. > > In principle I'd agree, but I use send-email non-interactively myself (I > type Meta/SE where Meta is an independent checkout of my 'todo' branch), > so I am not sure if the "just use the configuration" is an added > requirement. I also have this in .git/config in the repo: > > [sendemail] > smtpserver = /usr/bin/msmtp > to = git@vger.kernel.org > suppressfrom > signedoffcc = false Well with my patches it goes _more_ interactive on request only, so that wouldn't break your setup (you have to explicitely pass --annotated and/or --compose). Okay arguably not the feature that auto enables --compose on series of more than 1 patch, but you can redirect send-email to | cat or pass --no-compose for that. Or we can drop that bit of the patch if people find it too cumbersome, I can put that in an alias I don't really care. I really _care_ about not breaking send-email for its previous uses. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org ```