mirror of
https://github.com/gryf/pentadactyl-pm.git
synced 2026-01-09 16:34:12 +01:00
Comment on 'new' in HACKING
This commit is contained in:
19
HACKING
19
HACKING
@@ -123,6 +123,12 @@ We try to be quite consistent, but of course, that's not always possible.
|
||||
|
||||
There is semantic value to using "new." It's good CBSE. --Ted
|
||||
|
||||
There's no semantic value. It's reasonable to infer that any function
|
||||
named in CamelCase is a constructor. That's the case with all such
|
||||
internal functions. As far as I'm concerned, 'new' is a hack. Actually,
|
||||
most of JS is a hack...
|
||||
--Kris
|
||||
|
||||
== Testing/Optimization ==
|
||||
|
||||
TODO: Add some information here about testing/validation/etc.
|
||||
@@ -138,5 +144,18 @@ TODO: Document the existence of remote branches and discuss when and how
|
||||
to look if an old branch needs to be maintained or a feature needs
|
||||
to be added to a new branch. Keep in mind that git is not the most
|
||||
intuitive SCM.
|
||||
I don't agree. git is about as intuitive as any other SCM, but,
|
||||
regardless, it's by far one of the most popular. There are
|
||||
countless git walkthroughs, FAQs, tips pages (not to mention 'git
|
||||
help') that I don't see the need to duplicate them here. As for
|
||||
branches, 'git branch' should be sufficient, and, if not, there's
|
||||
a list on gitweb. --Kris
|
||||
I wasn't trying to say that git was a problem (though other DVCS
|
||||
have more accessible help systems; except for very complex
|
||||
projects, I think Mercurial is a much more comfortable DVCS to
|
||||
learn, use, and navigate). I was saying that it might be nice if
|
||||
the remote branches (and related polices) were documented. Yes,
|
||||
anyone can do a "git branch -r", but seeing that a branch exists
|
||||
is not the same as understanding why it's there. --Ted
|
||||
|
||||
# vim: set ft=asciidoc fdm=marker sw=4 ts=4 et ai:
|
||||
|
||||
@@ -98,19 +98,6 @@ FEATURES:
|
||||
have a look into the split browser extension
|
||||
1 Add information to liberator/HACKING file about testing and optimization
|
||||
1 Document remote branches in liberator/HACKING
|
||||
I don't agree. git is about as intuitive as any other SCM, but,
|
||||
regardless, it's by far one of the most popular. There are
|
||||
countless git walkthroughs, FAQs, tips pages (not to mention 'git
|
||||
help') that I don't see the need to duplicate them here. As for
|
||||
branches, 'git branch' should be sufficient, and, if not, there's
|
||||
a list on gitweb. --Kris
|
||||
I wasn't trying to say that git was a problem (though other DVCS
|
||||
have more accessible help systems; except for very complex
|
||||
projects, I think Mercurial is a much more comfortable DVCS to
|
||||
learn, use, and navigate). I was saying that it might be nice if
|
||||
the remote branches (and related polices) were documented. Yes,
|
||||
anyone can do a "git branch -r", but seeing that a branch exists
|
||||
is not the same as understanding why it's there. --Ted
|
||||
1 Reformat liberator/HACKING so that git diff can find sections and report changes @ somewhere
|
||||
- many other ideas are listed in the wiki
|
||||
|
||||
|
||||
Reference in New Issue
Block a user