Updated tags on repo are not updated when pull

Default pull behavior does bring new tag that are hitting the revisions involved in the pull, in other words all tags that would point to log entries that are pulled.

I have tag like: LATEST_UIT, LATEST_QA, LATEST_CONTINOUS_BUILD

But with this incoherent behavior of not having the already pulled tag been updated when doing a pull, my developers end-up with misleading information in their log since their tags point to old pointer.

Please fix.

On Mon, Apr 2, 2012 at 12:16 PM, Sebastien Tardif <sebastien_tardif@oxfordcorp.com> wrote:

There's a discussion in the git-tag man page about titled "On Re-tagging," the upshot of which is:

'Just admit you screwed up, and use a different name. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people both have "version X", but they actually have different "X"'s. So just call it "X.1" and be done with it.'

You could use branches instead of tags for your 'latest X' things. A branch is basically a tag that moves.

-PJ

Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced.

Like almost everything else, if a local repo is not updated, many things like HEAD and branch may not point to the latest thing.

I agree that using branch is somehow a workaround, but it's still wrong that the tag is not updated by default when doing pull. Even if I find a long documentation about this behavior, it will still be wrong.

Let just admit git is still new, this use case is not original at all, it just show some outstanding issue with Git.

I'm used to work with SCM that that is server base, each extra step a developer need to do create issues and productivity lost. They just needed to do commit/update, but end-up forgetting "add" when creating new file.

Now with git beside still forgetting 'add" they forget to push. And now they will forget to do a extra "pull --tag".

Designed for failure.
________________________________________
From: pjweisberg@gmail.com [pjweisberg@gmail.com] on behalf of PJ Weisberg [pj@irregularexpressions.net]
Sent: Monday, April 02, 2012 7:29 PM
To: Sebastien Tardif
Cc: git@vger.kernel.org
Subject: Re: Updated tags on repo are not updated when pull

On Mon, Apr 2, 2012 at 12:16 PM, Sebastien Tardif <sebastien_tardif@oxfordcorp.com> wrote:

There's a discussion in the git-tag man page about titled "On Re-tagging," the upshot of which is:

'Just admit you screwed up, and use a different name. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people both have "version X", but they actually have different "X"'s. So just call it "X.1" and be done with it.'

You could use branches instead of tags for your 'latest X' things. A branch is basically a tag that moves.

-PJ

Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced.

On 12-04-03 08:00 AM, Sebastien Tardif wrote:

You need to wrap your head around the concept that git keeps your local repository's branches separate from any remote repositories'. Even if my local repository has a branch "foo" and the remote also has a branch "foo", git stores these in separate namespaces.

Well, that's debatable and depends on how you're using git. Other people's processes *want* the tags to remain unchanged.

And indeed has been discussed at length. The latest proposal was about letting tags have local and remote namespaces and to have "git fetch" automatically move remote tags, just like remote branches:

http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=166118

		M.

On Tue, Apr 3, 2012 at 5:00 AM, Sebastien Tardif <sebastien_tardif@oxfordcorp.com> wrote:

The documentation is at least an indication that it was a reasoned decision on the part of the Git developers, so changing it would take more of a discussion than "Please fix."

Indeed, I see what you're trying to do with those tags, and I like it.
 There just needs to be a way to implement it while addressing the
concern about tags changing out from under people.  A branch is
*almost* what you want.  Basically it's a branch that no one updates
except the build server under specific circumstances.  You could
enforce that with hooks, but I think the biggest problem is the word
"branch".  People (and UIs) have ideas of what a branch is and what
it's used for, which don't *quite* match the intended use.

I wonder if the Git developers have any ideas on the best way to maintain a pointer to the latest successful automated build, and other such things?

-PJ

Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced.

PJ Weisberg <pj@irregularexpressions.net> writes:

Such things, if they are not branches nor tags, can be placed under different naming hierarchy, e.g. refs/built, without interfering the normal semantics of "branches" (people expect to be able to check them out, build on them and push them back to advance their tips) or "tags" (people expect them to anchored at known points without floating). Any semantics the project wants to assign to them by social convention, and Git does not care. If the project participants are expected to always fetch them to keep them up to date in their local namespace, the project can tell them to place an extra entry for remote.origin.fetch in their repository config

	[remote "origin"]
        	fetch = +refs/built/*:refs/built/*

in the same document they tell them where and how to clone the project history from.

I would however use the usual branch perhaps with a well-known prefix if I were doing this. You would want to forbid updates of them from random people at the central site with a pre-receive hook anyway; using a different hierarchy only to avoid the word "branch" is not worth the extra complexity.