Help with gatekeeper workflow.
amanic at gmail.com
Wed Mar 4 07:23:54 GMT 2009
2009/3/4 Eric Berry <elberry at gmail.com>
> The problem with this approach is that we get the merges from trunk as part
> of Joe's history - which isn't bad, but can distract Bob from Joe's real
I don't think its that bad or that it is really avoidable other than using
`bzr replay` from the rebase plugin.
I think if you standardize the merge commit message eg. "merge main",
you should be able to ignore them easily enough.
After you merge his changes into main,
`bzr diff` would in any case show you all the real changes he made.
To avoid the merges from trunk in the history, another approach is to have
> Joe create a local branch of the main branch which he commits work to, and
> he merges changes from the main branch regularly. When he is finished with
> his work, he uses diff to create a patch which he then sends to Bob to
> apply. After Bob approves of the changes, he applies the patch locally and
> commits the changes upwards to the main branch. The problem with this
> approach is that we lose all the history of Joe's commits in the main
this is bad, don't even consider it IMHO
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bazaar