1 |
On Sat, 19 Sep 2009 22:56:52 +0200 |
2 |
Patrick Lauer <patrick@g.o> wrote: |
3 |
> > The wording in PMS is sound, and says exactly what it needs to say. |
4 |
> > If you'd like to propose clarifications to that wording that make it |
5 |
> > easier to understand, feel free to do so, but the actual meaning |
6 |
> > mustn't be changed. |
7 |
> |
8 |
> "A packager manager should not treat empty categories and categories |
9 |
> that don't exist differently. Both cases should not be treated as |
10 |
> errors." |
11 |
> |
12 |
> How's that? It's not circular and quite readable. And if you noticed |
13 |
> I borrowed most of your interpretation. |
14 |
|
15 |
I'd take a patch for that (keeping or clarifying the original sentence), |
16 |
although stylistically, "Neither case should be" is cleaner. Also, I |
17 |
think we're supposed to be using 'must' over 'should', although most of |
18 |
the existing language doesn't... |
19 |
|
20 |
> > In |
21 |
> > any case, please learn how to use 'git rebase' and only send patches |
22 |
> > that are against current master -- even for patches that do apply, |
23 |
> > if you're basing them upon unpublished changes, we can't use three |
24 |
> > way merges when applying them. |
25 |
> Ah, that sucks. Is there any non-hellish way to use git then? |
26 |
|
27 |
Do your changes on a private branch. Use either 'git cherry-pick' |
28 |
or 'git rebase' to copy them onto either master or a 'to-submit' |
29 |
branch, and create your format-patches from there. Use 'git rebase' to |
30 |
sort your branches out if master changes in the mean time. |
31 |
|
32 |
Note that git rebase is a swiss army chainsaw, and unless you |
33 |
understand exactly what it does, it's fairly easy to lose limbs... The |
34 |
'Git for Computer Scientists' article [1] is a pretty good way of |
35 |
learning what's really going on. |
36 |
|
37 |
[1]: http://eagain.net/articles/git-for-computer-scientists/ |
38 |
|
39 |
-- |
40 |
Ciaran McCreesh |