Re: [PATCH] Fixes git-cherry algorithmic flaws

>> I wonder if we can kill it by introducing a new rev notation and
>> using regular rev-list family of commands instead.
>> 
>> What we want here is a way to say "give me commits that are in B
>> but not in A, but before returning a commit see if there is an
>> equivalent change in the set of commits that are in A but not in
>> B, and filter it out".
> 
> I think that your formalization is very close to what I was expecting to 
> get (sort of one-way definition)... However, my git-cherry way produces 
> "difference" but on a higher level (than git-diff) since it includes both 
> + and - "changes". Of course, when I have then modified one of the 
> changesets slightly, I have different patch id, and thus + and - with same 
> log message (with verbose), which IMHO is a good thing to notice, 
> especially if I return to the work after 2 weeks or so :-).  
> 
> A real life example: In a branch, I have changed tcp_packets_in_flight 
> (~10 callers) to input sk instead of tp in a single changeset and >10 
> minor changesets. I would love to see tcp_packets_in_fligth change 
> information just once when doing diffing topic-old topic-new during cherry 
> picking, instead of a lengthy diff full of search-and-replace "noise", 
> which increases possiblity of an human error...
> 
> But anyway, I'm not claiming that your approach is less useful...