git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Erick Mattos <erick.mattos@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] git checkout: create unparented branch by --orphan
Date: Sat, 20 Mar 2010 13:30:57 -0700	[thread overview]
Message-ID: <7v4okad9by.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <55bacdd31003201206w6215c6a4qec09797fbe060725@mail.gmail.com> (Erick Mattos's message of "Sat\, 20 Mar 2010 16\:06\:56 -0300")

Erick Mattos <erick.mattos@gmail.com> 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.

  reply	other threads:[~2010-03-20 20:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-18 16:09 [PATCH] git checkout: create unparented branch by --orphan Erick Mattos
2010-03-20 15:13 ` Junio C Hamano
2010-03-20 19:06   ` Erick Mattos
2010-03-20 20:30     ` Junio C Hamano [this message]
2010-03-20 20:36       ` Erick Mattos
2010-03-20 20:54         ` Junio C Hamano
2010-03-20 21:37           ` Erick Mattos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v4okad9by.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=erick.mattos@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).