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

Re: Git methodology question

From
Chris Packham <judge.packham@gmail.com>
Date
May 14, 2010, 21:44 UTC
Message-ID
<AANLkTikCHpIJYsORc2buuZkCNgg3dJAt-r7QuNI_dELv@mail.gmail.com>
In-Reply-To
<F802F7F4D3C2674881AB105A9CD324A804EE0D0D8D@azsmsx504.amr.corp.intel.com>

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

Show 22 quoted lines
>
> 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.
>
Hi,

I'm not sure if I entirely understand your question. Is "the model builder" a person?

Making the assumption that it is (the usual term for this would be a project maintainer) then you might wan to have a read of the "DISTRIBUTED WORKFLOWS" section of the gitworkflows man page [1].

The short answer, if I've understood your question, is that all 3 developers will have to submit their work to the maintainer. There are various mechanisms for this; they can either use "git format-patch" and "git send-email" or request that the maintainer pulls from a repository that they have published ("git request-pull" can help by generating a nicely formatted email message).

After the maintainer has applied the changes the developers can then use "git pull" to get the latest changes from the origin. This will include their change and the changes from the other developers and may also include some merge commits.

As developers get more advanced they may start working on topic branches and re-basing (or deleting) the branches after the maintainer has applied their changes. Remember that in this case the topic branches are local so the developers can do what they like with them. The maintainer doesn't care _how_ the developers work locally they are just concerned with the end result.

Hope that helps.
---
[1] http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html#_distributed_workflows
Previous: Akhbari, FarshadNext: Avery Pennarun
Message 12 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.