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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Tue, 28 Feb 2006, Martin Langhoff wrote:
> 
> git-svn-HEAD "moves" so it's really a bad idea to have it as a tag.
> Nothing within core git prevents it from moving, but I think that
> porcelains will start breaking. Tags and heads are the same thing,
> except that heads are expected to change (specifically, to move
> forward), and tags are expected to stand still.

Well, I wouldn't say that tags are expected to stand still. Some kinds of 
tags are expected to move: a "this is the last tested version" tag would 
be expected to move with testing. 

That said, the movement is _different_ from a branch. A branch is expected 
to move _with_ development, while a tag is expected to either stay the 
same, or move _after_ development.

However, in many ways git really doesn't care much. The "refs/heads" 
directory is the only one that is really special, in that "git checkout" 
refuses to check out a moving branch in anything but that subdirectory. 
The "tags" subdirectory is slightly special to some helpers (like "git 
pull"), which have flags to pull everythying in that subdirectory. 

But other than those two pretty trivial issues, any ref under "refs/" 
should work perfectly fine. I would argue that a specialized tracking tool 
might well be better off without using either "refs/heads" _or_ 
"refs/tags", since those have accepted meaning outside of tracking.

Using a "refs/remotes" subdirectory makes tons of sense for something like 
this. Or something even more specific, like "refs/svn-tracking/". Git 
shouldn't care - all the tools _should_ work fine with any subdirectory 
structure.

		Linus
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]