On Fri, May 14, 2010 at 9:14 AM, Akhbari, Farshad
<farshad.akhbari@xxxxxxxxx> wrote:
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html