On 3/30/15 6:08 PM, Kan-Ru Chen (陳侃如) wrote:
Is there an hg or git equivalent to Perforce's Time-Lapse View tool? It
shows a global view of a file's blame history and you can visually
scrub
through the blame history.
You mean like git log -p FILE? I'm sure there are fancier graphic ways
On Mon, Mar 30, 2015 at 11:01:28AM -0700, Bobby Holley wrote:
On Mon, Mar 30, 2015 at 10:54 AM, Chris Peterson cpeter...@mozilla.com
wrote:
On 3/29/15 3:35 PM, smaug wrote:
Having the one commit in the blame doesn't really matter. Often one
needs to go to the first commit of the code
On 3/30/15 6:08 PM, Kan-Ru Chen (陳侃如) wrote:
Is there an hg or git equivalent to Perforce's Time-Lapse View tool? It
shows a global view of a file's blame history and you can visually scrub
through the blame history.
You mean like git log -p FILE? I'm sure there are fancier graphic ways to
On 3/29/15 3:35 PM, smaug wrote:
Having the one commit in the blame doesn't really matter. Often one
needs to go to the first commit of the code anyway.
Is there an hg or git equivalent to Perforce's Time-Lapse View tool?
It shows a global view of a file's blame history and you can visually
On Mon, Mar 30, 2015 at 10:54 AM, Chris Peterson cpeter...@mozilla.com
wrote:
On 3/29/15 3:35 PM, smaug wrote:
Having the one commit in the blame doesn't really matter. Often one
needs to go to the first commit of the code anyway.
Is there an hg or git equivalent to Perforce's Time-Lapse
Bobby Holley bobbyhol...@gmail.com writes:
On Mon, Mar 30, 2015 at 10:54 AM, Chris Peterson cpeter...@mozilla.com
wrote:
On 3/29/15 3:35 PM, smaug wrote:
Having the one commit in the blame doesn't really matter. Often one
needs to go to the first commit of the code anyway.
Is there an
Bobby Holley writes:
On Fri, Mar 27, 2015 at 2:04 PM, Mats Palmgren m...@mozilla.com wrote:
So let's change the project-wide coding rules instead to allow 99
columns as the hard limit, but keep 80 columns as the recommended
(soft) limit.
I think we should avoid opening up a can of worms
On 03/28/2015 02:32 AM, Nicolas B. Pierron wrote:
On 03/27/2015 11:51 PM, Bobby Holley wrote:
On Fri, Mar 27, 2015 at 2:04 PM, Mats Palmgren m...@mozilla.com wrote:
So let's change the project-wide coding rules instead to allow 99
columns as the hard limit, but keep 80 columns as the
I just pushed this to inbound (rev 0c030f97a04f).
Jan
On Thu, Mar 26, 2015 at 11:52 PM, Jan De Mooij jdemo...@mozilla.com wrote:
Hi all,
After some discussion, we want to switch SpiderMonkey and XPConnect style
for pointers/references from |T *p| to |T* p| (and |T ref| to |T ref|).
This
On 03/27/2015 12:19 AM, Bobby Holley wrote:
Can we switch from 4-space to 2-space indentation at some point too?
Yeah good idea, and we should probably scratch everything we have done so
far and rewrite everything in whitespace.
--
Nicolas B. Pierron
On Thu, Mar 26, 2015 at 10:37 PM, Birunthan Mohanathas
birunt...@mohanathas.com wrote:
On 27 March 2015 at 01:19, Bobby Holley bobbyhol...@gmail.com wrote:
Can we switch from 4-space to 2-space indentation at some point too?
Together, those would remove the most glaring formatting
On Fri, Mar 27, 2015 at 5:12 PM, Bobby Holley bobbyhol...@gmail.com wrote:
On Thu, Mar 26, 2015 at 10:37 PM, Birunthan Mohanathas
birunt...@mohanathas.com wrote:
I've done all of that and more on a few directories (e.g. xpcom/ in
bug 1046841). If we reach consensus regarding js/ style, I
and security issues as contributors (including employees)
do not look for the original authors.
It would be really nice if there was a way to annotate whitespace-only
changesets as being such, and then configure tools such as hg blame
to look past them.
Cheers,
Botond
On Fri, Mar 27, 2015 at 7:59 PM, Botond Ballo bba...@mozilla.com wrote:
It would be really nice if there was a way to annotate whitespace-only
changesets as being such, and then configure tools such as hg blame
to look past them.
You mean `hg blame -w` ?
On 03/27/2015 11:51 PM, Bobby Holley wrote:
On Fri, Mar 27, 2015 at 2:04 PM, Mats Palmgren m...@mozilla.com wrote:
So let's change the project-wide coding rules instead to allow 99
columns as the hard limit, but keep 80 columns as the recommended
(soft) limit.
I think we should avoid
On Fri, Mar 27, 2015 at 10:25 AM, Robert O'Callahan
rob...@ocallahan.org wrote:
Switching method names to start with a capital letter would be helpful too
... especially where it's leaked into MFBT.
FWIW, here is the contents of mfbt/STYLE:
MFBT uses standard Mozilla style, with the
On 27 March 2015 at 01:19, Bobby Holley bobbyhol...@gmail.com wrote:
Can we switch from 4-space to 2-space indentation at some point too?
Together, those would remove the most glaring formatting differences. The
others (bracing single-line consequents, aNamingWarts, etc) might be harder.
I've
Is the bug tasking this marked dev-doc-needed? We will have SD
A bunch of cleanup to do
On Thursday, March 26, 2015, Jan De Mooij jdemo...@mozilla.com wrote:
Hi all,
After some discussion, we want to switch SpiderMonkey and XPConnect style
for pointers/references from |T *p| to |T* p| (and
Hi all,
After some discussion, we want to switch SpiderMonkey and XPConnect style
for pointers/references from |T *p| to |T* p| (and |T ref| to |T ref|).
This matches the rest of the project and will make life easier for
developers working on multiple parts of the tree.
Although this will break
\o/
Can we switch from 4-space to 2-space indentation at some point too?
Together, those would remove the most glaring formatting differences. The
others (bracing single-line consequents, aNamingWarts, etc) might be harder.
On Thu, Mar 26, 2015 at 3:52 PM, Jan De Mooij jdemo...@mozilla.com
On Fri, Mar 27, 2015 at 12:19 PM, Bobby Holley bobbyhol...@gmail.com
wrote:
\o/
Can we switch from 4-space to 2-space indentation at some point too?
Together, those would remove the most glaring formatting differences. The
others (bracing single-line consequents, aNamingWarts, etc) might be
21 matches
Mail list logo
