[Ffmpeg-devel-irc] ffmpeg-devel.log.20111122

[burek]

[00:17] <teratorn> weeeee
[01:21] <kierank> MP4_suspended: what are you suspended from?
[02:38] <CIA-36> ffmpeg: 03Reimar Döffinger 07oldabi * rd58c5586ec 10ffmpeg/libavcodec/nuv.c: 
[02:38] <CIA-36> ffmpeg: nuv: Fix combination of size changes and LZO compression.
[02:38] <CIA-36> ffmpeg: There were multiple issues, for example might we have to re-run
[02:38] <CIA-36> ffmpeg: the decompression when the size of the buffer increased,
[02:38] <CIA-36> ffmpeg: we should always use a decompression buffer large enough for
[02:38] <CIA-36> ffmpeg: the header (so we do not get stuck when the size is too small).
[02:38] <CIA-36> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[02:38] <CIA-36> ffmpeg: 03Thierry Foucu 07oldabi * r8a63deab15 10ffmpeg/libavcodec/vp6.c: 
[02:38] <CIA-36> ffmpeg: vp6: Fix illegal read.
[02:38] <CIA-36> ffmpeg: Found with Address Sanitizer
[02:38] <CIA-36> ffmpeg: Signed-off-by: Alex Converse <alex.converse at gmail.com>
[02:38] <CIA-36> ffmpeg: (cherry picked from commit e0966eb140b3569b3d6b5b5008961944ef229c06)
[02:38] <CIA-36> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:38] <CIA-36> ffmpeg: 03Stefano Sabatini 07oldabi * r87ae12009e 10ffmpeg/libavfilter/vf_transpose.c: (log message trimmed)
[02:38] <CIA-36> ffmpeg: vf_transpose: avoid multiple calls to avfilter_draw_slice()
[02:38] <CIA-36> ffmpeg: avfilter_draw_slice() is already called in the end_frame() callback,
[02:38] <CIA-36> ffmpeg: this avoids multiple calls. This is done by adding a null draw_slice()
[02:38] <CIA-36> ffmpeg: callback.
[02:38] <CIA-36> ffmpeg: In particular fix crash occurring with -vf transpose=3,hflip, fix trac
[02:38] <CIA-36> ffmpeg: issue #371.
[02:38] <CIA-36> ffmpeg: 03Miroslav SlugeH 07oldabi * rfd30240e98 10ffmpeg/libavformat/ (Makefile rtpdec.c rtpdec_formats.h rtpdec_g726.c): 
[02:38] <CIA-36> ffmpeg: libavformat: add support for G726 audio decoder in RTP and RTSP streams
[02:38] <CIA-36> ffmpeg: Fixes Ticket611
[02:38] <CIA-36> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:38] <CIA-36> ffmpeg: (cherry picked from commit df9c1cfb48c2d8ddb3c11b4d1e8c4c33c6b0d8a2)
[02:38] <CIA-36> ffmpeg: 03Reimar Döffinger 07oldabi * r54e4bf3296 10ffmpeg/libavformat/flvdec.c: 
[02:38] <CIA-36> ffmpeg: Do not call parse_keyframes_index with NULL stream.
[02:38] <CIA-36> ffmpeg: Seems to fix trac issue #569.
[02:38] <CIA-36> ffmpeg: Sample is unfortunately not available, but it might be caused by
[02:38] <CIA-36> ffmpeg: an index existing for non-existing audio stream (?).
[02:38] <CIA-36> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[02:38] <CIA-36> ffmpeg: (cherry picked from commit 6ea6ff053af2aff8a9a898292f9640efa9290c9f)
[02:38] <CIA-36> (126 lines omitted)
[02:39] <CIA-36> ffmpeg: 03Michael Niedermayer 07oldabi * r5c6a2d9878 10ffmpeg/libavformat/ac3dec.c: (log message trimmed)
[02:39] <CIA-36> ffmpeg: ac3probe: Detect Sonic Foundry Soft Encode AC3 as raw AC3.
[02:39] <CIA-36> ffmpeg: Our ac3 code chain can handle it fine.
[02:39] <CIA-36> ffmpeg: More ideal would be to write a demuxer that actually extracts what can be from the additional
[02:39] <CIA-36> ffmpeg: headers and uses it for whatever it can be used for.
[02:39] <CIA-36> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:39] <CIA-36> ffmpeg: (cherry picked from commit 30ca700ba17b9ba46f4648afa30559ad890f0221)
[02:39] <CIA-36> ffmpeg: 03Michael Niedermayer 07oldabi * r14d4eee547 10ffmpeg/: (log message trimmed)
[02:39] <CIA-36> ffmpeg: Merge remote-tracking branch 'qatar/release/0.7' into release/0.8
[02:39] <CIA-36> ffmpeg: * qatar/release/0.7:
[02:39] <CIA-36> ffmpeg:  Add a version bump and APIchanges entry for avcodec_open2 and avformat_find_stream_info.
[02:39] <CIA-36> ffmpeg:  lavf: fix multiplication overflow in avformat_find_stream_info()
[02:39] <CIA-36> ffmpeg:  lavf: fix invalid reads in avformat_find_stream_info()
[02:39] <CIA-36> ffmpeg:  lavf: add avformat_find_stream_info()
[02:39] <CIA-36> ffmpeg: 03Michael Niedermayer 07oldabi * ra12dec4699 10ffmpeg/: (log message trimmed)
[02:39] <CIA-36> ffmpeg: Merge branch 'release/0.8' into release/0.7
[02:39] <CIA-36> ffmpeg: * release/0.8: (31 commits)
[02:39] <CIA-36> ffmpeg:  svq1dec: call avcodec_set_dimensions() after dimensions changed. Fixes NGS00148
[02:39] <CIA-36> ffmpeg:  vp3dec: Check coefficient index in vp3_dequant() Fixes NGS00145
[02:39] <CIA-36> ffmpeg:  qdm2dec: fix buffer overflow. Fixes NGS00144
[02:39] <CIA-36> ffmpeg:  h264: Fix invalid interlaced progressive MB combinations for direct mode prediction. Fixes Ticket312
[02:39] <CIA-36> ffmpeg: 03Michael Niedermayer 07oldabi * r17c54e9317 10ffmpeg/libavformat/rawdec.c: 
[02:39] <CIA-36> ffmpeg: mjpeg: support mpo
[02:39] <CIA-36> ffmpeg: Fixes stereoscopic_photo.mpo
[02:39] <CIA-36> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:39] <CIA-36> (32 lines omitted)
[03:11] <CIA-36> ffmpeg: 03Anton Khirnov 07master * rb0641ab7a0 10ffmpeg/doc/filters.texi: doc/filters: fix some typos.
[03:11] <CIA-36> ffmpeg: 03Anton Khirnov 07master * r1bb77e51a8 10ffmpeg/avconv.c: 
[03:11] <CIA-36> ffmpeg: avconv: rename 'os' variable to 'oc'
[03:11] <CIA-36> ffmpeg: Output AVFormatContext is called 'oc' in most other places.
[03:11] <CIA-36> ffmpeg: 03Anton Khirnov 07master * r7c9224111e 10ffmpeg/configure: 
[03:11] <CIA-36> ffmpeg: configure: add libpulse to help output
[03:11] <CIA-36> ffmpeg: Fixes Bug 72.
[03:11] <CIA-36> ffmpeg: 03Anton Khirnov 07master * r03f30c837b 10ffmpeg/avconv.c: 
[03:11] <CIA-36> ffmpeg: avconv: cosmetics, reformat transcode_init()
[03:11] <CIA-36> ffmpeg: Fix spacing, vertically align, break some long lines, add some empty
[03:11] <CIA-36> ffmpeg: lines for readability.
[03:11] <CIA-36> ffmpeg: 03Justin Ruggles 07master * ra8fe9a7242 10ffmpeg/libavcodec/pthread.c: pthread: add some malloc failure checks
[03:11] <CIA-36> ffmpeg: 03Michael Niedermayer 07master * r7876f14f8b 10ffmpeg/: (log message trimmed)
[03:11] <CIA-36> ffmpeg: Merge remote-tracking branch 'qatar/master'
[03:11] <CIA-36> ffmpeg: * qatar/master:
[03:11] <CIA-36> ffmpeg:  pthread: add some malloc failure checks
[03:11] <CIA-36> ffmpeg:  avconv: cosmetics, reformat transcode_init()
[03:11] <CIA-36> ffmpeg:  avconv: rename 'os' variable to 'oc'
[03:11] <CIA-36> ffmpeg:  doc/filters: fix some typos.
[09:18] <ZacS123> hi
[09:19] <ZacS123> avfilter_graph_parse seems to be returning 1, but the comments/docs suggest it should only ever return a 0 or negative error code
[15:06] <_kaiza> Hello
[15:06] <_kaiza> FFmpeg 0.7.8 and 0.8.7 have been released
[15:06] <_kaiza> What does that mean ? why are 2 different versions are released ?
[15:07] <av500> so you have a choise
[15:07] <av500> like in a democracy
[15:07] <kierank> FREEDOM
[15:07] <JEEB> _kaiza, those who are still stuck/wish to keep to 0.7.x can get security etc. fixes there
[15:07] <JEEB> and otherwise you have the 0.8.x branch + trunk for other usage
[15:08] <_kaiza> is 0.8.7 stable yet?
[15:08] <JEEB> releases are "stable"
[15:08] <_kaiza> ok thanks
[15:09] <JEEB> or well, as stable as you can get with quick development, I would say that using the trunk isn't a bad idea in most cases either :P
[15:09] <_kaiza> hehe
[15:10] <JEEB> basically the releases are for parties that really, really want "releases"
[15:10] <JEEB> they don't care about anything else but the fact that it is a release :3
[15:19] <ubitux> michaelni: it seems i can't use the option for this actually
[15:20] <ubitux> after the probing, context option are cleared
[15:20] <ubitux> avformat_find_stream_info ’ avcodec_close ’ av_opt_free
[15:21] <ubitux> so the string option gets av_freep()
[15:21] <ubitux> and the meta is NULL after probing
[15:21] <ubitux> so while it should work at decode time, the probing won't work that way
[15:22] <_kaiza> with 0.8.7 and libvo_aacenc: 
[15:22] <_kaiza> ffmpeg: bitbuffer.c:269: WriteBits: Assertion `hBitBuf->cntBits <= (hBitBuf->pBi
[15:22] <ubitux> and basically, the most important timecode is the first one you decode in the mpeg stream (if the container hasn't any)
[15:22] <_kaiza> tBufEnd - hBitBuf->pBitBufBase + 1) * 8' failed.
[15:22] <_kaiza> Aborted
[15:33] <_kaiza> hey
[15:33] <_kaiza> it looks like (for me)
[15:33] <_kaiza> when i'm compiling ffmpeg with libaacplus, libaacplus is working
[15:33] <_kaiza> when i'm compile ffmpeg with libaacplus and libvo_aacenc, both not working !
[15:36] <michaelni> ubitux, but if its a char[123] theres no gurantee that the last decoded by "probing" is matching the first decoded after probe either i think
[15:36] <michaelni> _kaiza, did you try just libvo_aacenc without aacplus ?
[15:37] <michaelni> iam curious if that would make libvo_aacenc work ...
[15:37] <ubitux> michaelni: any reason we could have multiple call to decode_gop() while probing?
[15:38] <ubitux> also, we could dedicate the field to the first one
[15:38] <ubitux> and never update it again
[15:38] <michaelni> might work
[15:38] <michaelni> also what about a int64_t ?
[15:39] <michaelni> in the private context maybe ?
[15:39] <ubitux> you mean using int64_t timecode_frame_start? :p
[15:39] <michaelni> yes but its just an idea i havnt really thought about
[15:39] <ubitux> it depends on fps, drop frame bit too
[15:40] <ubitux> i think expressing as a string is better
[15:41] <ubitux> or we would need to code the timecode in "ffmpeg style" (hard fps value, specific drop frame bit, ...)
[15:41] <ubitux> i don't think it's a good idea
[15:41] <michaelni> fps is possibly not known at the time you parse the gop
[15:42] <ubitux> well then we can't use timecode_frame_start
[15:42] <ubitux> frame -> timecode needs fps + drop flag
[15:43] <ubitux> if we want to code it in a int64_t we need to store the timecode in a custom maner, and i don't think it's a good idea as i just said
[15:43] <michaelni> maybe put the 25bit timecode from gop in a private context int and export the string per frame or something?
[15:44] <ubitux> i don't really like having it in private context; maybe some other codec will have the timecode information in it (is there one already?)
[15:44] <ubitux> ATM we raise some timecode information from container
[15:44] <ubitux> (gxf at least)
[15:44] <ubitux> through the metadata
[15:45] <ubitux> but codecs can also have it: mpeg at least
[15:45] <ubitux> since codecs have no metadata (afaik) i though of adding it to the codec context struct
[15:46] <ubitux> the main goal behind this is to show the user where all the timecode are set
[15:46] <ubitux> containers (gxf, mxf, ...) or codecs (mpeg, ...)
[15:46] <ubitux> ffprobe will show containers timecode in the meta, and codec ones in the stream information
[15:47] <ubitux> hi saste :)
[15:47] <michaelni> what is the disadvantage in having the timecode char* in every private context of every decoder that supports timecodes ?
[15:47] <michaelni> that would also tell the user which support it implicitly
[15:47] <ubitux> mmh true
[15:47] <ubitux> would that work with the issue i raised earlier?
[15:48] <ubitux> (opt being reset, at least at codec context level)
[15:48] <michaelni> if you put the 25bit in a int
[15:48] <michaelni> it should work
[15:48] <ubitux> what's the difference with using a string/array?
[15:49] <ubitux> the int will be reset in the same way, no?
[15:49] <michaelni> a *char gets killed on _close() or you have a memleak
[15:49] <michaelni> hmm
[15:52] <michaelni> true but where exactly is the problem ? the decoder should still see the first gop after probe that it has seen during probe 
[15:53] <michaelni> ubitux,  the *find_stream_info() code should not loose data, neither should probe
[15:54] <ubitux> currently, if i add the option in libavcodec/options.c, the close will reset the field so i can't access it in ffprobe
[15:54] <ubitux> i guess the issue will be the same if the option is in decoder context
[15:56] <michaelni> if i understand correctly you probe + print without any decode between ?
[15:57] <michaelni> if so you have a problem because theres no real gurantee that probe would open or use the decoder
[15:57] <michaelni> i mean if probe can figure out all it needs without using the decoder it wont open it and it never would see a gop or timecode
[15:58] <michaelni> also it might start in the middle of a gop and find a redundant sequence header and stop decoding before a gop start code
[15:58] <michaelni> and then also never know the timecode when it exits probe
[16:00] <michaelni> now one could theoretically force the decode until the timecode is filled in find_stream_info but if the stream has no timecode this would be a problem
[16:05] <ubitux> about adding the feature in find_stream_info mmmh& maybe in case of mpeg we could look for the first GOP (or maybe a fixed N GOP) to extract the timecode
[16:07] <michaelni> and what if there is no GOP header ?
[16:09] <michaelni> "A video sequence commences with a sequence header which  may  optionally  be
[16:09] <michaelni> followed by a group of pictures  header  and  then  by  one  or  more  coded
[16:09] <michaelni> frames."
[16:09] <michaelni> its just "optionally"
[16:10] <ubitux> mmh i don't know the mpeg enough to think of any heuristic to assume there will be a gop or not
[16:11] <michaelni> "At various points in the  video  sequence  a  particular
[16:11] <michaelni> coded frame may be preceded by either a repeat sequence header  or  a  group
[16:11] <michaelni> of pictures header or both.  (In  the  case  that  both  a  repeat  sequence
[16:11] <michaelni> header and a group of  pictures  header  immediately  precede  a  particular
[16:11] <michaelni> picture, the group of pictures  header  shall  follow  the  repeat  sequence
[16:11] <michaelni> header.)"
[16:13] <michaelni> thats all i found that restricts their placement ...
[16:18] <michaelni> and "In the coded bitstream, the first coded frame following a group of  pictures
[16:18] <michaelni> header shall be a coded I-frame."
[16:19] <michaelni> but as far as i can see nothing would disallow a stream to have a gop header once per hour at random places
[16:21] <ubitux> if the timecode is not quickly raised it does not really mean anything
[16:21] <ubitux> so we can have a really short lookup
[16:35] <kierank> hehe mpeg-2 timecode
[16:35] <kierank> h264 can have it on every frame
[16:36] <ubitux> well i think the simpler way is indeed to use the timecode_frame_start field
[16:36] <ubitux> put the 25 bits in it
[16:36] <ubitux> and go with it
[16:36] <ubitux> if the timecode isn't find at probing, then be it; it is needed anyway for the first frame
[16:36] <ubitux> found*
[16:37] <michaelni> we can also extend avoptions to support the char array
[17:03] <ubitux> kierank: i wonder what's the point; so it can be split at any time?
[17:03] <kierank> well with mpeg2 you can only split at gop
[17:03] <kierank> well all i mean
[18:10] <ubitux> not sure the new version is the sexiest way to do it, but it's another way
[18:11] <ubitux> i like it does need to compute the string all the time and the no need of adding a field
[18:11] <ubitux> but it's not perfect either
[18:34] <CIA-36> ffmpeg: 03Michael Niedermayer 07master * r78317881f0 10ffmpeg/libavfilter/avfiltergraph.h: 
[18:34] <CIA-36> ffmpeg: graphparser: Fix doxy on avfilter_graph_parse() return value.
[18:34] <CIA-36> ffmpeg: Found-by: ZacS123
[18:34] <CIA-36> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:17] <CIA-36> ffmpeg: 03Michael Niedermayer 07master * rc12e1bd1bc 10ffmpeg/libavformat/avio.c: 
[21:17] <CIA-36> ffmpeg: avio: allow any chars in protocols
[21:17] <CIA-36> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:17] <CIA-36> ffmpeg: 03Michael Niedermayer 07master * r6161c41817 10ffmpeg/libavformat/avio.c: 
[21:17] <CIA-36> ffmpeg: avio: Support private options in URLProtocols
[21:17] <CIA-36> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:17] <CIA-36> ffmpeg: 03Clément BSsch 07master * r2bb1c713cc 10ffmpeg/libavformat/http.c: 
[21:17] <CIA-36> ffmpeg: http: add user_agent option.
[21:17] <CIA-36> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:18] <ubitux> oh, almost forgot this one :)
[21:18] <ubitux> i wonder if it was really useful though, since we have the headers custom option
[21:19] <ubitux> but well, the option is handy
[21:25] <michaelni> its just a few lines code, easy to throw out it noone uses and wants it but i suspect it might be usefull for something
[21:26] <Compn> hmm
[21:26] <Compn> itunes forcing people to have quicktime user agent to play those trailers
[21:26] <Compn> and other streams require other user agents
[21:26] <Compn> there are mplayer bugzilla entries for this
[21:26] <Compn> ubitux : wasnt aurelien working on subtitle stuff ? is there some patches that were never submitted ?
[21:27] <ubitux> yes Aurelien worked a lot on the subtitles
[21:27] <Compn> i remember a lot of flaming about aurels subtitle code :\
[21:27] <ubitux> i basically started working on ffmpeg when he left
[21:27] <ubitux> i exchanged a few mails about the subtitles state with him
[21:27] <ubitux> but nothing more
[21:27] <Compn> oh ok
[21:41] <CIA-36> ffmpeg: 03Mashiat Sarker Shakkhar 07master * ra3a8d5e0c1 10ffmpeg/libavcodec/wmalosslessdec.c: Initialize pred in lms_predict()
[21:41] <CIA-36> ffmpeg: 03Mashiat Sarker Shakkhar 07master * r6cf31ef263 10ffmpeg/libavcodec/wmalosslessdec.c: Fix some loop conditions to prevent overreads
[21:41] <CIA-36> ffmpeg: 03Mashiat Sarker Shakkhar 07master * rea0323b0fa 10ffmpeg/libavcodec/wmalosslessdec.c: call revert_cdlms()
[21:41] <CIA-36> ffmpeg: 03Michael Niedermayer 07master * rb429440d85 10ffmpeg/: 
[21:41] <CIA-36> ffmpeg: Merge remote-tracking branch 'shariman/wmall'
[21:41] <CIA-36> ffmpeg: * shariman/wmall:
[21:41] <CIA-36> ffmpeg:  call revert_cdlms()
[21:41] <CIA-36> ffmpeg:  Fix some loop conditions to prevent overreads
[21:41] <CIA-36> ffmpeg:  Initialize pred in lms_predict()
[21:41] <CIA-36> ffmpeg: Merged-by: Michael Niedermayer <michaelni at gmx.at>
[21:52] <ubitux> wow a lot of merges recently
[21:53] <ubitux> michaelni: maybe you could try to rebase just a bit to avoid unwanted "commit regressions" which are harder to detect?
[21:54] <CIA-36> ffmpeg: 03Clément BSsch 07master * r530a540cec 10ffmpeg/doc/ffmpeg.texi: doc: add a -map_channel example for splitting channels into streams.
[22:53] <michaelni> ubitux, iam not sure what you mean
[22:56] <ubitux> the risk of merge commits that actually revert some chunks to an old state is pretty common
[22:56] <ubitux> and it's not obvious especially when there are successive merges in the history
[22:57] <ubitux> while when the history is rebased (single line), those "reverted" chunks are spotted pretty easily
[22:57] <ubitux> and much less common too
[22:57] <ubitux> also note the merge commits are not displayed in the cvslog
[22:58] <ubitux> (and anyway not easily readable)
[22:59] <ubitux> while i can understand the explicit merge with qatar, i don't think it's a good idea to merge non-rebased branches
[23:04] <michaelni> ubitux, do you have an example where a chunk was reverted ?
[23:05] <michaelni> also you should talk with the owners of the branches, when they rebase their branch to ffmpeg master HEAD then the following merge is linear if there are no other commits in between
[23:09] <ubitux> michaelni: i remember the some profiles chunks beeing restore by Lou, or something like that
[23:09] <ubitux> also i think you commented some stuff accidently reverted
[23:11] <ubitux> michaelni: you can simple checkout the remote branch, git rebase master, git checkout master and git merge; if it doesn't work the conflict is treated at commit level (but you don't change ownership while updating the commit); you can also ask for a rebase if it doesn't apply
[23:12] <ubitux> but it's just a comment, i'm not asking for this that rigorously
[23:12] <ubitux> i just think we should just avoid excessive merges
[23:12] <michaelni> ubitux, unless you can show a single example where achunk was reverted due to a merge i think you try to solve a problem that doesnt exist
[23:13] <ubitux> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-October/116010.html
[23:14] <ubitux> this is not the only case, i need to look more into it
[23:15] <michaelni> ok but this only case was qatar and they probably wont rebase their code on ffmpeg HEAD
[23:16] <ubitux> yes sure, but it's just an example of inconspicuous merge chunk
[23:17] <ubitux> it's just it can happens, and the harm is that it's not spot immediately
[23:19] <ubitux> doing a rebase just before a merge might be a bit laborious, but you fixed the conflict at commit level (and we can clearly see it in the cvslog)
[23:19] <ubitux> but again, it's just a good practice extra karma hint
[23:20] <ubitux> you're doing daily merge and this is an awesome job, so i won't interfere more into it
[23:20] <ubitux> you know what you do better than i do, that was just my 50ct :p
[23:20] <michaelni> like i said, you should talk to the branch owners, really
[23:21] <michaelni> the closer their branch is to ffmpeg HEAD the less likely is any kind of issue
[23:21] <ubitux> they need to know when you are doing the merge; only you can ask for a rebase when you're going to merge
[23:21] <michaelni> i merge when they tell me to merge
[23:21] <ubitux> i'm not aware of that, and i don't know what branches you are watching :p
[23:30] <michaelni> ubitux, for example, talk with Michael Bradshaw, he had 2 merges on his branch. which when merged led to 3 merges 
[23:30] <michaelni> also i couldnt have rebased it easily
[23:30] <michaelni> but i double checked that the actual diff over the final merge was correct
[23:38] <ubitux> i need to learn how to read merge diff then ;)
[23:39] <michaelni> in this case: git diff 7f6a0190963f99c9b90dc58f17f8d450d2a4f98e^ 7f6a0190963f99c9b90dc58f17f8d450d2a4f98e
[00:00] --- Wed Nov 23 2011