Eclipse Community Forums: EGit / JGit » workaround for the broken aspect of refs/remotes

Help

Home

Home » Eclipse Projects » EGit / JGit » workaround for the broken aspect of refs/remotes

Show: Today's Messages :: Show Polls :: Message Navigator

workaround for the broken aspect of refs/remotes [message #756940]

Tue, 15 November 2011 15:53

R Shapiro

Messages: 386
Registered: June 2011

Senior Member

Currently egit synchronization has a bug in its handling of references in refs/remotes: the plugin assumes these are remote-reference form, which Git does not require. Any files in this directory which are not in remote-reference form will fail when selected for use as the destination in advanced synchronization. One way you can get such files is via svn-bridging, but this is just an example, bridging is not the source of the problem.

Fortunately there's a simple workaround, at least in the unix world: symbolic links. Just make a symlink from the entry in refs/remotes to the the top-level of refs. The link can then be used in advanced synchronization.

For example suppose you have a bridge reference in .git/refs/remotes/trunk. You can't use this directly in advanced synchronization even though it's listed in the menu. Instead do this:

cd .git
ln -s remotes/trunk svn_trunk (or whatever name you want to use)

Now you can do advanced synchronization with refs/svn-trunk as the destination and everything works fine.

Note that it has to be a link, not a copy, otherwise the new reference will never be updated.

Probably there's a Windows equivalent but I don't know what it is.

Report message to a moderator

Re: workaround for the broken aspect of refs/remotes [message #757626 is a reply to message #756940]

Sun, 20 November 2011 15:24

R Shapiro

Messages: 386
Registered: June 2011

Senior Member

Poking around a little, I realized that I should have been using Git symbolic-refs instead of symlinks, since the former are platform neutral and the latter are not.

git symbolic-ref svn_trunk refs/remotes/trunk

Unfortunately this doesn't work, due to a second bug: egit doesn't seem to know anything about user-created symbolic-refs. But there's a workaround for this workaround -- after creating the symbolic-ref, move it somewhere under .git/refs (the Git command will create it directly under .git).

I want to emphasize again that none of this has anything specifically to do with svn bridging, which is nothing more than an example case. Both problems are general egit issues and both have been filed as bugs.

Report message to a moderator

Re: workaround for the broken aspect of refs/remotes [message #758117 is a reply to message #757626]

Mon, 21 November 2011 22:24

Robin Rosenberg

Messages: 332
Registered: July 2009

Senior Member

R Shapiro skrev 2011-11-20 16.24:
> Poking around a little, I realized that I should have been using Git symbolic-refs instead of symlinks, since the former are platform neutral and the latter are not.
>
> git symbolic-ref svn_trunk refs/remotes/trunk
>
> Unfortunately this doesn't work, due to a second bug: egit doesn't seem to know anything about user-created symbolic-refs. But there's a workaround for this workaround --
> after creating the symbolic-ref, move it somewhere under .git/refs (the Git command will create it directly under .git).

git symblic-ref is a low-level (plumbing) stupid command that does what you tell it to. Place the
symbolic refs in the refs name space directly and no workaround is needed.

git symbolic-ref refs/svn_trunk refs/remotes/trunk

EGit and to my knowledge all other UI's (including command line) doesn't list symbolic refs outside
the refs name space.

> I want to emphasize again that none of this has anything specifically to do with svn bridging, which is nothing more than an example case. Both problems are general egit
> issues and both have been filed as bugs.
>

-- robin

Report message to a moderator

Re: workaround for the broken aspect of refs/remotes [message #759009 is a reply to message #758117]

Fri, 25 November 2011 15:01

R Shapiro

Messages: 386
Registered: June 2011

Senior Member

Thank you for pointing out the the first parameter to git symbolic-ref can be an arbitrary path. As I mentioned, I only just found this command and that feature wasn't obvious from the help page.

Are symbolic references a 'stupid' concept? <shrug>. Stupid or not, at least this provides a workaround for the Advanced Synchronization refs/remotes bug. Otherwise my team wouldn't be able to make any effective use of Advanced Synchronization at all. This way they can.

Report message to a moderator

Previous Topic:	Switching branches leaves folders that should be gone!
Next Topic:	Diff between a current state of a file and the commited version

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Apr 24 22:54:54 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter