Re: problem with cherry-picking a commit which comes before introducing a new submodule

From: Yaroslav Halchenko <debian@onerussian.com>
Date: Jan 7, 2011, 23:48 UTC
Message-ID: <20110107234841.GQ6040@onerussian.com>
In-Reply-To: <20110107230017.GA15495@burratino>

sorry -- lame me... 1.7.2.3 ... I will check with current version as soon as kids permit ;-)

% apt-cache policy git
git:
  Installed: 1:1.7.2.3-2.2
  Candidate: 1:1.7.2.3-2.2
  Version table:
 *** 1:1.7.2.3-2.2 0
        900 http://debian.lcs.mit.edu/debian/ squeeze/main amd64 Packages
        800 http://debian.lcs.mit.edu/debian/ sid/main amd64 Packages
        100 /var/lib/dpkg/status
% git --version
git version 1.7.2.3

On Fri, 07 Jan 2011, Jonathan Nieder wrote:

> One more piece of protocol: what git version are you using?  The
> release notes mention a fix in this area in v1.7.3[1]:

>  * "git merge -s recursive" (which is the default) did not handle cases
>    where a directory becomes a file (or vice versa) very well.

> Hopefully this is that.  In any case, sounds like a bug.

> (Hopefully someone else can comment on why cherry-pick uses the
> merge machinery to notice conflicts that would not be clear from
> the patch alone.)

> Thanks again.
> Jonathan

> [1] There is an updated Debian source package at [2].  Or, probably
> faster: one can use the build result in bin-wrappers/ from a git.git
> clone in place.
> [2] http://mentors.debian.net/debian/pool/main/g/git/git_1.7.4~rc1-0.1.dsc

-- 
=------------------------------------------------------------------=
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic