Subtree Split Includes Commits Outside Prefix Directory

Subtree Split Includes Commits Outside Prefix Directory

[ELI]

I attempt a subtree push to a sub-project which I knew not to have had
any local modification since the last subtree push it had received,
but it failed.

To subproject
 ! [rejected]        5a9ad640651d3d54387afa5b7eaf89ed0b392a01 ->
master (non-fast-forward)
error: failed to push some refs to 'subproject'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and integrate the remote changes
hint: (e.g. 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.


The first step I took to understand the cause was to do a subtree
split and inspect the commit history of the resulting branch.  I found
that it contained commits that did not touch any files in the
subproject.  Doing a git show on these commits revealed that they were
not empty commits, but contained diff information for paths in the
main project, and in some cases, other subprojects that exist in the
main project.


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.


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.


- Harpreet "Eli" Sangha

Re: Subtree Split Includes Commits Outside Prefix Directory

[David A. Greene]

ELI <eliptus@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

Re: Subtree Split Includes Commits Outside Prefix Directory

[ELI]

Attempting to resend without HTML...

- Harpreet "Eli" Sangha


On Thu, Jun 23, 2016 at 7:18 PM, ELI <eliptus@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 <greened@obbligato.org>
> wrote:
>>
>> ELI <eliptus@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

Re: Subtree Split Includes Commits Outside Prefix Directory

[ELI]

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 <eliptus@gmail.com> wrote:
> Attempting to resend without HTML...
>
> - Harpreet "Eli" Sangha
>
>
> On Thu, Jun 23, 2016 at 7:18 PM, ELI <eliptus@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 <greened@obbligato.org>
>> wrote:
>>>
>>> ELI <eliptus@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