How to add daily tags for a central repo?

How to add daily tags for a central repo?

[roylee17]

Hi,

We currently host our projects on a central server.
For the daily build purpose, I currently using a script to do the following
steps:

  1. clone the project from the central server

  2. find the target commit for a specified date
      commit=`git log origin/master -n1 --format=%H --until="${timespec}
00:00:00"`

  3. tag the commit
      git tag -f daily/${timespec} ${commit}

  4. push the tag up to the central server

This usually works fine and allows us to tag earlier commit with past dates

However, it depends on the "COMMIT DATE", which is a local time to the
developer who
committed the changes.
And if some developer didn't have the time or date configured correctly on
his machine,
the changes committed by him may not be included in a tag, even it is pushed
to the 
on a date earlier than the target date to tag.

Alternatively, we can queue the job to do the following steps "on a target
date":

1. clone the project from the central server
2. tag the "latest commit"
3. push the tag to the server

But I'd like to know better ways to do the daily tag things?

Roy
-- 
View this message in context: http://git.661346.n2.nabble.com/How-to-add-daily-tags-for-a-central-repo-tp5124575p5124575.html
Sent from the git mailing list archive at Nabble.com.

Re: How to add daily tags for a central repo?

[Michael J Gruber]

roylee17 venit, vidit, dixit 01.06.2010 07:21:
> 
> Hi,
> 
> We currently host our projects on a central server.
> For the daily build purpose, I currently using a script to do the following
> steps:
> 
>   1. clone the project from the central server
> 
>   2. find the target commit for a specified date
>       commit=`git log origin/master -n1 --format=%H --until="${timespec}
> 00:00:00"`
> 
>   3. tag the commit
>       git tag -f daily/${timespec} ${commit}
> 
>   4. push the tag up to the central server
> 
> This usually works fine and allows us to tag earlier commit with past dates
> 
> However, it depends on the "COMMIT DATE", which is a local time to the
> developer who
> committed the changes.
> And if some developer didn't have the time or date configured correctly on
> his machine,
> the changes committed by him may not be included in a tag, even it is pushed
> to the 
> on a date earlier than the target date to tag.
> 
> Alternatively, we can queue the job to do the following steps "on a target
> date":
> 
> 1. clone the project from the central server
> 2. tag the "latest commit"
> 3. push the tag to the server
> 
> But I'd like to know better ways to do the daily tag things?

Having these tags seems strange to me. Imagine someone pushing a patch
series one-by-one around midnight, or pushing a commit and, shortly
after, a fixup. You'll end up with a tag pointing to a commit in the middle.

The commit time is totally unreliable, as you noticed, also because
authors may commit locally, then push later.

That being said, if you're really interested in the state of a branch on
the central server at a certain point in time it's easiest to enable
reflogs on the central repository (by setting core.logAllRefUpdates or
enabling individually) and to tag the commit HEAD@{datetimespec} (or
branchname@...). No need for cloning.

Cheers,
Michael

Re: How to add daily tags for a central repo?

[Roy Lee]

Hi Michael,

>
> Having these tags seems strange to me. Imagine someone pushing a patch
> series one-by-one around midnight, or pushing a commit and, shortly
> after, a fixup. You'll end up with a tag pointing to a commit in the middle.
>
> The commit time is totally unreliable, as you noticed, also because
> authors may commit locally, then push later.
>
> That being said, if you're really interested in the state of a branch on
> the central server at a certain point in time it's easiest to enable
> reflogs on the central repository (by setting core.logAllRefUpdates or
> enabling individually) and to tag the commit HEAD@{datetimespec} (or
> branchname@...). No need for cloning.
>
> Cheers,
> Michael
>

This is what I'm looking for. Thanks a lot.

But I have another question:
How to use the refspec to refer to the reflogs?
Or any alternatives for developer to query this information.

Regards,
Roy

Re: How to add daily tags for a central repo?

[Michael J Gruber]

Roy Lee venit, vidit, dixit 01.06.2010 09:55:
> Hi Michael,
> 
>>
>> Having these tags seems strange to me. Imagine someone pushing a patch
>> series one-by-one around midnight, or pushing a commit and, shortly
>> after, a fixup. You'll end up with a tag pointing to a commit in the middle.
>>
>> The commit time is totally unreliable, as you noticed, also because
>> authors may commit locally, then push later.
>>
>> That being said, if you're really interested in the state of a branch on
>> the central server at a certain point in time it's easiest to enable
>> reflogs on the central repository (by setting core.logAllRefUpdates or
>> enabling individually) and to tag the commit HEAD@{datetimespec} (or
>> branchname@...). No need for cloning.
>>
>> Cheers,
>> Michael
>>
> 
> This is what I'm looking for. Thanks a lot.
> 
> But I have another question:
> How to use the refspec to refer to the reflogs?

Well, as I wrote: HEAD@{datetimespec} for the HEAD,
branchname@{datetimespec} for a branch "branchname". datetimespec is
decribed in git rev-parse's manpage but can be what you'd think (e.g.
"date time") and more ("yesterday").
If you really want to inspect the reflog (not the commits listed in the
reflog) use "git log -g" or, unsurprisingly, "git reflog".

> Or any alternatives for developer to query this information.

The reflog is local to the repo, which is why you would create tags on
the central repo based on the reflog there, if that is your "trusted
time and push reference source".

Cheers,
michael

Re: How to add daily tags for a central repo?

[Roy Lee]

On Tue, Jun 1, 2010 at 4:05 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Roy Lee venit, vidit, dixit 01.06.2010 09:55:
>> Hi Michael,
>>
> Well, as I wrote: HEAD@{datetimespec} for the HEAD,
> branchname@{datetimespec} for a branch "branchname". datetimespec is
> decribed in git rev-parse's manpage but can be what you'd think (e.g.
> "date time") and more ("yesterday").
> If you really want to inspect the reflog (not the commits listed in the
> reflog) use "git log -g" or, unsurprisingly, "git reflog".
>
>> Or any alternatives for developer to query this information.
>
> The reflog is local to the repo, which is why you would create tags on
> the central repo based on the reflog there, if that is your "trusted
> time and push reference source".

Does this mean the tagging must be done on the server?
Is there any way to query this information from a client repo,
do the tagging locally, and than push the tag back to the server?

Regards,
Roy

Re: How to add daily tags for a central repo?

[Michael J Gruber]

Roy Lee venit, vidit, dixit 01.06.2010 10:25:
> On Tue, Jun 1, 2010 at 4:05 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Roy Lee venit, vidit, dixit 01.06.2010 09:55:
>>> Hi Michael,
>>>
>> Well, as I wrote: HEAD@{datetimespec} for the HEAD,
>> branchname@{datetimespec} for a branch "branchname". datetimespec is
>> decribed in git rev-parse's manpage but can be what you'd think (e.g.
>> "date time") and more ("yesterday").
>> If you really want to inspect the reflog (not the commits listed in the
>> reflog) use "git log -g" or, unsurprisingly, "git reflog".
>>
>>> Or any alternatives for developer to query this information.
>>
>> The reflog is local to the repo, which is why you would create tags on
>> the central repo based on the reflog there, if that is your "trusted
>> time and push reference source".
> 
> Does this mean the tagging must be done on the server?

Yes.

> Is there any way to query this information from a client repo,
> do the tagging locally, and than push the tag back to the server?

No.

This answer assumes that what you want to do is the following:

* Create a tag for the state of a ref (such as HEAD) on the central repo
at a specific date and time.

No client can know this. Reflogs are local. The point of your tagging
(as I understand it) is to create an authoritative date based tag, and
only the central repo has the necessary info.

If you want to do something different you should say so ;) But note that
committer and author dates are completely bogus from the point of view
of "was in the central repo at a certain date", they have nothing to do
with that.

Michael

Re: How to add daily tags for a central repo?

[Roy Lee]

On Tue, Jun 1, 2010 at 4:52 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Roy Lee venit, vidit, dixit 01.06.2010 10:25:
>> On Tue, Jun 1, 2010 at 4:05 PM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Roy Lee venit, vidit, dixit 01.06.2010 09:55:
>>>> Hi Michael,
>>>>
>>> Well, as I wrote: HEAD@{datetimespec} for the HEAD,
>>> branchname@{datetimespec} for a branch "branchname". datetimespec is
>>> decribed in git rev-parse's manpage but can be what you'd think (e.g.
>>> "date time") and more ("yesterday").
>>> If you really want to inspect the reflog (not the commits listed in the
>>> reflog) use "git log -g" or, unsurprisingly, "git reflog".
>>>
>>>> Or any alternatives for developer to query this information.
>>>
>>> The reflog is local to the repo, which is why you would create tags on
>>> the central repo based on the reflog there, if that is your "trusted
>>> time and push reference source".
>>
>> Does this mean the tagging must be done on the server?
>
> Yes.
>
>> Is there any way to query this information from a client repo,
>> do the tagging locally, and than push the tag back to the server?
>
> No.
>
> This answer assumes that what you want to do is the following:
>
> * Create a tag for the state of a ref (such as HEAD) on the central repo
> at a specific date and time.

Yes, for the daily build stuff.

> No client can know this. Reflogs are local. The point of your tagging
> (as I understand it) is to create an authoritative date based tag, and
> only the central repo has the necessary info.
>
> If you want to do something different you should say so ;) But note that
> committer and author dates are completely bogus from the point of view
> of "was in the central repo at a certain date", they have nothing to do
> with that.
>
> Michael

I've been using reflog locally for some time, but never thought that
it could be used in this way -- combining with timespec to get the
timestamps of updates to the server. :)

The only problem now is that the tag creator might not have the access
to shell on the central server. To grant the shell access for the tag creator
may be a quick way to circumvent this. But I think I'll try if git can export
the reflog to the client in a native way or with some trickery.

Thank you so much, Michael.

Regards,
Roy

Re: How to add daily tags for a central repo?

[Ilari Liusvaara]

On Tue, Jun 01, 2010 at 05:45:16PM +0800, Roy Lee wrote:
> 
> I've been using reflog locally for some time, but never thought that
> it could be used in this way -- combining with timespec to get the
> timestamps of updates to the server. :)
> 
> The only problem now is that the tag creator might not have the access
> to shell on the central server. To grant the shell access for the tag creator
> may be a quick way to circumvent this. But I think I'll try if git can export
> the reflog to the client in a native way or with some trickery.
 
Have an automated script that creates the tags and runs from cron or somesuch
(or from post-update hook)?

If you don't want to use tags, you can use refs in other namespaces (but these
would still be sent as refs to client, increasing bandwidth usage a bit).

-Ilari

Re: How to add daily tags for a central repo?

[Junio C Hamano]

Roy Lee <roylee17@gmail.com> writes:

>> * Create a tag for the state of a ref (such as HEAD) on the central repo
>> at a specific date and time.
>
> Yes, for the daily build stuff.

If this is really "the daily build", the easiest is to

 - arrange the "daily build" environment to be kept up-to-date (either
   developers will be pushing into it, or there is another canonical
   central repository developer pushes into, and the daily build
   repository pulls from that canonical central repository via cron just
   before starting to build);

 - tag the version that is being built; and

 - do the "daily build".

Even if the automated "daily build" runs an hour after midnight, I
wouldn't imagine that you would want to grab the version that was the
latest as of midnight, building that slightly stale one, excluding the
development that happened within an our since that version.

Re: How to add daily tags for a central repo?

[Roy Lee]

Hi,

On Wed, Jun 2, 2010 at 12:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Roy Lee <roylee17@gmail.com> writes:
>
>>> * Create a tag for the state of a ref (such as HEAD) on the central repo
>>> at a specific date and time.
>>
>> Yes, for the daily build stuff.
>
> If this is really "the daily build", the easiest is to
>
>  - arrange the "daily build" environment to be kept up-to-date (either
>   developers will be pushing into it, or there is another canonical
>   central repository developer pushes into, and the daily build
>   repository pulls from that canonical central repository via cron just
>   before starting to build);
>
>  - tag the version that is being built; and
>
>  - do the "daily build".
>
> Even if the automated "daily build" runs an hour after midnight, I
> wouldn't imagine that you would want to grab the version that was the
> latest as of midnight, building that slightly stale one, excluding the
> development that happened within an our since that version.

The daily build process for our company is still under development.

I'll feel more comfortable if the timing of tagging can be decoupled with
the target revision date. In case one day the mechanism is asked to tag
more branches on during different time interval or even backtrack to
snapshots earlier than now.

So far, the reflog mechanism seems to be able to fulfill this requirement,
since it allows us to backtrack earlier updates and do the tagging.
I'm taking it as a starting point or as a building block unless more attractive
alternatives show up.

Regards,
Roy