Re: git-svn and huge data and modifying the git-svn-HEAD branch directly

Hi,

On Wed, 1 Mar 2006, Linus Torvalds wrote:

On Wed, 1 Mar 2006, Andreas Ericsson wrote:

quoted

Personally I'm all for namespace separation. I'm assuming the script 
has the tracker-branch hardcoded anyway, so I don't really understand 
why it would be necessary to keep other refs in a separate directory 
and, if it *is* necessary, why that subdirectory can't be 
.git/refs/heads/svn.

Eric mentioned earlier that the tracking-branch can't be committed to 
(ever), so the user convenience for searching other directories should 
be nearly non-existant.

The thing about it being .git/refs/heads/svn/xyzzy is that then you can 
do

	git checkout svn/xyzzy

_not_ a branch and you must _not_ commit to it.

It's much more like a tag: it's a pointer to the last point of an 
svn-import.

So I think it should either _be_ a tag (although Dscho worries about some 
broken porcelain being confused by tags changing) or it should be in a 
namespace all it's own. Not under .git/refs/heads/ at any point, because 
it is _not_ a head of development.

I almost missed that you reference me in the email (often, I just delete 
the email if the Subject is of no interest to me).

I did not worry about broken porcelain. I saw broken porcelain. But that 
is more a broken concept than broken porcelain: in a distributed 
environment, there is no way to have a reliable tag. Think about it: 
whenever you have two different versions of a tag, you cannot know which 
one is the correct one.

But my worries do not matter at all for local tags.

Conceptually, however, the last point of a svnimport should *never* be a 
tag, but *always* a head.

Ciao,
Dscho