| Message ID | 20181129215850.7278-1-pclouds@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce new commands switch-branch and restore-files | expand |
On Thu, Nov 29 2018, Nguyễn Thái Ngọc Duy wrote: > v3 sees switch-branch go back to switch-branch (in v2 it was > checkout-branch). checkout-files is also renamed restore-files (v1 was > restore-paths). Hopefully we won't see another rename. > > I'll try to summarize the differences between the new commands and > 'git checkout' down here, but you're welcome to just head to 07/14 and > read the new man pages. > > 'git switch-branch' > > - does not "do nothing", you have to either switch branch, create a > new branch, or detach. "git switch-branch" with no arguments is > rejected. > > - implicit detaching is rejected. If you need to detach, you need to > give --detach. Or stick to 'git checkout'. > > - -b/-B is renamed to -c/-C with long option names > > - of course does not accept pathspec > > 'git restore-files' > > - takes a ref from --from argument, not as a free ref. As a result, > '--' is no longer needed. All non-option arguments are pathspec > > - pathspec is mandatory, you can't do "git restore-files" without any > pathspec. > > - I just remember -p which is allowed to take no pathspec :( I'll fix > it later. > > - Two more fancy features (the "git checkout --index" being the > default mode and the backup log for accidental overwrites) are of > course still missing. But they are coming. > > I did not go replace "detached HEAD" with "unnamed branch" (or "no > branch") everywhere because I think a unique term is still good to > refer to this concept. Or maybe "no branch" is good enough. I dunno. I finally tracked down https://redfin.engineering/two-commits-that-wrecked-the-user-experience-of-git-f0075b77eab1 which I'd remembered reading and couldn't find again in these discussions. Re-reading it while one may not 100% agree with the author's opinion, it's an interesting rabbit hole. I also didn't know about EasyGit, or that Elijah Newren had written it. I haven't seen him chime in on this series, and would be interested to see what he thinks about it. Re the naming question in https://public-inbox.org/git/87o9abzv46.fsf@evledraar.gmail.com/ & seeing that eg-switch exists, I wonder if just s/switch-branch/switch/ makes more sense. Assuming greenfield development (which we definitely don't have), I don't like the "restore-files" name, but the alternative that makes sense is "checkout". Then this "--from" argument could become "git checkout-tree <treeish> -- <pathspec>", and we'd have: git switch <branchish> git checkout <pathspec> git checkout-tree <treeish> -- <pathspec> Or maybe that sucks, anyway what I was going to suggest is *if* others think that made sense as a "if we designed git today" endgame whether we could have an opt-in setting where you set e.g. core.uiVersion=3 (in anticipation of Git 3.0) and you'd get that behavior. There could be some other setting where core.uiVersion would use the old behavior (or with another setting, only warn) if we weren't connected to a terminal. I.e. I'm thinking of this as step #2 in a #3 step series. Where this is the fully backwards compatible UI improvement, but someone who'd e.g. use EasyGit or didn't have backwards compatibility concerns could enable step #3 and opt-in to a mode where we'd fixed a bunch of UI warts in a backwards-incompatible way. What would that mode look like? I'd to work on piling that on top of this :)
On Thu, Nov 29 2018, Ævar Arnfjörð Bjarmason wrote: > On Thu, Nov 29 2018, Nguyễn Thái Ngọc Duy wrote: > >> v3 sees switch-branch go back to switch-branch (in v2 it was >> checkout-branch). checkout-files is also renamed restore-files (v1 was >> restore-paths). Hopefully we won't see another rename. >> >> I'll try to summarize the differences between the new commands and >> 'git checkout' down here, but you're welcome to just head to 07/14 and >> read the new man pages. >> >> 'git switch-branch' >> >> - does not "do nothing", you have to either switch branch, create a >> new branch, or detach. "git switch-branch" with no arguments is >> rejected. >> >> - implicit detaching is rejected. If you need to detach, you need to >> give --detach. Or stick to 'git checkout'. >> >> - -b/-B is renamed to -c/-C with long option names >> >> - of course does not accept pathspec >> >> 'git restore-files' >> >> - takes a ref from --from argument, not as a free ref. As a result, >> '--' is no longer needed. All non-option arguments are pathspec >> >> - pathspec is mandatory, you can't do "git restore-files" without any >> pathspec. >> >> - I just remember -p which is allowed to take no pathspec :( I'll fix >> it later. >> >> - Two more fancy features (the "git checkout --index" being the >> default mode and the backup log for accidental overwrites) are of >> course still missing. But they are coming. >> >> I did not go replace "detached HEAD" with "unnamed branch" (or "no >> branch") everywhere because I think a unique term is still good to >> refer to this concept. Or maybe "no branch" is good enough. I dunno. > > I finally tracked down > https://redfin.engineering/two-commits-that-wrecked-the-user-experience-of-git-f0075b77eab1 > which I'd remembered reading and couldn't find again in these > discussions. Re-reading it while one may not 100% agree with the > author's opinion, it's an interesting rabbit hole. > > I also didn't know about EasyGit, or that Elijah Newren had written > it. I haven't seen him chime in on this series, and would be interested > to see what he thinks about it. > > Re the naming question in > https://public-inbox.org/git/87o9abzv46.fsf@evledraar.gmail.com/ & > seeing that eg-switch exists, I wonder if just s/switch-branch/switch/ > makes more sense. > > Assuming greenfield development (which we definitely don't have), I > don't like the "restore-files" name, but the alternative that makes > sense is "checkout". Then this "--from" argument could become "git > checkout-tree <treeish> -- <pathspec>", and we'd have: > > git switch <branchish> > git checkout <pathspec> > git checkout-tree <treeish> -- <pathspec> > > Or maybe that sucks, anyway what I was going to suggest is *if* others > think that made sense as a "if we designed git today" endgame whether we > could have an opt-in setting where you set e.g. core.uiVersion=3 (in > anticipation of Git 3.0) and you'd get that behavior. There could be > some other setting where core.uiVersion would use the old behavior (or > with another setting, only warn) if we weren't connected to a terminal. > > I.e. I'm thinking of this as step #2 in a #3 step series. Where this is > the fully backwards compatible UI improvement, but someone who'd > e.g. use EasyGit or didn't have backwards compatibility concerns could > enable step #3 and opt-in to a mode where we'd fixed a bunch of UI warts > in a backwards-incompatible way. > > What would that mode look like? I'd to work on piling that on top of > this :) (Digging some more) There's also more interesting prior art at https://gitless.com/ (CC'd authors) and 2x research papers linked at the bottom of that page which were briefly discussed on-list before: https://public-inbox.org/git/20160930191413.002049b94b3908b15881b77f@domain007.com/ The "gitless" UI has a "gl checkout" which just takes paths as I was musing about above (and that Redfin post also suggests).
Assuming the great day has come to think about this, one thing I'd love to do is to unify the name of the index/stage/cache in command-line parameters and the documentation.
The index/stage/cache should have one canonical name, and the documentation should support that consistently. My taste is to call it the "stage," but references to --index, --keep-index, --no-index, etc. are all over the code, as well as legacy references to "--cached".
* You can 'git rm --cached myfile' but you can't 'git rm --staged myfile' or 'git rm --index myfile'.
* You can 'git diff --no-index' or you can 'git diff --cached' with 'git diff --staged' as a synonym, deprioritized in the documentation ("--staged is a synonym of --cached"). But you can't 'git diff --index' or 'git diff --no-stage' or 'git diff --no-cache'.
* You can 'git stage' but 'git help stage' is only one line long, declaring that it's a synonym for 'git add'. 'add' appears in the 'git help' common commands, but not 'git stage'. There's no built-in 'git unstage', and certainly no appetite for 'git index' or 'git cache'.
* Not to mention all of the plumbing commands: checkout-index, diff-index, index-pack, merge-index, show-index, and update-index.
My understanding based on historical threads is that changes like this would be unwelcome, even just to add synonyms and standardize the documentation around "stage" as the term (leaving the plumbing commands alone), but if documentation+synonym patches are welcome here, I'd be very enthusiastic.
-Dan
> On Nov 29, 2018, at 3:05 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>
>
> On Thu, Nov 29 2018, Nguyễn Thái Ngọc Duy wrote:
>
>> v3 sees switch-branch go back to switch-branch (in v2 it was
>> checkout-branch). checkout-files is also renamed restore-files (v1 was
>> restore-paths). Hopefully we won't see another rename.
>>
>> I'll try to summarize the differences between the new commands and
>> 'git checkout' down here, but you're welcome to just head to 07/14 and
>> read the new man pages.
>>
>> 'git switch-branch'
>>
>> - does not "do nothing", you have to either switch branch, create a
>> new branch, or detach. "git switch-branch" with no arguments is
>> rejected.
>>
>> - implicit detaching is rejected. If you need to detach, you need to
>> give --detach. Or stick to 'git checkout'.
>>
>> - -b/-B is renamed to -c/-C with long option names
>>
>> - of course does not accept pathspec
>>
>> 'git restore-files'
>>
>> - takes a ref from --from argument, not as a free ref. As a result,
>> '--' is no longer needed. All non-option arguments are pathspec
>>
>> - pathspec is mandatory, you can't do "git restore-files" without any
>> pathspec.
>>
>> - I just remember -p which is allowed to take no pathspec :( I'll fix
>> it later.
>>
>> - Two more fancy features (the "git checkout --index" being the
>> default mode and the backup log for accidental overwrites) are of
>> course still missing. But they are coming.
>>
>> I did not go replace "detached HEAD" with "unnamed branch" (or "no
>> branch") everywhere because I think a unique term is still good to
>> refer to this concept. Or maybe "no branch" is good enough. I dunno.
>
> I finally tracked down
> https://redfin.engineering/two-commits-that-wrecked-the-user-experience-of-git-f0075b77eab1
> which I'd remembered reading and couldn't find again in these
> discussions. Re-reading it while one may not 100% agree with the
> author's opinion, it's an interesting rabbit hole.
>
> I also didn't know about EasyGit, or that Elijah Newren had written
> it. I haven't seen him chime in on this series, and would be interested
> to see what he thinks about it.
>
> Re the naming question in
> https://public-inbox.org/git/87o9abzv46.fsf@evledraar.gmail.com/ &
> seeing that eg-switch exists, I wonder if just s/switch-branch/switch/
> makes more sense.
>
> Assuming greenfield development (which we definitely don't have), I
> don't like the "restore-files" name, but the alternative that makes
> sense is "checkout". Then this "--from" argument could become "git
> checkout-tree <treeish> -- <pathspec>", and we'd have:
>
> git switch <branchish>
> git checkout <pathspec>
> git checkout-tree <treeish> -- <pathspec>
>
> Or maybe that sucks, anyway what I was going to suggest is *if* others
> think that made sense as a "if we designed git today" endgame whether we
> could have an opt-in setting where you set e.g. core.uiVersion=3 (in
> anticipation of Git 3.0) and you'd get that behavior. There could be
> some other setting where core.uiVersion would use the old behavior (or
> with another setting, only warn) if we weren't connected to a terminal.
>
> I.e. I'm thinking of this as step #2 in a #3 step series. Where this is
> the fully backwards compatible UI improvement, but someone who'd
> e.g. use EasyGit or didn't have backwards compatibility concerns could
> enable step #3 and opt-in to a mode where we'd fixed a bunch of UI warts
> in a backwards-incompatible way.
>
> What would that mode look like? I'd to work on piling that on top of
> this :)
Other thoughts on a global UI rethink: One of the most common complaints I hear about git is the conceptual difficulty required in undoing changes. https://ohshitgit.com/ > Git is hard: screwing up is easy, and figuring out how to fix your mistakes is fucking impossible. Git documentation has this chicken and egg problem where you can't search for how to get yourself out of a mess, unless you *already know the name of the thing you need to know about* in order to fix your problem. A significant fraction of the top-voted questions on StackOverflow are about undoing changes. https://stackoverflow.com/questions/tagged/git What if there were a 'git undo' command that could unify the answers to all of these questions? git undo stage git undo rm git undo edit (checkout files from the stage) git undo commit (prompt the user whether to revert or reset) git undo reset git undo checkout git undo merge git undo pull git undo push (prompt the user whether to force push back to the past or whether to revert pushed commits) git undo rebase git undo undo git undo clean git undo delete-branch git undo delete-stash Some of these would be trivial effort, but a lot of them would require fundamental changes in the way git operates. (You can't undo a clean right now because the files are just destroyed.) -Dan > On Nov 29, 2018, at 3:05 PM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > > > On Thu, Nov 29 2018, Nguyễn Thái Ngọc Duy wrote: > >> v3 sees switch-branch go back to switch-branch (in v2 it was >> checkout-branch). checkout-files is also renamed restore-files (v1 was >> restore-paths). Hopefully we won't see another rename. >> >> I'll try to summarize the differences between the new commands and >> 'git checkout' down here, but you're welcome to just head to 07/14 and >> read the new man pages. >> >> 'git switch-branch' >> >> - does not "do nothing", you have to either switch branch, create a >> new branch, or detach. "git switch-branch" with no arguments is >> rejected. >> >> - implicit detaching is rejected. If you need to detach, you need to >> give --detach. Or stick to 'git checkout'. >> >> - -b/-B is renamed to -c/-C with long option names >> >> - of course does not accept pathspec >> >> 'git restore-files' >> >> - takes a ref from --from argument, not as a free ref. As a result, >> '--' is no longer needed. All non-option arguments are pathspec >> >> - pathspec is mandatory, you can't do "git restore-files" without any >> pathspec. >> >> - I just remember -p which is allowed to take no pathspec :( I'll fix >> it later. >> >> - Two more fancy features (the "git checkout --index" being the >> default mode and the backup log for accidental overwrites) are of >> course still missing. But they are coming. >> >> I did not go replace "detached HEAD" with "unnamed branch" (or "no >> branch") everywhere because I think a unique term is still good to >> refer to this concept. Or maybe "no branch" is good enough. I dunno. > > I finally tracked down > https://redfin.engineering/two-commits-that-wrecked-the-user-experience-of-git-f0075b77eab1 > which I'd remembered reading and couldn't find again in these > discussions. Re-reading it while one may not 100% agree with the > author's opinion, it's an interesting rabbit hole. > > I also didn't know about EasyGit, or that Elijah Newren had written > it. I haven't seen him chime in on this series, and would be interested > to see what he thinks about it. > > Re the naming question in > https://public-inbox.org/git/87o9abzv46.fsf@evledraar.gmail.com/ & > seeing that eg-switch exists, I wonder if just s/switch-branch/switch/ > makes more sense. > > Assuming greenfield development (which we definitely don't have), I > don't like the "restore-files" name, but the alternative that makes > sense is "checkout". Then this "--from" argument could become "git > checkout-tree <treeish> -- <pathspec>", and we'd have: > > git switch <branchish> > git checkout <pathspec> > git checkout-tree <treeish> -- <pathspec> > > Or maybe that sucks, anyway what I was going to suggest is *if* others > think that made sense as a "if we designed git today" endgame whether we > could have an opt-in setting where you set e.g. core.uiVersion=3 (in > anticipation of Git 3.0) and you'd get that behavior. There could be > some other setting where core.uiVersion would use the old behavior (or > with another setting, only warn) if we weren't connected to a terminal. > > I.e. I'm thinking of this as step #2 in a #3 step series. Where this is > the fully backwards compatible UI improvement, but someone who'd > e.g. use EasyGit or didn't have backwards compatibility concerns could > enable step #3 and opt-in to a mode where we'd fixed a bunch of UI warts > in a backwards-incompatible way. > > What would that mode look like? I'd to work on piling that on top of > this :)
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes: > 'git switch-branch' > > - implicit detaching is rejected. If you need to detach, you need to > give --detach. Or stick to 'git checkout'. OK. Is "auto-vivify the named branch based on a remote-tracking" also rejected, as it is a confusing behaviour that is a too subtle and implicit, just like the detaching head is, and require --guess or sticking to 'git checkout'? I think it should. > - -b/-B is renamed to -c/-C with long option names I did not expect that these two are the only options that would be out of place with the command name split, but presumably you looked at all options for both of the two new commands to see if they made sense in the new context? > 'git restore-files' > > - takes a ref from --from argument, not as a free ref. As a result, > '--' is no longer needed. All non-option arguments are pathspec OK. That does make things easier to teach, as there is no need for disambiguation. > - pathspec is mandatory, you can't do "git restore-files" without any > pathspec. > > - I just remember -p which is allowed to take no pathspec :( I'll fix > it later. Or leave it out of restore-files as a more advanced feature (just like detaching with HEAD^0 is left out of switch-branch) that the user can stick to 'git checkout' to use. > - Two more fancy features (the "git checkout --index" being the > default mode and the backup log for accidental overwrites) are of > course still missing. But they are coming. I am unsure about the wisdom of calling it "--index", though. The "--index" option is "the command can work only on the index, or only on the working tree files, or on both the index and the working tree files, and this option tells it to work in the 'both the index and the working tree files' mode", but when "restore-files" touches paths, it always modifies both the index and the working tree, so the "--index" option does not capture the differences well in this context [*1*]. As I saw this was described as "not using the usual 'overlay' semantics [*2*]", perhaps --overlay/--no-overlay option that defaults to --no-overlay is easier to explain. side note 1. I think the original mention of "--index" came in the context of contrasting "git reset" with "git checkout". "git reset (--hard|--mixed) -- <pathspec>" (that does not move HEAD), which does not but perhaps should exist, is very much like "git checkout -- <pathspec>", and if "reset" were written after the "--index/--cached" convention was established, "reset --hard" would have called "reset --index" while "reset --mixed" would have been "reset --cached" (i.e. only work on the index and not on the working tree). And "reset --index <directory>" would have worked by removing paths in <directory> that are not in the HEAD and updating paths in <directory> that are in the HEAD, i.e. identical to the non overlay behaviour proposed for the "git checkout" command. So calling the non overlay mode "--index" makes sense in the context of discussing "git reset", and not in the context of "git checkout". side note 2. "git checkout <tree-ish> <pathspec>" grabs entries from the <tree-ish> that patch <pathspec> and adds them to the index and checks them out to the working tree. If the original index has entries that match <pathspec> but do not appear in <tree-ish>, they are left in the result. That is "overlaying what was taken from the <tree-ish> on top of what is in the index". Having said all that, I will not be looking at the series until 2.20 final. And I hope more people do the same to concentrate on helping us prevent the last minute glitch slipping in the final release. Thanks.
On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > Assuming greenfield development (which we definitely don't have), I > don't like the "restore-files" name, but the alternative that makes > sense is "checkout". Then this "--from" argument could become "git > checkout-tree <treeish> -- <pathspec>", and we'd have: > > git switch <branchish> > git checkout <pathspec> > git checkout-tree <treeish> -- <pathspec> > > Or maybe that sucks, anyway what I was going to suggest is *if* others > think that made sense as a "if we designed git today" endgame whether we > could have an opt-in setting where you set e.g. core.uiVersion=3 (in > anticipation of Git 3.0) and you'd get that behavior. There could be > some other setting where core.uiVersion would use the old behavior (or > with another setting, only warn) if we weren't connected to a terminal. core.uiVersion is a big no no to me. I don't want to go to someone's terminal, type something and have a total surprise because they set different ui version. If you want a total UI redesign, go with a new prefix, like "ng" (for new git) or something instead of "git".
On Fri, Nov 30, 2018 at 3:16 AM Junio C Hamano <gitster@pobox.com> wrote: > > Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes: > > > 'git switch-branch' > > > > - implicit detaching is rejected. If you need to detach, you need to > > give --detach. Or stick to 'git checkout'. > > OK. Is "auto-vivify the named branch based on a remote-tracking" > also rejected, as it is a confusing behaviour that is a too subtle > and implicit, just like the detaching head is, and require --guess > or sticking to 'git checkout'? I think it should. This touches the "remote" concept which I think is another confusing thing for new people (your "master" is not the same as the server's "master", aka origin/master) and perhaps this dwim thing helps. Frankly I don't do dwim much so I don't know if it's that often used. > > - -b/-B is renamed to -c/-C with long option names > > I did not expect that these two are the only options that would be > out of place with the command name split, but presumably you looked > at all options for both of the two new commands to see if they made > sense in the new context? Yeah (at least the description in struct option[] array) -- Duy
Duy Nguyen <pclouds@gmail.com> writes: >> >> OK. Is "auto-vivify the named branch based on a remote-tracking" >> also rejected, as it is a confusing behaviour that is a too subtle >> and implicit, just like the detaching head is, and require --guess >> or sticking to 'git checkout'? I think it should. > > This touches the "remote" concept which I think is another confusing > thing for new people (your "master" is not the same as the server's > "master", aka origin/master) and perhaps this dwim thing helps. > Frankly I don't do dwim much so I don't know if it's that often used. I actually think a user who sees a DWIM without understanding what the user wants to do would perceive magic that sometimes works and sometimes does not, and some other times it does a random thing that the user does not even understand what is going on. And such a random magic that sometimes works, even if the "sometimes" is "most of the time", say 85% of the time, would not help user form the right mental model. "git checkout master~2" that DWIMs to "git checkout --deatch master~2", but does totally different thing when "git checkout master" is given, leaving the user confused "what is so different between these two?". Until the user realizes 'master' can serve both as a branch name and a name for a commit object, while master~2 can only be a name for a commit object and is not a branch name, the behaviour of the command will stay to be mysterious and DWIMmage would not help user form the right mental model. I earlier said that I agree with your decision to leave the implied form out of switch-branch for exactly that reason. The behaviour falls into the same category as "git checkout frotz" that DWIMS to "git checkout -b frotz -t remotes/origin/frotz", which also is mysterious until the user understands your 'master' is unique and is different from 'master' to everybody else, I would think.
Duy Nguyen <pclouds@gmail.com> writes: > core.uiVersion is a big no no to me. I don't want to go to someone's > terminal, type something and have a total surprise because they set > different ui version. If you want a total UI redesign, go with a new > prefix, like "ng" (for new git) or something instead of "git". Yup, very good point to keep in mind.
On Fri, Nov 30, 2018 at 1:16 AM Dan Fabulich <dan@fabulich.com> wrote: > > Other thoughts on a global UI rethink: > > One of the most common complaints I hear about git is the conceptual difficulty required in undoing changes. https://ohshitgit.com/ > > > Git is hard: screwing up is easy, and figuring out how to fix your mistakes is fucking impossible. Git documentation has this chicken and egg problem where you can't search for how to get yourself out of a mess, unless you *already know the name of the thing you need to know about* in order to fix your problem. > > A significant fraction of the top-voted questions on StackOverflow are about undoing changes. https://stackoverflow.com/questions/tagged/git > > What if there were a 'git undo' command that could unify the answers to all of these questions? > > git undo stage > git undo rm > git undo edit (checkout files from the stage) > > git undo commit (prompt the user whether to revert or reset) > git undo reset > git undo checkout > > git undo merge > git undo pull > git undo push (prompt the user whether to force push back to the past or whether to revert pushed commits) > git undo rebase > > git undo undo > > git undo clean > git undo delete-branch > git undo delete-stash > > Some of these would be trivial effort, but a lot of them would require fundamental changes in the way git operates. (You can't undo a clean right now because the files are just destroyed.) We're getting there. The biggest problem I have is how this "git undo" should work, not the changes behind to support it. For example, if I pulled then did some rebase, what would "git undo pull" do?
On Fri, Nov 30 2018, Duy Nguyen wrote: > On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason > <avarab@gmail.com> wrote: >> Assuming greenfield development (which we definitely don't have), I >> don't like the "restore-files" name, but the alternative that makes >> sense is "checkout". Then this "--from" argument could become "git >> checkout-tree <treeish> -- <pathspec>", and we'd have: >> >> git switch <branchish> >> git checkout <pathspec> >> git checkout-tree <treeish> -- <pathspec> >> >> Or maybe that sucks, anyway what I was going to suggest is *if* others >> think that made sense as a "if we designed git today" endgame whether we >> could have an opt-in setting where you set e.g. core.uiVersion=3 (in >> anticipation of Git 3.0) and you'd get that behavior. There could be >> some other setting where core.uiVersion would use the old behavior (or >> with another setting, only warn) if we weren't connected to a terminal. > > core.uiVersion is a big no no to me. I don't want to go to someone's > terminal, type something and have a total surprise because they set > different ui version. If you want a total UI redesign, go with a new > prefix, like "ng" (for new git) or something instead of "git". I don't think that's a viable way forward. First, we're not talking about a total change of the UI. Most the main porcelain will stay the same. So we'd have a "ng" that's >98% the same UI, and then if we discover warts in in 10 years we'd like to fix then what do wo do? Ship "nng" and so forth? We already have this UI problem with various config variables that change things. I think we should just solve this general issue by a combination of: a) Accepting that over the long term we will have Git's UI changing, sometimes in breaking ways (with sensible phase-in), hopefully for the better. E.g. we had this with "git-init" v.s. "git init". This is similar, there'd be an error due to ambiguity with a "hint" saying use the new thing if you e.g. feed "git checkout" a branch name. b) For the general problem of "user has exotic config" we should learn a "git -Q <cmd>" option similar to Emacs, which is another highly customizable piece of software that has a "don't read user config" escape hatch. That's a bit more complex than for Emacs since we need to actually read some config (e.g. remote config from .git/config), and maybe opt to keep some stuff like user.*. But there's no reason we can't have such a black/whitelist of config & env variables that impact us with a switch to get "make it as if nothing was configured" for whatever sane version of that we'd come up with.
On Fri, Nov 30, 2018 at 12:29 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > > > On Fri, Nov 30 2018, Duy Nguyen wrote: > > > On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason > > <avarab@gmail.com> wrote: > >> Assuming greenfield development (which we definitely don't have), I > >> don't like the "restore-files" name, but the alternative that makes > >> sense is "checkout". Then this "--from" argument could become "git > >> checkout-tree <treeish> -- <pathspec>", and we'd have: > >> > >> git switch <branchish> > >> git checkout <pathspec> > >> git checkout-tree <treeish> -- <pathspec> > >> > >> Or maybe that sucks, anyway what I was going to suggest is *if* others > >> think that made sense as a "if we designed git today" endgame whether we > >> could have an opt-in setting where you set e.g. core.uiVersion=3 (in > >> anticipation of Git 3.0) and you'd get that behavior. There could be > >> some other setting where core.uiVersion would use the old behavior (or > >> with another setting, only warn) if we weren't connected to a terminal. > > > > core.uiVersion is a big no no to me. I don't want to go to someone's > > terminal, type something and have a total surprise because they set > > different ui version. If you want a total UI redesign, go with a new > > prefix, like "ng" (for new git) or something instead of "git". > > I don't think that's a viable way forward. First, we're not talking > about a total change of the UI. Most the main porcelain will stay the > same. So we'd have a "ng" that's >98% the same UI, and then if we > discover warts in in 10 years we'd like to fix then what do wo do? Ship > "nng" and so forth? Yes. So think it through and try not to do it often. > We already have this UI problem with various config variables that > change things. I think we should just solve this general issue by a > combination of: > > a) Accepting that over the long term we will have Git's UI changing, > sometimes in breaking ways (with sensible phase-in), hopefully for > the better. E.g. we had this with "git-init" v.s. "git init". This > is similar, there'd be an error due to ambiguity with a "hint" > saying use the new thing if you e.g. feed "git checkout" a branch > name. And I hate adding a zillion of config keys to change little things like this. Now you use this to change bigger behavior. No.
On 11/30, Junio C Hamano wrote: > > I am unsure about the wisdom of calling it "--index", though. > > The "--index" option is "the command can work only on the index, or > only on the working tree files, or on both the index and the working > tree files, and this option tells it to work in the 'both the index > and the working tree files' mode", but when "restore-files" touches > paths, it always modifies both the index and the working tree, so > the "--index" option does not capture the differences well in this > context [*1*]. As I saw this was described as "not using the usual > 'overlay' semantics [*2*]", perhaps --overlay/--no-overlay option > that defaults to --no-overlay is easier to explain. Agreed, I think --{no-,}overlay is a much better name for the option, I'll use that for my patch series (I hope to send that soon after 2.20 is released). I must admit that I was not aware that the mode is called overlay mode, before you explained it to me, so I wouldn't expect most users to know either. But as it's easy to explain that probably doesn't matter much. > side note 1. I think the original mention of "--index" came in > the context of contrasting "git reset" with "git checkout". > "git reset (--hard|--mixed) -- <pathspec>" (that does not move > HEAD), which does not but perhaps should exist, is very much > like "git checkout -- <pathspec>", and if "reset" were written > after the "--index/--cached" convention was established, "reset > --hard" would have called "reset --index" while "reset --mixed" > would have been "reset --cached" (i.e. only work on the index > and not on the working tree). And "reset --index <directory>" > would have worked by removing paths in <directory> that are not > in the HEAD and updating paths in <directory> that are in the > HEAD, i.e. identical to the non overlay behaviour proposed for > the "git checkout" command. So calling the non overlay mode > "--index" makes sense in the context of discussing "git reset", > and not in the context of "git checkout". > > side note 2. "git checkout <tree-ish> <pathspec>" grabs entries > from the <tree-ish> that patch <pathspec> and adds them to the > index and checks them out to the working tree. If the original > index has entries that match <pathspec> but do not appear in > <tree-ish>, they are left in the result. That is "overlaying > what was taken from the <tree-ish> on top of what is in the > index". > > Having said all that, I will not be looking at the series until 2.20 > final. And I hope more people do the same to concentrate on helping > us prevent the last minute glitch slipping in the final release. > > Thanks.
Thomas Gummerer <t.gummerer@gmail.com> writes: > Agreed, I think --{no-,}overlay is a much better name for the option, > I'll use that for my patch series (I hope to send that soon after 2.20 > is released). OK. > I must admit that I was not aware that the mode is called overlay > mode, before you explained it to me, so I wouldn't expect most users > to know either. But as it's easy to explain that probably doesn't > matter much. I do not think "the mode is called the overlay mode" is so accurate a description. I think I've seen the word 'overlay' used to describe the behaviour in earlier discussions, but because there is no 'non-overlay' mode exists in versions of 'git checkout' the end-users have, the users won't even be aware of the possibility that mode different from what they are used to see could exist, or that the mode that they are used to see could be called/explained as the 'overlay' mode. IOW, we should pick the best phrase to explain the behaviour we can use when coming up with the command line option, and that phrase does not have to be 'overlay'---there is no "using the word 'overlay' for this is good because the users are familiar with the existing use of the word", simply because there isn't such familiarilty ;-)
On Thu, Nov 29, 2018 at 2:01 PM Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote: > > v3 sees switch-branch go back to switch-branch (in v2 it was > checkout-branch). checkout-files is also renamed restore-files (v1 was > restore-paths). Hopefully we won't see another rename. I started reading through the patches. I also tried to apply them locally, but they had conflicts or missing base file version on both master and next. What version did you base it on? I stopped at 07/14, and dropped my comments all there. I didn't read any further yet, and may wait for your post-2.20 reroll. > I'll try to summarize the differences between the new commands and > 'git checkout' down here, but you're welcome to just head to 07/14 and > read the new man pages. > > 'git switch-branch' > > - does not "do nothing", you have to either switch branch, create a > new branch, or detach. "git switch-branch" with no arguments is > rejected. > > - implicit detaching is rejected. If you need to detach, you need to > give --detach. Or stick to 'git checkout'. > > - -b/-B is renamed to -c/-C with long option names > > - of course does not accept pathspec > > 'git restore-files' > > - takes a ref from --from argument, not as a free ref. As a result, > '--' is no longer needed. All non-option arguments are pathspec > > - pathspec is mandatory, you can't do "git restore-files" without any > pathspec. > > - I just remember -p which is allowed to take no pathspec :( I'll fix > it later. This all looks good. I commented elsewhere but please remember that pathspec implies directories as a possibility and we really need to fix the broken behavior of checkout when given a directory. > - Two more fancy features (the "git checkout --index" being the > default mode and the backup log for accidental overwrites) are of > course still missing. But they are coming. > > I did not go replace "detached HEAD" with "unnamed branch" (or "no > branch") everywhere because I think a unique term is still good to > refer to this concept. Or maybe "no branch" is good enough. I dunno. I personally like "unnamed branch", but "no branch" would still be better than "detached HEAD".
On Tue, Dec 4, 2018 at 2:29 AM Elijah Newren <newren@gmail.com> wrote: > > On Thu, Nov 29, 2018 at 2:01 PM Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote: > > > > v3 sees switch-branch go back to switch-branch (in v2 it was > > checkout-branch). checkout-files is also renamed restore-files (v1 was > > restore-paths). Hopefully we won't see another rename. > > I started reading through the patches. I also tried to apply them > locally, but they had conflicts or missing base file version on both > master and next. What version did you base it on? I think nd/checkout-dwim-fix because of a non-trivial conflict there (but I don't remember when I noticed it and rebased on that). Anyway you can get the whole series at https://gitlab.com/pclouds/git/tree/switch-branch-and-checkout-files It fixes some of your comments already, a couple of bug fixes here and there and in a good-enough shape that I start actually using it. > > - Two more fancy features (the "git checkout --index" being the > > default mode and the backup log for accidental overwrites) are of > > course still missing. But they are coming. > > > > I did not go replace "detached HEAD" with "unnamed branch" (or "no > > branch") everywhere because I think a unique term is still good to > > refer to this concept. Or maybe "no branch" is good enough. I dunno. > > I personally like "unnamed branch", but "no branch" would still be > better than "detached HEAD". Haven't really worked on killing the term "detached HEAD" yet. But I noticed the other day that git-branch reports * (HEAD detached from 703266f6e4) and I didn't know how to rephrase that. I guess "unnamed branch from 703266f6e4" is probably good enough but my old-timer brain screams no.
On Tue, Dec 4, 2018 at 8:28 AM Duy Nguyen <pclouds@gmail.com> wrote: > > On Tue, Dec 4, 2018 at 2:29 AM Elijah Newren <newren@gmail.com> wrote: > > > > On Thu, Nov 29, 2018 at 2:01 PM Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote: > > > > > > v3 sees switch-branch go back to switch-branch (in v2 it was > > > checkout-branch). checkout-files is also renamed restore-files (v1 was > > > restore-paths). Hopefully we won't see another rename. > > > > I started reading through the patches. I also tried to apply them > > locally, but they had conflicts or missing base file version on both > > master and next. What version did you base it on? > > I think nd/checkout-dwim-fix because of a non-trivial conflict there > (but I don't remember when I noticed it and rebased on that). Anyway > you can get the whole series at > > https://gitlab.com/pclouds/git/tree/switch-branch-and-checkout-files > > It fixes some of your comments already, a couple of bug fixes here and > there and in a good-enough shape that I start actually using it. Cool. > > > - Two more fancy features (the "git checkout --index" being the > > > default mode and the backup log for accidental overwrites) are of > > > course still missing. But they are coming. > > > > > > I did not go replace "detached HEAD" with "unnamed branch" (or "no > > > branch") everywhere because I think a unique term is still good to > > > refer to this concept. Or maybe "no branch" is good enough. I dunno. > > > > I personally like "unnamed branch", but "no branch" would still be > > better than "detached HEAD". > > Haven't really worked on killing the term "detached HEAD" yet. But I > noticed the other day that git-branch reports > > * (HEAD detached from 703266f6e4) > > and I didn't know how to rephrase that. I guess "unnamed branch from > 703266f6e4" is probably good enough but my old-timer brain screams no. Perhaps "* (On an unnamed branch, at 703266f6e4)"?
On Tue, Dec 4, 2018 at 6:45 PM Elijah Newren <newren@gmail.com> wrote: > > > > - Two more fancy features (the "git checkout --index" being the > > > > default mode and the backup log for accidental overwrites) are of > > > > course still missing. But they are coming. > > > > > > > > I did not go replace "detached HEAD" with "unnamed branch" (or "no > > > > branch") everywhere because I think a unique term is still good to > > > > refer to this concept. Or maybe "no branch" is good enough. I dunno. > > > > > > I personally like "unnamed branch", but "no branch" would still be > > > better than "detached HEAD". > > > > Haven't really worked on killing the term "detached HEAD" yet. But I > > noticed the other day that git-branch reports > > > > * (HEAD detached from 703266f6e4) > > > > and I didn't know how to rephrase that. I guess "unnamed branch from > > 703266f6e4" is probably good enough but my old-timer brain screams no. > > Perhaps "* (On an unnamed branch, at 703266f6e4)"? This 703266f6e4 is the fork point. Once you start adding more commits on top of this unnamed branch, I find it hard to define it "at" 703266f6e4 anymore. "forked from 703266f6e4" (or even starting/growing from...) is probably clearest but also a bit longer.
On Tue, Dec 4, 2018 at 10:22 AM Duy Nguyen <pclouds@gmail.com> wrote: > > On Tue, Dec 4, 2018 at 6:45 PM Elijah Newren <newren@gmail.com> wrote: > > > > > - Two more fancy features (the "git checkout --index" being the > > > > > default mode and the backup log for accidental overwrites) are of > > > > > course still missing. But they are coming. > > > > > > > > > > I did not go replace "detached HEAD" with "unnamed branch" (or "no > > > > > branch") everywhere because I think a unique term is still good to > > > > > refer to this concept. Or maybe "no branch" is good enough. I dunno. > > > > > > > > I personally like "unnamed branch", but "no branch" would still be > > > > better than "detached HEAD". > > > > > > Haven't really worked on killing the term "detached HEAD" yet. But I > > > noticed the other day that git-branch reports > > > > > > * (HEAD detached from 703266f6e4) > > > > > > and I didn't know how to rephrase that. I guess "unnamed branch from > > > 703266f6e4" is probably good enough but my old-timer brain screams no. > > > > Perhaps "* (On an unnamed branch, at 703266f6e4)"? > > This 703266f6e4 is the fork point. Once you start adding more commits > on top of this unnamed branch, I find it hard to define it "at" > 703266f6e4 anymore. "forked from 703266f6e4" (or even starting/growing > from...) is probably clearest but also a bit longer. It reports the fork point rather than the commit HEAD points to? Ah, I guess I never payed that close of attention before. I actually think "on an unnamed branch" is good enough, but if others gain value from the extra info, then I understand the conundrum. I'm not sure what the use or rationale is for the fork point, though, so I feel slightly at a loss to try to describe this extra piece of info.
On Tue, Dec 4, 2018 at 7:31 PM Elijah Newren <newren@gmail.com> wrote: > > On Tue, Dec 4, 2018 at 10:22 AM Duy Nguyen <pclouds@gmail.com> wrote: > > > > On Tue, Dec 4, 2018 at 6:45 PM Elijah Newren <newren@gmail.com> wrote: > > > > > > - Two more fancy features (the "git checkout --index" being the > > > > > > default mode and the backup log for accidental overwrites) are of > > > > > > course still missing. But they are coming. > > > > > > > > > > > > I did not go replace "detached HEAD" with "unnamed branch" (or "no > > > > > > branch") everywhere because I think a unique term is still good to > > > > > > refer to this concept. Or maybe "no branch" is good enough. I dunno. > > > > > > > > > > I personally like "unnamed branch", but "no branch" would still be > > > > > better than "detached HEAD". > > > > > > > > Haven't really worked on killing the term "detached HEAD" yet. But I > > > > noticed the other day that git-branch reports > > > > > > > > * (HEAD detached from 703266f6e4) > > > > > > > > and I didn't know how to rephrase that. I guess "unnamed branch from > > > > 703266f6e4" is probably good enough but my old-timer brain screams no. > > > > > > Perhaps "* (On an unnamed branch, at 703266f6e4)"? > > > > This 703266f6e4 is the fork point. Once you start adding more commits > > on top of this unnamed branch, I find it hard to define it "at" > > 703266f6e4 anymore. "forked from 703266f6e4" (or even starting/growing > > from...) is probably clearest but also a bit longer. > > It reports the fork point rather than the commit HEAD points to? Ah, > I guess I never payed that close of attention before. I actually > think "on an unnamed branch" is good enough, but if others gain value > from the extra info, then I understand the conundrum. I'm not sure > what the use or rationale is for the fork point, though, so I feel > slightly at a loss to try to describe this extra piece of info. It's probably a corner case. This is a better example * (HEAD detached at pclouds/backup-log) It does help see i'm working on top of some branch (or tag)
On Tue, Dec 4, 2018 at 11:28 AM Duy Nguyen <pclouds@gmail.com> wrote: > Haven't really worked on killing the term "detached HEAD" yet. But I > noticed the other day that git-branch reports > > * (HEAD detached from 703266f6e4) > > and I didn't know how to rephrase that. I guess "unnamed branch from > 703266f6e4" is probably good enough but my old-timer brain screams no. "git worktree add" and "git worktree show" also report similar messages.