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

Re: [PATCH 2/2] Add Author and Documentation sections to git-for-each-ref.txt

From
Jeff King <peff@peff.net>
Date
Mar 13, 2011, 06:47 UTC
Message-ID
<20110313064710.GA13135@sigill.intra.peff.net>
In-Reply-To
<7vsjuril5r.fsf@alter.siamese.dyndns.org>
On Sat, Mar 12, 2011 at 10:34:08PM -0800, Junio C Hamano wrote:
Show 5 quoted lines
> I see you rebased your jk/doc-credits topic at GitHub but haven't queued
> this one yet, so I won't be pulling, but give me a holler when the branch
> is ready to be pulled into 'master'.  I'll then push the result out after
> running final "make doc" check on a few platforms I have and eyeballing
> the output.

It's pushed now. I rebase my topics aggressively on top of master (which you saw), but I don't always push out regularly. Since my main output is patches to the list, in general I assume nobody is actually looking at my topics directly. :) Let me know if some other strategy would be better[1].

I've done a perfunctory check over the changes, but there are a lot of them, so another set of eyeballs on the output is appreciated.

-Peff

[1] I have mixed feelings about the aggressive rebasing. Our 'master' is pretty stable, so I don't feel the need to build off the last tagged release. But rebasing a lot does make it hard for others to follow the topic, and it makes it hard to organize my work with you queue in pu, and then merge to 'next' and 'master'. However, I haven't found a satisfactory solution to tracking patches as they move through the workflow of local development, sent to list, and applied upstream.

Git-cherry sort of does this, but patch-ids miss a lot of cases: patches tweaked in transit, patches applied on a different commit, or even patches taken partially or split up. So I rebase frequently, and as patches get picked up in master, the branches dwindle to empty. Suggestions welcome if anybody else has figured out something clever.

-Peff
Previous: Junio C HamanoNext: Junio C Hamano
Message 20 of 24 in “A couple of tweaks in git-for-each-ref.txt”
  1. 0/2 A couple of tweaks in git-for-each-ref.txtAlexei Sholik, Mar 8, 2011
  2. 1/2 Documentation: remove redundant colons in git-for-each-ref.txtAlexei Sholik, Mar 8, 2011
  3. Michael J GruberMar 9, 2011
  4. 2/2 Add Author and Documentation sections to git-for-each-ref.txtAlexei Sholik, Mar 8, 2011
  5. Michael J GruberMar 9, 2011
  6. Alexei SholikMar 9, 2011
  7. Will PalmerMar 17, 2011
  8. Jeff KingMar 17, 2011
  9. Alexei SholikMar 17, 2011
  10. Jeff KingMar 17, 2011
  11. Alexei SholikMar 17, 2011
  12. Junio C HamanoMar 9, 2011
  13. Jeff KingMar 10, 2011
  14. Junio C HamanoMar 10, 2011
  15. Jeff KingMar 11, 2011
  16. Junio C HamanoMar 11, 2011
  17. Alexei SholikMar 12, 2011
  18. Jeff KingMar 13, 2011
  19. Junio C HamanoMar 13, 2011
  20. Jeff KingMar 13, 2011
  21. Junio C HamanoMar 13, 2011
  22. Michael J GruberMar 13, 2011
  23. Jeff KingMar 17, 2011
  24. Junio C HamanoMar 9, 2011

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.