Erick Mattos <erick.mattos@xxxxxxxxx> writes: >> With local changes in the index/working tree without "start commit" (which >> should never fail) and with "start commit" (which should fail if HEAD and >> start commit has differences to the same paths as you have local changes >> to). > > It is behaving like that already and that is intrinsically a > switch_branches() logic, not a special --orphan need. It is not part > of this implementation and It is probably tested elsewhere (you > probably do know where). > >> Also you would want to check with -t, --no-t, branch.autosetupmrebe set to >> always in the configuration with -t and without -t from the command line, > > The actual implementation is just ignoring track and -t is not even > allowed. So it is pointless. I think you misunderstood the point of having tests. It is not about demonstrating that you did a good job implementing the new feature, or your implementation works as advertised in the submitted form. That is the job of the review process before patch acceptance. Tests are to pretect what you perfected during the patch acceptance review from getting broken by other people in the future, while you are not closely monitoring the mailing list traffic. Many people, me included, tend to concentrate on their own new addition, without being careful enough not to break the existing features. If "-t --orphan" should result in an error, it should result in an error even after somebody restructures the code, so it is not sufficient that it is obvious in the _current_ code structure that breakage of that feature is unlikely. If you can promise that you will be around on this list forever, and that every time somebody posts patches to the related areas, you will make sure that the changes do not inadvertently break this feature and respond to the patches that do break it before they hit my tree, then theoretically we do not need to have any test to make sure this feature keeps working as advertised. But we cannot ask that kind of time/attention commitment from anybody. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html