Re: New push emails

[Behdad Esfahbod <behdad behdad org>]

Hi Owen,

This all sounds like the right thing to do.  I'm a bit confused though.  Does
the "This commit already existed in another branch" message mean "this patch
already..."?  Cause I have a hard time seeing how two commits can be the same
without their parents also being the same.  Or maybe it was just your example
that was bogus?

Oh, where did you push the Sumerian Cuneiform shaper BTW?

Cheers,
behdad

Owen Taylor wrote:
> I've installed my push email script. Everything is pretty much as I
> proposed doing it in my earlier mail, with some improvement that were
> suggested.
> 
> I did a lot of testing, but I'm there are some stupid mistakes, so:
> 
>  - If you make a commit to a git repository, and you get an error,
>    please let me know.
> 
>  - If you see a commit email that looks weird or strange or confusing,
>    please let me know.
> 
> If you wait a day or so you should be able to see a bunch of examples by
> searching for 'src.gnome.org' in your svn-commits-list email folder.
> 
> Some particular points of note:
> 
>  - One thing that may look a bit weird is the numbering of mails
>    with merges. You might see a sequence like:
> 
>     [pango] (8 commits) ...Merge branch sumerian-cuneiform
>     [pango: 1/8] Fix crasher
>     [pango: 8/8] Merge branch sumerian-cuneiform
> 
>   That means that 8 commits were pushed at once to the master branch. 
>   The cover email will list all 8 like:
> 
> ===
>     2131312... Fix crasher
>     a412a42... Start implementing Sumerian shaper (*)
>     c123121... Use a less sticky clay (*)
>     ...
>     4121231... Merge branch sumerian-cuneiform
> 
>    (*) This commit already existed in another branch; no separate mail sent
> ===
>  
>   Then only the ones that are genuinely new are mailed out. This all makes
>   sense, but maybe it would be better to just number as 1/2, 2/2.
> 
>  - Because of the behavior where it omits sending out detailed mails for changes
>    already in the repository, you can't always tell exactly what files changed just 
>    by reading mails, something that wa requested. Different ways we could attack this.
> 
>    - The cover email could contain a 'diffstat' for the entire series of commits.
>    - We could extract a common prefix for all changed files and then put that
>      in a header. 'X-Git-Changes-In: po/'. Or Something.
>    - If we really just care about distinguishing po-file only changes, we could
>      have X-Gnome-Po-Only: yes and make it easy for people to filter.
> 
>  - No cgit links yet. I didn't feel like figuring out how to map repo
>    path to cgit path generically and didn't just want to hack it. Not
>    hard though.
> 
> - Owen
> 
> 
> _______________________________________________
> gnome-infrastructure mailing list
> gnome-infrastructure gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
>