1 |
On Sat, Feb 02, 2013 at 10:45:19AM -0800, Brian Dolbec wrote: |
2 |
> I do think that it will be difficult to make complete commits for |
3 |
> some changes that do not break catalyst until the remaining commits |
4 |
> are also merged. |
5 |
|
6 |
This may be true for some of the shifting commits, we'll see after the |
7 |
initial reroll. |
8 |
|
9 |
> Thank you for enough info for me to google about commit summary, |
10 |
> message body. Until now I didn't know about needing to separate |
11 |
> them with a blank line. I had never come across that info before, |
12 |
> so had given up trying to format them better. Everything I tried |
13 |
> had failed. Even googling it now it seems to be everywhere but |
14 |
> git's own help. |
15 |
|
16 |
Actually, it is in Git's help: |
17 |
|
18 |
$ git commit --help | grep -B3 blank |
19 |
DISCUSSION |
20 |
Though not required, it’s a good idea to begin the commit message with |
21 |
a single short (less than 50 character) line summarizing the change, |
22 |
followed by a blank line and then a more thorough description. The text |
23 |
up to the first blank line in a commit message is treated as the commit |
24 |
|
25 |
> > 321df3b whitespace cleanup |
26 |
> > |
27 |
> > This looks good, but there are also whitespace cleanups in some other |
28 |
> > commits (e.g. 2d36d29). I think we should just run something like: |
29 |
> > |
30 |
> > for FILE in $(git ls-tree -r --name-only HEAD | grep -v 'bz2$'); do |
31 |
> > sed -i 's/[[:space:]]*$//' "$FILE" |
32 |
> > done |
33 |
> > |
34 |
> > and have done with it ;). |
35 |
> |
36 |
> yeah, that requires way more knowledge about those tools than I know. |
37 |
> For me, I open a file, the editor does the cleanup automatically. If I |
38 |
> don't separate them when committing, then... If I didn't edit the |
39 |
> file... |
40 |
|
41 |
I've pushed this change to the `whitespace` branch on |
42 |
git://tremily.us/catalyst.git if you want to rebase your changes onto |
43 |
that. I can also submit it as a patch to the mailing list if anyone |
44 |
wants it that way. |
45 |
|
46 |
> > 38cd3bb add more configured defaults |
47 |
> > |
48 |
> > List the new settings (distdir, repo_name, packagedir, port_tmpdir, |
49 |
> > options, snapshot_name) in the commit message so I don't have to read |
50 |
> > the diff. Probably explain why you think they should be configurable |
51 |
> > as well. `options` is also a pretty ambiguous name. |
52 |
> |
53 |
> Now that I know how to blab on in a message body with a brief summary, |
54 |
> yeah :) |
55 |
> |
56 |
> "options" was existing and seems comparable to FEATURES for emerge in |
57 |
> make.conf. Suggestions for a new name? |
58 |
|
59 |
In a later comment I suggested breaking each of the options variables |
60 |
out into their own setting. Then we don't have to worry about what to |
61 |
call the boolean settings in aggregate ;). |
62 |
|
63 |
> > This might also be a good place to move the path construction over to |
64 |
> > use os.path.join(). |
65 |
> |
66 |
> Yes, I agree, but I am still getting accustomed to the code, so was |
67 |
> holding off that for a bit. Need to debug changes first. I am also |
68 |
> contemplating stealing the path() from layman which joins a list of |
69 |
> partial paths. I've noticed it could simplify code in many places that |
70 |
> join more than 2 partial paths. |
71 |
|
72 |
Doesn't os.path.join already do that? |
73 |
|
74 |
$ python2.7 -c "import os; print(os.path.join('a', 'b', 'c'))" |
75 |
a/b/c |
76 |
|
77 |
> > This might also be a good time to transition from `CatalystError, …` |
78 |
> > to `CatalystError(…)` where you're touching lines. |
79 |
> > |
80 |
> > I'm not sure which versions of Python Catalyst is trying to support, |
81 |
> > but I'd be happy to see the beginings of a migration to '{}'.format() |
82 |
> > for building strings (vs. the current `'' + ''` concatenation) |
83 |
> |
84 |
> yeah, there are a ton of those in the code. |
85 |
> |
86 |
> Since portage is python-2.6+ and python-2.5 is pretty close to being |
87 |
> removed from the tree... I intend to make it, 2.6, 2.7, 3.2 + |
88 |
> compatible. |
89 |
|
90 |
So the CatalystError(…) updates will be fine, and we should use |
91 |
'{0}'.format(xyz). |
92 |
|
93 |
> > 60919e4 Apply all Matt Turner's has_key() replacement patches |
94 |
> > |
95 |
> > This looks like a job for `rebase` ;). Cherry-picking will just lead |
96 |
> > to redundant commits. |
97 |
> |
98 |
> That will be looked after in my rebase to master again. Since I had |
99 |
> already made a number of changes in my rewrite branch, I could not apply |
100 |
> his commit cleanly without editing. |
101 |
|
102 |
Right. What you should have done is rebase onto the new `master` |
103 |
branch. Where Matt's changes clashed with yours, Git would stop and |
104 |
ask to to fix the conflicts. Then you could update *your* patches so |
105 |
that they worked ;). Since Matt's changes got into `master` first, he |
106 |
gets to keep them the way they originally were. |
107 |
|
108 |
> > 7a909b9 cleanup long lines, improve useage() output formatting |
109 |
> slightly |
110 |
> > |
111 |
> > Can we just switch from getopt to argparse (Python ≥2.7)? |
112 |
> |
113 |
> Yes, we can also add argparse as dep for 2.6 if they want to maintain |
114 |
> 2.6 compatibility. |
115 |
|
116 |
Ah, that would be much nicer :). |
117 |
|
118 |
> > 5eeb8b1 new minimal start script |
119 |
> > |
120 |
> > I think __version__ and __maintainer__ should live in |
121 |
> > catalyst/__init__.py. |
122 |
> |
123 |
> Can do. The version can also be set for releases easily using some |
124 |
> methods from gentoolkit when making the release tarball. The version |
125 |
> could then be left as "git" with a partial hash added of the last commit |
126 |
> when it was merged with. |
127 |
|
128 |
I do something like this in bugs-everywhere [1], but for Catalyst I |
129 |
think it may be more work than it's worth. |
130 |
|
131 |
> > 267dbb6 add __init__.py's to modules and arch sub-pkgs |
132 |
> > |
133 |
> > Added with blank lines? |
134 |
> |
135 |
> I cheated at the time and just used my editor to save an existing one to |
136 |
> different places. So it likely saved it with a blank line. Instead of |
137 |
> using a terminal and touch. |
138 |
|
139 |
These should probably get copyright blurbs and descriptive docstrings |
140 |
anyway, so it's probably not worth worrying over the blank lines. |
141 |
|
142 |
> > da6cbbf rename shell script targets directory to targets.sh so as to |
143 |
> not be confused with the new python targets directory |
144 |
> > |
145 |
> > “so as…” should go in the commit message body to get a shorter |
146 |
> > summary. |
147 |
> > |
148 |
> > I'm not sold on this. Since they are data files intended to be used |
149 |
> > by the Python modules, why not move them to catalyst/targets/scripts |
150 |
> [1]? |
151 |
> |
152 |
> I had been re-thinking that change and was thinking of renaming it back |
153 |
> to targets now that things have been better rearranged. There is one py |
154 |
> file in stage1. It is also easier to do now since it is just one edit |
155 |
> and a git mv away. I've removed that directory name from being hard |
156 |
> coded in the scripts, so now it just means there is one place to edit. |
157 |
|
158 |
This sounds reasonable to me. |
159 |
|
160 |
> > f9f18be update gitignore |
161 |
> > |
162 |
> > The Scratch, catalystc, *.geany, and test* entries would appear to be |
163 |
> > specific to your local installation and usage. I'd drop them from the |
164 |
> > reroll. |
165 |
> > |
166 |
> |
167 |
> They are only for my dev space git repo and me. They will not be part |
168 |
> of a final ready to merge branch. But my dev space is also acting as my |
169 |
> backup, so I committed them. It makes my git status output cleaner. |
170 |
|
171 |
Fair enough, but it's probably a good idea to put your local changes |
172 |
in a clearly marked commit: |
173 |
|
174 |
$ git commit -am 'FIXME: local changes to gitignore' |
175 |
|
176 |
> > d23d96b revert urllib import from commit |
177 |
> 64c16cae70da13de3c55d8555a2e4c5dcdf2fcad since it is not used anywhere |
178 |
> in catalyst |
179 |
> > |
180 |
> > 64c16cae does a lot more than import urllib, so I think “revert” gives |
181 |
> > the wrong impression. I'd remove the import entirely (instead of |
182 |
> > commenting it out), and say: |
183 |
> > |
184 |
> > catalyst/support.py: Remove unused urllib import |
185 |
> > |
186 |
> > This was introduced in commit |
187 |
> > 64c16cae70da13de3c55d8555a2e4c5dcdf2fcad but is no longer used. |
188 |
> |
189 |
> Actually urllib was never used. It was added as a fix for a bug. It |
190 |
> was not a correct fix, so just masked what was causing the bug. I only |
191 |
> commented it out until I could either find what caused the bug or it |
192 |
> just didn't return due to other changes. It is often easier to |
193 |
> comment/uncomment during testing runs than to remove/re-add code. |
194 |
|
195 |
Sure. It's strange that it had any effect at all on a bug if it was |
196 |
never used, but whatever ;). |
197 |
|
198 |
Cheers, |
199 |
Trevor |
200 |
|
201 |
[1]: http://gitorious.org/be/be/blobs/master/libbe/version.py#line21 |
202 |
http://gitorious.org/be/be/blobs/master/Makefile#line80 |
203 |
|
204 |
-- |
205 |
This email may be signed or encrypted with GnuPG (http://www.gnupg.org). |
206 |
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy |