git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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