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

Help designing work flow

From
JDJohn Dlugosz <jdlugosz@tradestation.com>
Date
Mar 5, 2009, 20:17 UTC
Message-ID
<450196A1AAAE4B42A00A8B27A59278E709F07D30@EXCHANGE.trad.tradestation.com>

I know we (my group) should use "topic" branches and apply them back to the dev branch when done. There is concern that the commit history gets too full of detailed stuff, especially with several developers, that you can't tell what "really changed". So, our dev branch should appear to contain only commit nodes representing completed assignments; not every day's checkpoint and trying to keep one's own stuff on top to avoid merging later.

I guess that's how it is on these Open Source projects where patches are submitted by email and applied by the maintainer. We don't see the details, just the final patch. But, my situation will be developers gathered around an in-house master repo, and everyone should be able to push their own changes as assignments are completed.

What is the best procedure to achieve that? Or what are some good alternatives with trade-offs?

I see that if a topic branch is merged (disabling FF if applicable), the main line (leftmost parent) will be a history of completed topics. But, we don't need to keep the detailed side-branches forever, and even if gitk and other visualization tools can be told to just show the main line, advanced use such as git log this..that will forever be packed with the micro-details.

So, unless someone has more input along that line, I'm assuming that we want to apply the completed topic as a single-parent commit. That is the natural result if preparing patches and then applying them, but is there a simpler, direct way to do that in git?

The detailed topic branches can be kept around for a while, for the original author to extend if it needs to be returned to, and to examine if the gestalt change in the single commit is too overwhelming to understand, or to help figure out what might have broken. But after a while they can be deleted and then gc will free up the disk space.

Anything else I should look into?
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.
Next: Andreas Ericsson
Message 1 of 8 in “Help designing work flow”
  1. John DlugoszMar 5, 2009
  2. Andreas EricssonMar 9, 2009
  3. John TapsellMar 9, 2009
  4. Andreas EricssonMar 9, 2009
  5. John TapsellMar 9, 2009
  6. Andreas EricssonMar 9, 2009
  7. John DlugoszMar 9, 2009
  8. John DlugoszMar 26, 2009

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.