Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > Hi, > > On Thu, 18 Jan 2007, David Kågedal wrote: > >> Someone who knows how it *actually* works is encouraged to send a >> better explanation. > > Nice try... Unfortunately, I don't have time to do it. > >> +--ignore-if-in-upstream:: >> + Do not include the same patch twice. If there are two commits >> + that would produce identical patches, the second one is >> + excluded from the output. > > This is not what it does, though. (If in doubt, use the source, Luke). I did. But I haven't learnt to navigate it yet. I get confused by the global state in the code, which makes it hard to know when I function call returns interesting information or changes some global table. > Given a range upstream..localbranch, --ignore-if-in-upstream looks at all > diffs associated with commits in localbranch..upstream (i.e. all commits > upstream has, but not localbranch), and when traversing > upstream..localbranch to output the commits with diffs, drops those at the > floor which were already seen in localbranch..upstream. Ah, now I see. How about this, then: +--ignore-if-in-upstream:: + Do not include a patch that matches a commit in + <until>..<since>. This will examine all patches reachable + from <since> but not from <until> and compare them with the + patches being generated, and any patch that matches is + ignored. It's hard to get something readable without writing lots about what <since>..<until> actually means. Which might actually be a good idea to do. But I don't have time to do that :-) -- David Kågedal - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html