threads / discuss / 45067

subtree merging fails

Subject: subtree merging fails

## tl;dr

4 messages between Feb 7, 2017 and Feb 8, 2017.

replies: 3people: 3as markdown or json

Stavros Liaskos· Feb 7, 2017, 08:16 UTC · lore

Following the instructions here: https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging will lead to an error.

In particular, if the subtree is merged and then updated, this command that is supposed to update the local subtree fails with a fatal: refusing to merge unrelated histories error.

$ git merge --squash -s subtree --no-commit rack_branch
A workaround could be using the --allow-unrelated-histories option

$ git merge --squash --allow-unrelated-histories -s subtree --no-commit rack_branch

But this completely destroys my project by pushing the subtree contents into a completely irrelevant directory in my project (no in the subtree).

Any ideas??
https://github.com/git/git-scm.com/issues/896#issuecomment-277587626
Samuel Lijin· Feb 7, 2017, 14:59 UTC · re: Stavros Liaskos · lore

Re: subtree merging fails

Have you tried using (without -s subtree) -X subtree=path/to/add/subtree/at?
From the man page:
          subtree[=<path>]
               This option is a more advanced form of subtree
strategy, where the strategy
               makes a guess on how two trees must be shifted to match
with each other when
               merging. Instead, the specified path is prefixed (or
stripped from the
               beginning) to make the shape of two trees to match.
On Tue, Feb 7, 2017 at 2:16 AM, Stavros Liaskos <st.liaskos@gmail.com> wrote:
Show 22 quoted lines
> Following the instructions here:
> https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging
> will lead to an error.
>
> In particular, if the subtree is merged and then updated, this command
> that is supposed to update the local subtree fails with a fatal:
> refusing to merge unrelated histories error.
>
> $ git merge --squash -s subtree --no-commit rack_branch
>
> A workaround could be using the --allow-unrelated-histories option
>
> $ git merge --squash --allow-unrelated-histories -s subtree
> --no-commit rack_branch
>
> But this completely destroys my project by pushing the subtree
> contents into a completely irrelevant directory in my project (no in
> the subtree).
>
> Any ideas??
>
> https://github.com/git/git-scm.com/issues/896#issuecomment-277587626
David Aguilar· Feb 7, 2017, 18:44 UTC · re: Samuel Lijin · lore

Re: subtree merging fails

On Tue, Feb 07, 2017 at 08:59:06AM -0600, Samuel Lijin wrote:
Show 12 quoted lines
> Have you tried using (without -s subtree) -X subtree=path/to/add/subtree/at?
> 
> From the man page:
> 
>           subtree[=<path>]
>                This option is a more advanced form of subtree
> strategy, where the strategy
>                makes a guess on how two trees must be shifted to match
> with each other when
>                merging. Instead, the specified path is prefixed (or
> stripped from the
>                beginning) to make the shape of two trees to match.

I'm not 100% certain, but it's highly likely that the subtree=<prefix> argument needs to include a trailing slash "/" in the prefix, otherwise files will be named e.g. "fooREADME" instead of "foo/README" when prefix=foo.

These days I would steer users towards the "git-subtree" command in contrib/ so that users don't need to deal with these details. It handles all of this stuff for you.

https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt
https://github.com/git/git/tree/master/contrib/subtree

Updating the progit book to also mention git-subtree, in addition to the low-level methods, would probably be a good user-centric change.

-- 
David
Stavros Liaskos· Feb 8, 2017, 10:42 UTC · re: David Aguilar · lore

Re: subtree merging fails

@Samuel Lijin I tried now and I get: "merge: branch_name
- not something we can merge". Maybe that is something easy to fix but currently I am using a workaround script so I am not putting any more effort at this at the moment.

@David Aguilar That's true but the trailing slash is already there. This commands looks promising. An update would be GREAT!

FYI that's the script I am using to address this problem:
#!/bin/bash
function initial {
  if git remote | grep -q lisa_remote
  then
    echo "Subtree delete & update"
    git checkout lisa_branch
    git pull
    git checkout master
    git merge --squash -s subtree --no-commit lisa_branch
    git merge --squash --allow-unrelated-histories -s subtree
--no-commit lisa_branch
  else
    echo "Add subtree"
    git remote add lisa_remote git@xxxxxxxx:lisa/lisa.git
    git fetch lisa_remote
    git checkout -b lisa_branch lisa_remote/master
    git checkout master
    git read-tree --prefix=lisaSubTree/ -u lisa_branch
    gitrm
    git rm --cached -r lisaSubTree/.gitignore
    git rm --cached -r lisaSubTree/*
  fi
}
initial
On Tue, Feb 7, 2017 at 7:44 PM, David Aguilar <davvid@gmail.com> wrote:
Show 31 quoted lines
> On Tue, Feb 07, 2017 at 08:59:06AM -0600, Samuel Lijin wrote:
>> Have you tried using (without -s subtree) -X subtree=path/to/add/subtree/at?
>>
>> From the man page:
>>
>>           subtree[=<path>]
>>                This option is a more advanced form of subtree
>> strategy, where the strategy
>>                makes a guess on how two trees must be shifted to match
>> with each other when
>>                merging. Instead, the specified path is prefixed (or
>> stripped from the
>>                beginning) to make the shape of two trees to match.
>
> I'm not 100% certain, but it's highly likely that the subtree=<prefix>
> argument needs to include a trailing slash "/" in the prefix,
> otherwise files will be named e.g. "fooREADME" instead of
> "foo/README" when prefix=foo.
>
> These days I would steer users towards the "git-subtree" command in
> contrib/ so that users don't need to deal with these details.  It
> handles all of this stuff for you.
>
> https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt
>
> https://github.com/git/git/tree/master/contrib/subtree
>
> Updating the progit book to also mention git-subtree, in addition to the
> low-level methods, would probably be a good user-centric change.
> --
> David

← back to recent threads