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.
From: Michael J Gruber <hidden> Date: 2016-06-15 22:48:53
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
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
From: Michael J Gruber <hidden> Date: 2016-06-15 22:48:53
Roy Lee venit, vidit, dixit 01.06.2010 09:55:
Hi Michael,
quoted
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
On Tue, Jun 1, 2010 at 4:05 PM, Michael J Gruber
[off-list ref] wrote:
Roy Lee venit, vidit, dixit 01.06.2010 09:55:
quoted
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".
quoted
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
From: Michael J Gruber <hidden> Date: 2016-06-15 22:48:53
Roy Lee venit, vidit, dixit 01.06.2010 10:25:
On Tue, Jun 1, 2010 at 4:05 PM, Michael J Gruber
[off-list ref] wrote:
quoted
Roy Lee venit, vidit, dixit 01.06.2010 09:55:
quoted
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".
quoted
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
On Tue, Jun 1, 2010 at 4:52 PM, Michael J Gruber
[off-list ref] wrote:
Roy Lee venit, vidit, dixit 01.06.2010 10:25:
quoted
On Tue, Jun 1, 2010 at 4:05 PM, Michael J Gruber
[off-list ref] wrote:
quoted
Roy Lee venit, vidit, dixit 01.06.2010 09:55:
quoted
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".
quoted
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.
quoted
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
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
From: Junio C Hamano <hidden> Date: 2016-06-15 22:48:53
Roy Lee [off-list ref] writes:
quoted
* 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.
Hi,
On Wed, Jun 2, 2010 at 12:40 PM, Junio C Hamano [off-list ref] wrote:
Roy Lee [off-list ref] writes:
quoted
quoted
* 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