On Tue, Dec 06, 2011 at 04:09:15AM -0800, Pedro wrote: > <quote author="Lionel Elie Mamane"> >> Joe downloads the new changes (git fetch) from time 192 to 196 >> Joe rebases (or merges) his changes with the new changes at time 198 >> Joe successfully pushes his changes to the central repository at time 201 > </quote>
> I didn't understand this part. If at time 198 it is included in his > personal repository wouldn't it make sense to use time 201 when the > changes are known to all developers? Prosaically, git does not keep track of time 201 (push time), so we cannot know what that time actually is. And since git does not keep track of it, it makes it harder to find a commit if one is given its push time, while one can (with a modicum of work) search a commit by commit time: It is shown in gitk and in "git log --format=fuller". And actually it does not make a difference in terms of ambiguity in practise, since no other changes recorded into another developer's local repository between times 198 (commit time) and 201 (push time) can be pushed successfully. I developer Jane has recorded another change at time 200 in her personal repository, she necessarily does not have Joe's change yet. When she tries to push her change at time 205, git will refuse, and Jane will have to fetch Joe's change (time 206), rebase her own change (time 207) and push it (time 208), so the commit time for her change will be 207. > Aren't the builds uploaded to the Tinderboxes supposed to be compiled > from the Central repositories only? Yes, they are. But if the system *also* works for a developer distributing his own build to a tester, that's a nice extra. > But I would still suggest using as epoch the TDF's Birth date > (midnight Sept 28th 2010) and to use days as unit with the point > separating days from the fraction part. It is easier to refer to a 3 > digit version as your email illustrates. Yes, but an added advantage of using standard Unix timestamp is that git can an also handle that format... As in: git --log --format=fuller --date=raw Given a commit's commit time, one can then search in the output of that for the exact timestamp. Also consider: git log --since 1323142582 --until 1323156305 which gets all commits with author date between 1323142582 and 1323156305. Yes, *author* date, not *commit* date, that's the snag right now, but if I get my way in the feature request I'm going to make to git, the next version of git will have a "--commit-since" and "--commit-until" for commit dates :) Your format needs manual conversion to do that. But it has other advantages, which you describe. So <shrug> I have no strong opinion on this point. -- Lionel _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
