* Unexpected behavior of git-subtree
@ 2013-04-29 17:34 Steffen Jaeckel
2013-04-29 18:20 ` John Keeping
0 siblings, 1 reply; 3+ messages in thread
From: Steffen Jaeckel @ 2013-04-29 17:34 UTC (permalink / raw)
To: git
Hi,
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
trace: built-in: git 'push' 'git@git.local:com_lib' ':refs/heads/develop'
trace: run_command: 'ssh' 'git@git.local' 'git-receive-pack '\''com_lib'\'''
Repository name is: com_lib.git
Repository_Clean name is: com_lib
Branch name is: com_lib/develop
To git@git.local:com_lib
- [deleted] develop
sjaeckel@T7400-003 /h/projects/my_project (develop)
$ git version
git version 1.8.1.msysgit.1
---- /snip ----
I don't know if that's a bug or I used git-subtree's options incorrect,
but what I read from its "manpage" 'git-subtree.txt', I would expect
that this command should split out the commits of the prefix and push
that to the remote of the former submodule.
Even if it's my fault, because I used it incorrect, I think it should
not delete the remote branch.
Besides "git subtree push --prefix=lib/com_lib/ git@git.local:com_lib
develop -b develop" I also tried "git subtree push
--prefix=lib/com_lib/ git@git.local:com_lib develop" with the same
effect.
Can someone tell me if that's a bug, and/or what I did wrong?
Thanks
Steffen
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Unexpected behavior of git-subtree
2013-04-29 17:34 Unexpected behavior of git-subtree Steffen Jaeckel
@ 2013-04-29 18:20 ` John Keeping
2013-04-30 11:13 ` Steffen Jaeckel
0 siblings, 1 reply; 3+ messages in thread
From: John Keeping @ 2013-04-29 18:20 UTC (permalink / raw)
To: Steffen Jaeckel; +Cc: git
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?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Unexpected behavior of git-subtree
2013-04-29 18:20 ` John Keeping
@ 2013-04-30 11:13 ` Steffen Jaeckel
0 siblings, 0 replies; 3+ messages in thread
From: Steffen Jaeckel @ 2013-04-30 11:13 UTC (permalink / raw)
To: John Keeping; +Cc: git
On Monday, April 29, 2013, 20:20, John Keeping, <john@keeping.me.uk> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-04-30 11:14 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-29 17:34 Unexpected behavior of git-subtree Steffen Jaeckel
2013-04-29 18:20 ` John Keeping
2013-04-30 11:13 ` Steffen Jaeckel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).