On Thu, 2009-03-05 at 22:12 -0500, Behdad Esfahbod wrote: > 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?
Merges. If branch A is merged into branch B, then the commits on branch A are now on branch B as well after the merge. In the example I gave things got a bit weirder because the branch that was merged into was pushed before the branch that was merged. Unfortunately there's no identity for patches that are cherry-picked between branches rather than merged ... they just look like duplicates. - Owen > Oh, where did you push the Sumerian Cuneiform shaper BTW? Heh :-) > 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 > > [email protected] > > http://mail.gnome.org/mailman/listinfo/gnome-infrastructure > > > > _______________________________________________ > gnome-infrastructure mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-infrastructure _______________________________________________ gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
