I have a situation with building ebuilds that will be a pain to write in any way other than calling git. Is it possible to support a EGIT_DATE which equates to something similar to: git checkout `git rev-list -n 1 --before="2009-07-27 13:37" master` Where the date 2009-07-27 is passed in as a standard YYYYMMDD date-version string? Thanks and best regards, EBo --
Wouldn't --before fail at merge commits?
To be honest I am not sure. When I wrote this two years ago I think I was thinking of using a date==version string and querying git to supply the revision number/string so that I do not have to hard code it. At the moment I have to explicitly give it (eg: 193acaa201efde6b358c2db5d1ffef35e436914e) instead of being able to resolve that via a date. With something like the above I should be able to do version bumps to the ebuilds by simply changing the ebuild version number, and it is not exactly a "live" ebuild. I should also mention that the upstream folks cannot be depended on tagging things in any useful way, and this was the best workaround I could think of. So the question is if --before fail at merge commits. I am not sure. I do not know enough of the git internals to hazard a guess. That said we should be able to develop some unit tests and then test the current behaviour and open a discussion on what the expected and best behaviour would be.
Just to be clear: 1. None of the git checkouts are considered 100% safe and suitable for release ebuilds in Gentoo. If you want a good and secure copy, make a snapshot that'll given proper checksum in the Manifest (SHA512). 2. The second-best choice is direct commit id since it gives SHA1-quality guarantee of matching commit. However, git does not support fetching by commit id directly, so we need to fetch the whole branch (and you need to specify an appropriate branch), and shallow clones are not supported. 3. Explicit tag has the advantage that it can be fetched remotely. However, upstream can update a tag and then the result would change. We could add some mechanism to ensure a specific commit id on a tag though. 4. Now, date is completely insecure and certainly not something that should be used in ebuilds. It could be useful for debugging though. Remember that: a) there's no guarantee that commit dates are correct, b) merge commits involve two or more branches evolving independently, so we have multiple states corresponding to the same date. Which, long story short, means that at any point in time a particular date could start pointing to a completely different commit, due to a new merge commit or a regular commit with incorrectly set clock.
I thought that when you merge, that the trunk only had only a single timeline. I do see that each of the branches have their own, but that is why I specified 'master' in my example. Regardless, I see that this may be problematic. I mostly was using this for debugging purposes, and when the code stabilizes enough I bother to takign a snapshot (giving it some appropriate versioning). That has truely been a pain when motoring through 40 different revisions... Hmmmm... maybe this is not useful. Take anything you find that is beneficial to the community and go ahead and close this ticket when you are ready. Thanks!
I think passing --first-parent to rev-list solves the merge problem partially. At least as long as we follow the idea that first parent of merge is the 'old' state.
Created attachment 435460 [details, diff] Proposed patch
I've been able to come up with this. It seems to work quite well, though it doesn't complain about invalid dates.
And merged.
