From: Erick Mattos Date: Sat, 20 Mar 2010 20:36:06 GMT Subject: Re: [PATCH] git checkout: create unparented branch by --orphan Message-ID: <55bacdd31003201336u685f4b91u5206ca719609d153@mail.gmail.com> In-Reply-To: <7v4okad9by.fsf@alter.siamese.dyndns.org> 2010/3/20 Junio C Hamano : > Erick Mattos 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. > All right then. I am going to check it too. But in this particular case, the track is being ignored completely. So to break this behavior people will need to add code to --orphan. That's not a break, it's a linkage! :-)