Do we have a convenient way to refer to a specific commit in an already filtered rev-list?

Hi Folks,

Do we have a convenient/symbolic way to refer to a specific commit of an already filtered rev-list? For example, I'm interested in the commits with some constraints:

    git log somepath --author=someone

Without gui/tui tools, I have to frequently CUT & PASTE the commit-ID for further manipulation (show, cherry-pick, ...), and possibly repeat the parsing couple of times if I didn't save the output. I wonder if we have a convenient way to refer to the discrete commits? like HEAD~4, HEAD@{3} or something magic.

Thanks, Roy

On Sun, Sep 25, 2011 at 12:46:20AM +0800, Tzu-Jung Lee wrote:

Use the shell:

  git rev-list --author=someone HEAD >saved-query
  git log --no-walk --stdin <saved-query
  git cherry-pick `cat saved-query`

or even:

  q=`git rev-list --author=someone HEAD`
  git log --no-walk $q
  git cherry-pick $q

-Peff

On Wed, Sep 28, 2011 at 5:35 AM, Jeff King <peff@peff.net> wrote:

Cool, this does record and replay.

How about adding a command or teaching some existing one an option like --saved=<ref_name>, which put the saved-list to refs/saved/<ref_name> ? 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. :)

Regards, Roy

Tzu-Jung Lee <roylee17@gmail.com> writes:

It feels too much hackery for too little gain.

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

On Mon, Oct 03, 2011 at 12:40:43PM -0700, Junio C Hamano wrote:

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:

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