From: "Martin Langhoff" <martin.langhoff@gmail.com>
To: "Linus Torvalds" <torvalds@osdl.org>
Cc: "Eric Wong" <normalperson@yhbt.net>, git@vger.kernel.org
Subject: Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
Date: Tue, 28 Feb 2006 13:58:18 +1300 [thread overview]
Message-ID: <46a038f90602271658h35623e58o7237a1703e6f4abd@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0602271634410.22647@g5.osdl.org>
On 2/28/06, Linus Torvalds <torvalds@osdl.org> 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.
>
> 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
next prev parent reply other threads:[~2006-02-28 0:58 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-27 17:59 git-svn and huge data and modifying the git-svn-HEAD branch directly Nicolas Vilz 'niv'
2006-02-27 18:46 ` Eric Wong
2006-02-27 18:55 ` Jan Harkes
2006-02-27 19:24 ` Eric Wong
2006-02-28 0:25 ` Martin Langhoff
2006-02-28 0:41 ` Linus Torvalds
2006-02-28 0:58 ` Martin Langhoff [this message]
2006-03-01 6:51 ` Eric Wong
2006-03-01 9:40 ` Andreas Ericsson
2006-03-01 15:53 ` Linus Torvalds
2006-03-01 16:07 ` Andreas Ericsson
2006-03-01 16:24 ` Linus Torvalds
2006-03-01 17:14 ` Josef Weidendorfer
2006-03-01 17:28 ` Shawn Pearce
2006-03-01 17:40 ` Linus Torvalds
2006-03-01 18:06 ` Josef Weidendorfer
2006-03-01 18:25 ` Linus Torvalds
2006-03-01 20:26 ` Josef Weidendorfer
2006-03-01 21:28 ` Linus Torvalds
2006-03-01 19:11 ` Junio C Hamano
2006-03-01 20:54 ` Josef Weidendorfer
2006-03-01 21:40 ` Martin Langhoff
2006-03-01 23:23 ` Carl Worth
2006-03-01 23:43 ` Linus Torvalds
2006-03-01 21:07 ` Johannes Schindelin
2006-03-19 19:12 ` Petr Baudis
2006-03-19 19:35 ` Linus Torvalds
2006-03-19 19:43 ` Junio C Hamano
2006-02-27 19:04 ` [PATCH] contrib/git-svn: tell the user to not modify git-svn-HEAD directly Eric Wong
2006-02-27 19:34 ` git-svn and huge data and modifying the git-svn-HEAD branch directly Nicolas Vilz 'niv'
2006-02-27 20:27 ` Eric Wong
2006-02-27 20:47 ` Nicolas Vilz 'niv'
2006-02-27 20:55 ` [PATCH] contrib/git-svn: correct commit example in manpage Eric Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46a038f90602271658h35623e58o7237a1703e6f4abd@mail.gmail.com \
--to=martin.langhoff@gmail.com \
--cc=git@vger.kernel.org \
--cc=normalperson@yhbt.net \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).