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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html