On Mon, Oct 03, 2011 at 12:40:43PM -0700, Junio C Hamano wrote: > Tzu-Jung Lee <roylee17@xxxxxxxxx> writes: > > > And also teach the rev-list to parse or interpret the 'saved' refs differently. > > So we can have the following use case: > > > > git log branch_foo --author=some_one -S some_string --saved=cached_ref > > git log cached_ref > > git cherry-pick cached_ref~4 > > git format-patch cached_ref~6..cached_ref~2 > > > > I often have such use cases. not sure others would be benefited from > > such feature. > > Just asking for comment. :) > > It feels too much hackery for too little gain. Agreed. It means that each entry in refs/saved is subtly _not_ a ref, but rather a list of refs. Until now, most refs are considered equal with respect to basic things like ref lookup. So if git were to save this, I'm not sure refs/ would be the right place. A reflog would be a bit closer in concept. But I really don't see the need for git to handle this at all. There is already a general solution: > $ git log --oneline master..branch --author=A.U.Thor -Spickaxe >foos.txt > > and working from the text file foos.txt at least would not contaminate any > ref namespace and you do not have to clean them after you are done. Which works just as well, and is way more flexible. You have to be a little more proficient in using the shell, but that is at least a general skill which transfers to many other programs. -Peff -- 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