Thread (27 messages) flat view 27 messages, 10 authors, 2016-06-15

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

From: Martin Langhoff <hidden>
Date: 2016-06-15 22:42:20

On 2/28/06, Linus Torvalds [off-list ref] wrote:
On Tue, 28 Feb 2006, Martin Langhoff wrote:
quoted
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.
Alrighty... in my git projects where things like these matter, my
"latest tested" and "current in production" refs are actually in
refs/heads.
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.
Grumble. I'd say a head is expected to reliably move _forward_...
"with" development, yes, but definitely forward. In my book a tag
wouldn't move, but if I take your word for it, then a tag can perhaps
change arbitrarily?

I'm not sure how much support we have in porcelains for "tracking" a
tag if it starts changing. Right now I think we'd find all sorts of
problems, we'd need to think carefully what moving tags means for
porcelains.
Or something even more specific, like "refs/svn-tracking/". Git
shouldn't care - all the tools _should_ work fine with any subdirectory
structure.
I think the moving-forward (therefore is trackable) vs stays reliably
in place distinction *is* useful. "Moves randomly" may also be useful,
but it should get a different treatment, because it's not "trackable".

Not that git and porcelains can't deal with all this stuff. But if
there is a clear convention then porcelains can be smart and refuse to
commit to the wrong place... it'd be a bit of a UI enhancement
perhaps?


martin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help