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]

 



Eric Wong wrote:
Linus Torvalds <torvalds@xxxxxxxx> wrote:


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.

<snipped>
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.


Git tools only work as long as the 'refs/{remotes,svn-tracking,...}/'
prefix is specified.  git-svn-HEAD (or any $GIT_SVN_ID-HEAD) does get
specified from the command-line quite often:
	
	git checkout -b mine git-svn-HEAD
	git-log git-svn-HEAD..head
	git-svn commit git-svn-HEAD..mine
	git-log mine..git-svn-HEAD

Should rev-parse be taught to be less strict and look for basenames
that can't be found in heads/ and tags/ in other directories?


It already does. The search order is this, for a ref named 'foo':
	$GIT_DIR/foo
	$GIT_DIR/refs/foo
	$GIT_DIR/refs/tags/foo
	$GIT_DIR/refs/heads/foo

--
Andreas Ericsson                   andreas.ericsson@xxxxxx
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
: 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]