Updated tags on repo are not updated when pull

Updated tags on repo are not updated when pull

[Sebastien Tardif]

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.

Re: Updated tags on repo are not updated when pull

[PJ Weisberg]

On Mon, Apr 2, 2012 at 12:16 PM, Sebastien Tardif
<sebastien_tardif@oxfordcorp.com> wrote:
> 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.

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.

RE: Updated tags on repo are not updated when pull

[Sebastien Tardif]

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

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.

Re: Updated tags on repo are not updated when pull

[Marc Branchaud]

On 12-04-03 08:00 AM, Sebastien Tardif wrote:
> Like almost everything else, if a local repo is not updated, many
> things like HEAD and branch may not point to the latest thing.

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.

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

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

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

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.

Re: Updated tags on repo are not updated when pull

[PJ Weisberg]

On Tue, Apr 3, 2012 at 5:00 AM, Sebastien Tardif
<sebastien_tardif@oxfordcorp.com> wrote:
> 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.

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

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

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.

Re: Updated tags on repo are not updated when pull

[Junio C Hamano]

PJ Weisberg <pj@irregularexpressions.net> writes:

> 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?

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.