Re: Unexpected behavior of git-subtree

2013-04-30 Thread Steffen Jaeckel
On Monday, April 29, 2013, 20:20, John Keeping,  wrote:
> On Mon, Apr 29, 2013 at 07:34:27PM +0200, Steffen Jaeckel wrote:
>>
>>  snip 
>> sjaeckel@T7400-003 /h/projects/my_project (develop)
>> $ GIT_TRACE=2 git subtree push --prefix=lib/com_lib/ git@git.local:com_lib 
>> develop -b develop

> Without knowing much about git-subtree, this looks like the culprit.  A
> quick look at cmd_push in git-subtree.sh indicates that it doesn't check
> for an error return from 'git subtree split --prefix=$prefix', so if
> that goes wrong you end up doing:

> git push $repository :refs/heads/$refspec

> which deletes the branch.

> Can you try running this:

> git subtree split --prefix=lib/com_lib/

> and see if that gives the same "fatal: bad object" message as above?

John, thanks for testing!
I just found out that it's all about the slashes

The solution was:
> git subtree push --prefix=lib/com_lib git@git.local:com_lib develop
look at the missing '/' at the end of the prefix.


Steffen
-- 
Steffen Jaeckel

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Unexpected behavior of git-subtree

2013-04-29 Thread John Keeping
On Mon, Apr 29, 2013 at 07:34:27PM +0200, Steffen Jaeckel wrote:
> lately I used git-subtree to integrate a submodule directly into a
> repository. Now I wanted to push the changes back to the original
> repository of the submodule and I was a bit surprised by what
> happened...
> 
> 
>  snip 
> sjaeckel@T7400-003 /h/projects/my_project (develop)
> $ GIT_TRACE=2 git subtree push --prefix=lib/com_lib/ git@git.local:com_lib 
> develop -b develop
> trace: exec: 'git-subtree' 'push' '--prefix=lib/com_lib/' 
> 'git@git.local:com_lib' 'develop' '-b' 'develop'
> trace: run_command: 'git-subtree' 'push' '--prefix=lib/com_lib/' 
> 'git@git.local:com_lib' 'develop' '-b' 'develop'
> trace: built-in: git 'rev-parse' '--parseopt' '--' 'push' 
> '--prefix=lib/com_lib/' 'git@git.local:com_lib' 'develop' '-b' 'develop'
> trace: built-in: git 'rev-parse' '--git-dir'
> trace: built-in: git 'rev-parse' '--show-cdup'
> git push using:  git@git.local:com_lib develop
> trace: exec: 'git-subtree' 'split' '--prefix=lib/com_lib/'
> trace: run_command: 'git-subtree' 'split' '--prefix=lib/com_lib/'
> trace: built-in: git 'rev-parse' '--parseopt' '--' 'split' 
> '--prefix=lib/com_lib/'
> trace: built-in: git 'rev-parse' '--git-dir'
> trace: built-in: git 'rev-parse' '--show-cdup'
> trace: built-in: git 'rev-parse' '--default' 'HEAD' '--revs-only'
> trace: built-in: git 'rev-parse' '--no-revs' '--no-flags'
> trace: built-in: git 'log' '--grep=^git-subtree-dir: lib/com_lib/*$' 
> '--pretty=format:START %H%n%s%n%n%b%nEND%n' 
> '8068a810709f6284b04a18ff38dbb72c36b8d9c6'
> trace: built-in: git 'rev-list' '--topo-order' '--reverse' '--parents' 
> '8068a810709f6284b04a18ff38dbb72c36b8d9c6'
> trace: built-in: git 'rev-list' '--topo-order' '--reverse' '--parents' 
> '8068a810709f6284b04a18ff38dbb72c36b8d9c6'
> 1/102 (0)trace: built-in: git 'ls-tree' 
> 'f6e1457d345029cf4d376ff3cf780cbb8c3080b4' '--' 'lib/com_lib'
> . loads of more git 'ls-tree'...
> 71/102 (70)72/102 (70)trace: built-in: git 'ls-tree' 
> '48dc0efb9a148b1146b013554f8bf4635adf7a0d' '--' 'lib/com_lib'
> trace: built-in: git 'log' '-1' '--pretty=format:%T' 
> '6299b48765e11302aca48cc9fca88735aeab7c54' '--'
> fatal: bad object 6299b48765e11302aca48cc9fca88735aeab7c54

Without knowing much about git-subtree, this looks like the culprit.  A
quick look at cmd_push in git-subtree.sh indicates that it doesn't check
for an error return from 'git subtree split --prefix=$prefix', so if
that goes wrong you end up doing:

git push $repository :refs/heads/$refspec

which deletes the branch.

Can you try running this:

git subtree split --prefix=lib/com_lib/

and see if that gives the same "fatal: bad object" message as above?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html