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@: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 Aguilarwrote: > 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[=] >>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= > 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
Re: subtree merging fails
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[=] >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= 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
Re: subtree merging fails
Have you tried using (without -s subtree) -X subtree=path/to/add/subtree/at? >From the man page: subtree[=] 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 Liaskoswrote: > 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
subtree merging fails
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
Re: subtree merging fails
Hi Stavros, On Mon, 6 Feb 2017, Stavros Liaskos wrote: > Please check this issue for a description of the bug: > https://github.com/git/git-scm.com/issues/896#issuecomment-277587626 Just an observation from my side: if I see a request for help on this mailing list where the sender merely pastes a link and does not bother to condense and summarize the information in the linked page, to help potential helpers, I am highly unlikely to even click on that link, let alone to try to help. Maybe you would want to spend as much effort on a request for help as you would like to ask people to spend on a reply? Ciao, Johannes
subtree merging fails
Hi, Please check this issue for a description of the bug: https://github.com/git/git-scm.com/issues/896#issuecomment-277587626 Regards, Stavros