Re: [PATCH] Fixes git-cherry algorithmic flaws

[Jakub Narebski <jnareb@gmail.com>]

Ilpo Järvinen wrote:

> On Sun, 24 Sep 2006, Junio C Hamano wrote:

>> 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...

+1 on an idea that git-cherry is "diff of logs". Perhaps to add some header.
Of course use patch_ids _and_ the commit message to compare (we can have
both match, patch id match only, commit message match only, and commit
title (first line) match only), but that can be selected using options. 
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git