Re: newbie questions about git design and features (some wrt hg)

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Feb 2, 2007, 16:42 UTC
Message-ID: <Pine.LNX.4.64.0702020835550.15057@woody.linux-foundation.org>
In-Reply-To: <epvnln$fmn$1@sea.gmane.org>

On Fri, 2 Feb 2007, Jakub Narebski wrote:

> 
> Gaaah. Why anyone would want to have non-propagated tags?

That's *definitely* not the mistake.

I use private tags (and branches, for that matter) all the time. I'd be very upset indeed if all my tags were always pushed out when I push something out.

The mistake seems to be to think that tags get "versioned", and are part of the tree history. That's insane. It means that you can never have a tag to a newer tree than the one you are on.

Tags are *independent* of history. They must be. They are "outside" history, since the whole point of tags are to point to history.

The same is obviously true of branches. The fact that my "master" branch is at some point in time should *not* version my "other" branch. So branches - like tags - must not be "inside" the history.

Show 9 quoted lines

> > If I may be opinionated for a bit: this is barking for two reasons:
> > 
> >   * The tags files grow by having lines added to the bottom.  Files of
> >     this kind are almost ideal for causing merge conflicts, and there's
> >     no automatic means for resolving them.  (I actually wrote a custom
> >     tags merger recently -- if anyone wants it, just mail me.)
> 
> Such a merger (merge strategy) would be also useful for other log-like
> files, e.g. ChangeLogs and such.

Yeah. I think per-file merge strategies are fine. We may not do them in git (nothing fundamental, it just hasn't come upas a real issue, although I think somebody was talking about how he ended up just using a special "merge" program that looked at the filename), but there is definitely nothing wrong with the concept.

And it solves that particular problem for tag-files, but it doesn't change the fact that keeping tags inside of history is insane in the first place (so it's not a problem that *should* be solved!)

			Linus