1 |
Rich Freeman: |
2 |
> On Mon, Sep 15, 2014 at 7:37 AM, hasufell <hasufell@g.o> wrote: |
3 |
>> * repoman must be run from all related directories (or the top-level |
4 |
>> directory) on the latest commit that is being pushed |
5 |
> |
6 |
> This should be clarified. Does repoman need to be run on the exact |
7 |
> commit that is being pushed, or perhaps on a "parent" commit prior to |
8 |
> rebasing/merging into the master branch? (I use parent liberally |
9 |
> here, since that commit wouldn't be an actual parent if it were |
10 |
> rebased.) |
11 |
> |
12 |
|
13 |
Yes, you have to rerun repoman after a rebase or merge. On the tip of |
14 |
the local master branch (as in: right before you try to push). |
15 |
|
16 |
Sure, this may lead to problems if repoman takes long... but that's on |
17 |
purpose. If your changes are that big, then they should be communicated |
18 |
and coordinated properly without people randomly pushing changes in |
19 |
between that may break yours. |
20 |
|
21 |
That's no different from what we are doing right now, except that we |
22 |
have now enforced consistency instead of "maybe repoman is correct, |
23 |
maybe not". |
24 |
|
25 |
|
26 |
>> |
27 |
>> == branching model == |
28 |
>> |
29 |
>> * the primary production-ready branch is master (users will pull from |
30 |
>> here), there are no non-fast-forward pushes allowed |
31 |
>> * there may be developer-specific, task-specific, project-specific |
32 |
>> branches etc (there are currently no specific rules about them) |
33 |
> |
34 |
> I suggest we at least toss out some kind of naming convention to prevent chaos. |
35 |
> How about dev/<name> as the namespace for devs acting as individuals |
36 |
> (devs can do whatever they want below this), and project/<name> as the |
37 |
> namespace for projects (which can also do whatever they want below |
38 |
> this). If we missed anything devs should discuss on-list before just |
39 |
> creating random branch names. I don't really want to contrain what |
40 |
> people do here - just try to organize it at least a tiny bit. |
41 |
> |
42 |
|
43 |
Makes sense. If there are no major disagreements, I'll open a wiki page |
44 |
for gentoo git workflow in a few days... as a draft ofc that is open to |
45 |
changes. |