Re: git status update?

[Owen Taylor <otaylor redhat com>]

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