On Wed, 2009-03-04 at 14:14 +0100, Frederic Peters wrote: > Owen Taylor wrote: > > > Commit mails now match what I described, but actually, the part that I > > would suggest you use hasn't changed. I'm not very comfortable with > > people parsing the subject and body, because that results in some > > combination of unreadable subject and body and scripts that break when > > we try to improve thing. > > At the moment build.gnome.org parses the svn-commits emails and > extracts: > > - commiter, using the From header (but in git, shouldn't it (also?) > look at the Author: field)
If you are looking for who made a particular commit (to be displayed along with the commit message), then yes, the Author field is what you want. The From: header is the person pushing. > - module name, using the Subject header (will be X-Topics) > - revision, (will be X-Git-Newrev, but see below) > - URL, (will be constructed, even though I would still like it in > the email) > - list of added, modified and removed files (this list is then used > to mark commits touching only /po/ as less important, note the > distinction is not really useful, and the list of files as given > be diffstat is enough) > - commit message [...] > As individual changes can be identified, buildbot will just add them > (just like today when there is many commits in a short timeframe) and > trigger a build when things are calm again. > > See http://build.gnome.org/empathy for example (at 17:40:45). Trying to extract the vcs history from the mails is a bit of a quixotic pursuit - but I understand the need to stick close to the way that buildbot works, especially considering that most of the modules are still in svn. There are two particular thing I'd caution about when trying to figure out the history from the mails * Ordering is not reliable. In fact, it's aggressively unreliable currently (to the point where I'm half considering adding sleeps to avoid [3/5],[2/5],[5/5],[1/5],[4/5] series of mails.) So you must not assume the last mail with X-Git-Newrev is the latest one. If buildbot is using revisions to figure out what to pull, then we need to figure out some way to answer "is this newer?". (Header with microsecond timestamp perhaps ... it's not perfect - the commit scripts are not run ordered between multiple commits, but at least it would help with the normal case; or you could remember all the X-Git-Oldrev and try to jigsaw it together.) * In some cases there may be no "individual commit mails" for a change. If I do something like: - Make a change on the master branch - Make a change on some feature branch - Merge the master branch into the feature branch - Push both branches to the server Then the series of mails might be: * [pango/sumerian-cuneiform] (2 commits) ...Merge branch 'master' [pango/sumerian-cuneiform: 1/2] Fix crasher [pango/sumerian-cuneiform: 2/2] Merge branch master * [pango] Fix crasher The mails with the * are "cover emails" - they have the X-Git-Oldrev/X-Git-Newrev describing what changed on the branch, but none of the "what files changed" "who was the author" "commit messages". The other mails are for the individual commits. They don't have the X-Git-Oldrev/X-Git-Newrev. (This is because they don't necessarily correspond to states of the branch in question - there was never any point in the branch'sumerian-cuneiform' where the head of the branch was at the 'Fix crasher'.) They do have all the other information. (In simple cases the two are merged together and you get a single mail with both the X-Git-Oldrev/X-Git-Newrev and a detail for an individual commit.) Anyways, what I'm getting at is that if you look just at mails sent for the master branch, you never see a details commit mail for the "Fix crasher" commit - that was omitted since it was already sent out on the other branch. There's certainly no need to get the corner cases perfect - as long as builds gets kicked off, that should be good enough, and people can go elsewhere to sort out what happens. (It would be very useful if buildbot actually recorded the versions the versions of the individual build, which I don't see in the web UI.) - Owen _______________________________________________ gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
