threads / discuss / 42112

Subtree Split Includes Commits Outside Prefix Directory

Subject: Subtree Split Includes Commits Outside Prefix Directory

## tl;dr

4 messages between Apr 22, 2016 and Aug 30, 2016.

replies: 3people: 2as markdown or json

ELI· Apr 22, 2016, 18:38 UTC · lore

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

David A. Greene· May 21, 2016, 23:06 UTC · re: ELI · lore

Re: Subtree Split Includes Commits Outside Prefix Directory

ELI <eliptus@gmail.com> writes:

Show 7 quoted lines

> 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

ELI· Jun 24, 2016, 02:32 UTC · lore

Re: Subtree Split Includes Commits Outside Prefix Directory

Attempting to resend without HTML...

- Harpreet "Eli" Sangha

On Thu, Jun 23, 2016 at 7:18 PM, ELI <eliptus@gmail.com> wrote:

Show 84 quoted lines

> 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

ELI· Aug 30, 2016, 05:12 UTC · re: ELI · lore

Re: Subtree Split Includes Commits Outside Prefix Directory

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:

Show 90 quoted lines

> 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