| 1 |
On 11 Aug 2015 15:23, Kent Fredric wrote: |
| 2 |
> On 11 August 2015 at 15:06, Mike Frysinger wrote: |
| 3 |
> > it would have to re-use the same tag name every time otherwise we end up with |
| 4 |
> > 17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea |
| 5 |
> |
| 6 |
> I was very much under the impression git is not designed with repeated |
| 7 |
> tag replication in consideration. |
| 8 |
|
| 9 |
git has no problem fetching rewritten tags. internally, it doesn't care |
| 10 |
either -- a tag is merely a reference to an object. |
| 11 |
|
| 12 |
> The git tag documentation very much implies that any tag having its |
| 13 |
> reference changed will result in effort being required of everyone who |
| 14 |
> wishes to consume that tag. ( It literally brands the act of |
| 15 |
> re-tagging things to be "insane" ) |
| 16 |
> |
| 17 |
> Tags are very much intended to be immutable references to commits. |
| 18 |
|
| 19 |
the git docs take the stance that publishing any mutable names is wrong. |
| 20 |
same goes for rebasing and publishing rewritten history. that's simply |
| 21 |
the recommended practice. it doesn't mean that the world blows up when |
| 22 |
you do rewrite things. |
| 23 |
|
| 24 |
> If you need mutable references to commits, isn't that what branches are for? |
| 25 |
|
| 26 |
no, that's not what they're for. |
| 27 |
-mike |
Archives