Git development
 help / color / mirror / Atom feed
From: "Philip Oakley" <philipoakley@iee.org>
To: "Junio C Hamano" <gitster@pobox.com>,
	"Christian Couder" <christian.couder@gmail.com>
Cc: "Martin von Zweigbergk" <martinvonz@gmail.com>,
	"Git List" <git@vger.kernel.org>,
	"Ramkumar Ramachandra" <artagnon@gmail.com>
Subject: Re: [PATCH 2/2] learn to pick/revert into unborn branch
Date: Sun, 23 Dec 2012 20:27:58 -0000	[thread overview]
Message-ID: <F74DFEF2E8914E76BDA501CA5CD4605F@PhilipOakley> (raw)
In-Reply-To: 7vzk14o9sk.fsf@alter.siamese.dyndns.org

From: "Junio C Hamano" <gitster@pobox.com> Sent: Sunday, December 23,
2012 3:24 AM
Subject: Re: [PATCH 2/2] learn to pick/revert into unborn branch
> Martin von Zweigbergk <martinvonz@gmail.com> writes:
>
>>>From the user's point of view, it seems natural to think that
>> cherry-picking into an unborn branch should work, so make it work,
>> with or without --ff.
>
> I actually am having a hard time imagining how that could ever be
> natural.
>
> When you are on an unborn branch, you may have some files in your
> working tree, and some of them may even be registered to the index,
> but the index is merely for your convenience to create your first
> commit, and as far as the history is concered, it does not matter.
>
> By definition you do not have any history in such a state.  What
> does it even mean to "cherry-pick" another commit, especially
> without the --no-commit option?  The resulting commit will carry the
> message taken from the original commit, but does what it says match
> what you have done?


From: "Junio C Hamano"  Sent: Sunday, December 23, 2012 7:20 PM
Subject: Re: [PATCH 2/2] learn to pick/revert into unborn branch
> Christian Couder <christian.couder@gmail.com> writes:
>
>> I agree that it would be nice if it worked.
>
> That is not saying anything.
>
> Yes, it would be nice if everything worked.  But the question in the
> thread is "with what definition of 'work'?"
> --

>From the dumb user perspective, I would have thought that the first
commit to be cherry picked for an unborn branch would be the complete
commit, which is then planted as the branch's start commit. We tend to
talk of cherry picking commits, though the documentation does say 'the
changes introduced', which allows such a (mistaken) user perspective for
this particular case.

It is only in retrospect, and a bit of extra thought, that one could see
that the commit's message would not actually describe the new situation
and should have been edited.

That doesn't mean that it would be right to allow such an initilisation
of an unborn branch, it's more an explanation of how the idea may have
developed.

Philip

  reply	other threads:[~2012-12-23 20:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-21 19:10 [PATCH 1/2] tests: move test_cmp_rev to test-lib-functions Martin von Zweigbergk
2012-12-21 19:10 ` [PATCH 2/2] learn to pick/revert into unborn branch Martin von Zweigbergk
2012-12-23  3:24   ` Junio C Hamano
2012-12-23  6:24     ` Martin von Zweigbergk
2012-12-23  7:01       ` Christian Couder
2012-12-23 19:20         ` Junio C Hamano
2012-12-23 20:27           ` Philip Oakley [this message]
2012-12-23 19:18       ` Junio C Hamano
2012-12-23 19:35         ` Junio C Hamano
2012-12-24  7:20         ` Martin von Zweigbergk
2012-12-23  4:02   ` Junio C Hamano

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=F74DFEF2E8914E76BDA501CA5CD4605F@PhilipOakley \
    --to=philipoakley@iee.org \
    --cc=artagnon@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=martinvonz@gmail.com \
    /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