git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Question on for-each-ref and --contains

From
SBSt. Blind <st.s.blind@gmail.com>
Date
Dec 23, 2014, 07:50 UTC
Message-ID
<CA++b5FaiKC2+U-Q_q7tBBjX2s+rLY6725H2ScUW26eOf-nmRjw@mail.gmail.com>
Hi.

In order to make some analyses here I had to build certain report lists of our remote refs, based on various "containing" and "merged" rules. We have more than hundred such refs at a time usually. So my poor script which tries to make decisions with the help of rev-list for each ref on each arbitrary commit is not really fast. The git-branch --contains and --merged are not very handy too, because the output is not really flexible, and the --merged works on HEAD only.

Do you think is a good idea to have the option "--contains" in for-each-ref too (and/or in rev-list directly)? If yes, then probably also the --(no-)merged options, but hopefully with the arbitrary commit this time?

Thank you in advance, Blind.

Next: Øystein Walle
Message 1 of 3 in “Question on for-each-ref and --contains”
  1. St. BlindDec 23, 2014
  2. Øystein WalleDec 23, 2014
  3. Jeff KingDec 23, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.