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

Re: Git methodology question

From
Avery Pennarun <apenwarr@gmail.com>
Date
May 14, 2010, 21:54 UTC
Message-ID
<AANLkTin40FdBUx75c0ENHU6PhsN3tPjy1dK-D6cxPgPX@mail.gmail.com>
In-Reply-To
<F802F7F4D3C2674881AB105A9CD324A804EE0D0D8D@azsmsx504.amr.corp.intel.com>

On Fri, May 14, 2010 at 12:14 PM, Akhbari, Farshad <farshad.akhbari@intel.com> wrote:

Show 11 quoted lines
> 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?

You will definitely need all three commit ids (SHA1_* in your words) since all three commits are totally independent from each other.

In order for someone to *get* all three of those commits, they will have to retrieve them somehow. Generally, you do it in one of these ways:

1) Run a git-daemon (or similar) on all three users' machines, and let
the model builder 'git pull' from all three servers
or
2) Have all three users 'git push' to a different branch on the
central repo, as in "git push origin HEAD:user1", "git push origin
HEAD:user2" and so on, and have the model builder merge all three
branches and then push the result back to master.

Of course, you could also have everybody pulling from / pushing to master directly, but I guess that isn't what you're trying to accomplish (it sounds like you want your "model builder" to be a central maintainer who decides what does/doesn't get into the main trunk).

Have fun,
Avery
Previous: Chris PackhamNext: Michael J Gruber
Message 13 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.