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

Git methodology question

From
AFAkhbari, Farshad <farshad.akhbari@intel.com>
Date
May 14, 2010, 16:14 UTC
Message-ID
<F802F7F4D3C2674881AB105A9CD324A804EE0D0D8D@azsmsx504.amr.corp.intel.com>
In-Reply-To
<4BED7574.4070503@drmicha.warpmail.net>
All,
I am trying to setup a "reliable" flow with git. I am sort of new to the tool and need some help from the experts. The question pertains to the way SHA1 tags can be back-tracked in parallel clones. Here is the scenario I have in mind:

In order of time: User1 – pulls from the origin; updates, modifies, verifies and commits into his clone. This will generate SHA1_1 User2 – pulls from the origin; updates, modifies, verifies and commits into his clone. This will generate SHA1_2 User3 – pulls from the origin; updates, modifies, verifies and commits into his clone. This will generate SHA1_3

In none of these cases, anyone is updating from each other’s clones
At the end of the week, the model builder needs to merge and verify all commits from user1, user2 and user3 before pushing into the origin master. 
The question is,
            Can the model builder use SHA1_3 tag only to get all the updates made by user1, user2 and user3; or all SHA1 tags are needed?

Thanks, Farshad.

Previous: Michael J GruberNext: Chris Packham
Message 11 of 27 in “revlist/rev-parse: Introduce --heads and --locals revision specifiers”
  1. revlist/rev-parse: Introduce --heads and --locals revision specifiersMichael J Gruber, May 1, 2010
  2. Jakub NarebskiMay 1, 2010
  3. Michael J GruberMay 1, 2010
  4. Jakub NarebskiMay 1, 2010
  5. Jeff KingMay 2, 2010
  6. Michael J GruberMay 2, 2010
  7. Jeff KingMay 5, 2010
  8. 0/4 All is too muchMichael J Gruber, May 13, 2010
  9. Jeff KingMay 14, 2010
  10. Michael J GruberMay 14, 2010
  11. Git methodology questionAkhbari, Farshad, May 14, 2010
  12. Chris PackhamMay 14, 2010
  13. Avery PennarunMay 14, 2010
  14. 0/4 All is too muchMichael J Gruber, May 14, 2010
  15. 1/4 rev-parse: deprecate use as an option sifterMichael J Gruber, May 14, 2010
  16. 2/4 t6018: add tests for rev-list's --branches and --tagsMichael J Gruber, May 14, 2010
  17. 3/4 t6018: make sure all tested symbolic names are different revsMichael J Gruber, May 14, 2010
  18. 4/4 revlist: Introduce --lrbranches and --locals revision specifiersMichael J Gruber, May 14, 2010
  19. 1/4 rev-parse: deprecate use as an option sifterMichael J Gruber, May 13, 2010
  20. Jakub NarebskiMay 14, 2010
  21. Michael J GruberMay 14, 2010
  22. Jakub NarebskiMay 14, 2010
  23. Michael J GruberMay 14, 2010
  24. Thomas RastMay 17, 2010
  25. 2/4 t6018: add tests for rev-list's --branches and --tagsMichael J Gruber, May 13, 2010
  26. 3/4 t6018: make sure all tested symbolic names are different revsMichael J Gruber, May 13, 2010
  27. 4/4 revlist: Introduce --lrbranches and --locals revision specifiersMichael J Gruber, May 13, 2010

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.