"Ben Peart" <peartben@xxxxxxxxx> writes: > Let me see if I can better explain what I’m trying to accomplish with this > patch. > > "git checkout -b foo" (without -f -m or <start_point>) is defined in the > manual as being a shortcut for/equivalent to: > > (1a) "git branch foo" > (1b) "git checkout foo" > > However, it has been our experience in our observed use cases and all the > existing git tests, that it can be treated as equivalent to: > > (2a) "git branch foo" > (2b) "git symbolic-ref HEAD refs/heads/foo" > > That is, the common perception (use case) is to just create a new branch > "foo" (pointing at the current commit) and point HEAD at it WITHOUT making > any changes to the index or worktree. > > However, the (1b) command has "git reset" connotations in that it should > examine and manipulate the trees, index, and worktree in the expectation > that there MIGHT be work to do. > > Since this additional work in (1b) takes minutes on large repos and (2b) > takes less than a second, my intent was to identify the conditions that this > additional work will have no affect and thereby avoid it. > > Alternatively, was the "-b" option just created as a shortcut only to avoid > calling the separate "git branch foo" command and we should not think about > the common perception and usage? If you are trying to change the definition of "checkout -b" from 1 to 2 above, that is a completely different issue. I thought this was an attempt to optimize for the performance without changing the behaviour. So if you did not apologize like this... > It is correct that this optimization will skip updating the tree to honor > any changes to the sparse-checkout in the case of creating a new branch. > Unfortunately, I don't know of any way to detect the changes other than > actually doing all the work to update the skip work tree bit in the index. ... but insisted that skipping the yucky sparse-checkout adjustment in this case was an intended behaviour change, I would have understood (not necessarily agreed, though) what you were trying to do. > Beyond this code review process and testing, I don't know how else we make > sure we're caught all the conditions where we are OK skipping some of the > steps. Any change has inherent risk - a change in behavior even more so. At least we made one-step progress today. I now know that you are trying to change the behaviour, but I didn't know that last week, when I was primarily reacting that your claim that this was performance thing and assuming you meant no change in behaviour, but there was clearly behaviour change, and it was apparent that the denseness of the code made it almost impossible to see if there are unintended changes. I am still not sure if I like the change of what "checkout -b" is this late in the game, though.