Page History
- 2020-Mar-20 10:40 zmiller
- 2016-Apr-01 13:03 johnkn
- 2014-May-08 11:13 adesmet
- 2013-Apr-10 15:36 nwp
- 2012-Nov-13 15:56 adesmet
- 2012-Jun-07 15:23 adesmet
- 2012-Jun-07 15:21 adesmet
- 2011-Dec-07 13:19 nwp
- 2011-Aug-15 09:41 nwp
- 2011-Aug-12 14:44 nwp
- 2011-Aug-12 14:27 psilord
- 2009-Dec-23 18:41 adesmet
- 2009-Dec-23 17:00 adesmet
- 2009-Oct-29 14:41 adesmet
- 2009-Oct-29 14:26 adesmet
- 2009-Oct-16 12:07 tannenba
- 2009-Oct-16 10:43 tannenba
- 2009-Sep-11 11:18 adesmet
- 2009-Sep-11 11:05 adesmet
- 2009-Jun-05 11:02 adesmet
- 2009-Mar-19 10:41 tannenba
- 2009-Feb-09 14:36 psilord
- 2009-Feb-09 14:35 psilord
- 2009-Feb-09 14:31 psilord
- 2009-Feb-02 16:36 psilord
- 2009-Feb-02 16:34 psilord
- 2009-Feb-02 16:05 psilord
- 2009-Feb-02 15:14 psilord
- 2009-Feb-02 15:11 psilord
- 2009-Feb-02 15:09 psilord
- 2009-Feb-02 15:08 psilord
- 2009-Feb-02 15:08 psilord
- 2009-Feb-02 15:07 psilord
- 2009-Jan-27 16:46 burnett
- 2009-Jan-22 11:11 burnett
- 2009-Jan-22 11:07 burnett
- 2009-Jan-21 12:19 burnett
- 2009-Jan-21 11:49 burnett
- 2009-Jan-21 11:48 burnett
- 2009-Jan-20 16:34 burnett
- 2009-Jan-20 16:12 burnett
Tricks
Windows
Add a splash of color to git output
For those who grew up with DOS, you'll probably recall the delight when it become possible to display characters on the terminal in color. This feature has long since been disabled, as more and more people are using the GUI rather than the command line to do their work. However, it is still possible to turn those lovely colors back on, if you are so inclined. To do this, simply add the following line in %SystemDrive%\config.sys
(or config.nt
for older versions of NT):
DEVICE=%SystemRoot%\system32\ANSI.SYS
That is it. After you're done reboot and tell git to use colors, it will highlight important information for you.
Trouble Shooting
Merging
File renaming problems
If, while merging, you encounter the following scary message:
warning: too many files, skipping inexact rename detection
You'll get a whole lot of merge conflicts which one would imagine git could have take care of. The problem, at least in my case, is that because detecting file name changes is currently an O(n^2) operation which may take a long time, especially when you take into account the number of files in our repository. As such, git defines an upper limit on the search, so that it will stop after m iteration. This limit can be set by changing the value of diff.renamelimit
to something higher. 400, in my case, seemed to do the trick.