Hey David,

Did this give you the repro case that you needed?
- Harpreet "Eli" Sangha


On Thu, Jun 23, 2016 at 7:32 PM, ELI <elip...@gmail.com> wrote:
> Attempting to resend without HTML...
>
> - Harpreet "Eli" Sangha
>
>
> On Thu, Jun 23, 2016 at 7:18 PM, ELI <elip...@gmail.com> wrote:
>> Sorry for the delayed response... your email somehow found it's way into my
>> Gmail spam folder.
>>
>> I've created a simple reproduction case and hosted the test repositories on
>> BitBucket for sharing:
>> https://bitbucket.org/eliptus/subtree-test-sup
>> https://bitbucket.org/eliptus/subtree-test-suba
>> https://bitbucket.org/eliptus/subtree-test-subb
>> https://bitbucket.org/eliptus/subtree-test-subc
>>
>> Quick Repro Step:
>> git -C Sup subtree push --prefix=c SubC working
>>
>> You can reproduce the behavior I describe previously with the test
>> repositories by simply attempting a subtree push from Sup to SubC.  The
>> result is that SubC contains commit history for changes make exclusively to
>> SubA and SubB.  Below are details of how I got to this state.
>>
>> Test Setup:
>>
>> Created four new git repositories with initial commits: Sup, SubA, SubB,
>> SubC
>>
>> The branch "working" in repository SubC still reflects the state after this
>> step.
>>
>> Performed "subtree add" for SubA, SubB, and SubC into Sup with prefixes a,
>> b, and c, respectively.
>> Added additional commits directly in repositories SubA and SubB.
>>
>> The branch "master" in repositories SubA and SubB still reflect the state
>> after this step.
>>
>> Performed "subtree pull" from SubA and SubB to Sup.
>> Added a commit in repository Sup that modifies prefix "c".
>>
>> The branch "master" in repository Sup still reflects the state after this
>> step.
>>
>> Performed "subtree push" to SubC from Sup.
>>
>> The branch "master" in repository SubC still reflects the state after this
>> step.
>> A "git log --patch master" in repository SubC shows commit's made in SubA
>> and SubB.
>>
>>
>> Regards,
>>
>> On Sat, May 21, 2016 at 4:06 PM David A. Greene <gree...@obbligato.org>
>> wrote:
>>>
>>> ELI <elip...@gmail.com> writes:
>>>
>>> > I then reviewed the commit history of contrib/subtree/git-subtree.sh
>>> > and determined that the last successful subtree push was performed
>>> > prior to the integration of this change:
>>> >
>>> > https://git.kernel.org/cgit/git/git.git/commit/contrib/subtree/git-subtree.sh?id=933cfeb90b5d03b4096db6d60494a6eedea25d03
>>> >
>>> > As a next step, I reversed that patch on my local install of git
>>> > subtree, and the result was a successful subtree push.
>>>
>>> So you're saying that this patch caused a regression?
>>>
>>> > Unfortunately, I have not yet reproduced this with a test main project
>>> > and subprojects, and I cannot make the project I observed it in
>>> > public.
>>>
>>> I very much want to see a testcase for this.  I'm planning to
>>> fundamentally rewrite the split code this year and want to make sure it
>>> covers everything it does now and fixes a few bugs that have been
>>> exposed lately.
>>>
>>> It's tough to revert that patch since it fixed a problem for someone and
>>> we don't have a testcase demonstrating the problem you encountered.  Not
>>> saying your problem isn't important but we need to understand it and
>>> have a way to flag it before fixing or hiding it with a revert of the
>>> above patch.
>>>
>>>                        -David
>>
>> --
>> - Harpreet "Eli" Sangha

Reply via email to