If the GUI installer never starts without any error message, then
  just run …\bin\nt\xsetup.exe
  or …\bin\nt64\xsetup.exe directly.  The toplevel
  installer seems to try to detect what system it is running on and
  gets confused if it encounters certain configurations (I suspect it
  is the XP Media Center Edition, a mixed breed between XP Home and
  XP Professional, that makes it bail in my case).
ISE13.2 and later actually come with a newer version of the
  Digilent plugin than is available from Digilent itself, after
  installation of ISE you find the installer
  in …/ISE_DS/common/bin/<OS>/digilent/.  The Adept
  framework however is an older version that will not work with the
  JTAG HS-1, so you still need to get that one from
  the Digilent website.  You should install the Digilent
  software in its default location.  While it allows you to change the
  installation path, any later update will use the default
  installation path with no option to change it.
Impact in ISE13.3 (and apparently earlier) crashes when loading the IPF project and/or opening the program cable if any Digilent cable has been set to operate at 30MHz. To clear this, start from an empty project — there must be only a single Digilent cable connected, otherwise the UI gets confused — open the cable, set a different speed. Program a device with the new settings. Close the cable, open it again in auto mode and check that the speed has been correctly remembered. You should now be able to use the other Impact projects again (unless you've manually set one of them to use 30MHz).
With ISE14.1 and openSUSE 12.1/Tumbleweed the GUI installer finally
  works, but if you try to use any file choser window, it will hang
  there, so just enter the path name to the installation by hand.
Older versions: If the GUI installer never starts,
  segfaults or otherwise misbehaves, try
  the batch installer —
  this was the ticket for me to finally get the install done on
  openSuSE 11.3.  I've since updated to openSuSE 11.4 and ISE13.x with
  the same installer problems and using the same solution.  ISE seems
  to be compiled using older libraries than required by some
  applications and the LD_LIBRARY_PATH settings don't
  seem to be correct or some libs are compiled in statically that
  shouldn't be.  I really wish someone would educate them about using
  the dynamic linker correctly, especially how rpath specification and
  $ORIGIN work…
Do not try to install the cable drivers unless you really have a Xilinx cable and also have the kernel sources installed since it will fail if they aren't. You don't need those drivers at all if you have a Digilent (or compatible) board or JTAG programmer and you can use libusb-driver if you need to use a parallel port cable or the popup-windows annoy you too much.
To run any applications, just open a new shell and
  source …/ISE_DS/settings32.csh
  or …/ISE_DS/settings32.sh as appropriate.  Start all
  Xilinx (and only those) applications from this shell.  Alternatively
  you can start a subshell together with the application.  That is
  more cumbersome to do on the command line, but easier to set up with
  an alias or wrapper script.
The shell script above sets LD_LIBRARY_PATH in a way
  that prevents most if not all KDE4.6 applications from running.
  This means that ISE can't fire up a browser to show certain parts of
  the help, otherwise I've not run across problems so far.  I've tried
  to prepend the system libraries to the LD_LIBRARY_PATH
  which allows to run KDE applications from the command line, but the
  problem with starting from within ISE remains (with a strange
  complaint from the dynamic linker).  I've not extensively tested if
  that produces further problems, but it seems likely.
I've solved the problem for Firefox (which is started via its
  own wrapper script) by ignoring the
  imported LD_LIBRARY_PATH in that wrapper.  So now the
  external webpages and some internal documentation will be correctly
  sent off to Firefox.  The only problem is that on each update of
  Firefox I'll have to re-edit the wrapper.
ISE14.1 comes again with a newer version of the Digilent plugin
  (version 2.2.10 vs. 2.1.7 from Digilent), but the Adept runtime is
  current.  The FTDI drivers have not been updated, so there is no
  need to reinstall those.
Older versions: ISE13.2 actually comes with a newer
  version of the Digilent plugin than is available from Digilent
  itself (it's version 2.1.5 vs. 2.0.5), after installation of ISE you
  find the installer
  in …/ISE_DS/common/bin/<OS>/digilent/.  The Adept
  framework however is an older version that will not work with the
  JTAG HS-1, so you still need to get that one from
  the Digilent
  website.  ISE13.3 comes with the exact same versions of the
  plugins, so the same setup as for ISE13.2 can be used.
Head over to Xilinx JTAG tools or better yet, clone the Git
repository git clone git://git.zerfleddert.de/usb-driver
and
apply this patch (which sets up to only use libusb-driver
by default).  Install the resulting library
into /usr/local/lib/libusb-driver.so, rename the Impact
binary to impact.orig and install a shell wrapper in its
place:
#!/usr/bin/sh
LD_PRELOAD=/usr/local/lib/libusb-driver.so exec ${0}.orig "$@"
When the GUI install for some reason doesn't work, cd
  to bin/lin, start ./batchxsetup
  --samplebatchtemplate batch.tmpl to create a batch install
  template, once you've edited it to your liking, start the batch
  install using that template ./batchxsetup --batch
  batch.tmpl.  The batch install template should look like this
  (note that the installer adds the »14.1« by itself now and it
  shouldn't be included in the destination directory):
destination_dir=/opt/Xilinx copy_preferences=Y use_multiple_cores=Y application=Acquire or Manage a License Key::0 application=Install Cable Drivers::0 application=Sourcery CodeBench for Xilinx Cortex-A9 EABI::1 application=Sourcery CodeBench for Xilinx Cortex-A9 GNU/Linux::1 application=Setup PlanAhead Install Environment::1 application=Install Linux System Generator Info XML::1 application=Ensure Linux System Generator Symlinks::1
The ISE13.2 template (with a different path to the installation of course) can be used for ISE13.3. There is a new option to take advantage of multiple processor cores during installation that you might want to add and customize appropriately.
The batch install template for ISE13.2 should look like this:
destination_dir=/opt/Xilinx/13.2 copy_preferences=Y application=Acquire or Manage a License Key::0 package=ISE WebPACK::1 application=Configure WebTalk::1 application=Install Linux System Generator Info XML::0 application=Ensure Linux System Generator Symlinks::0 application=Install Cable Drivers::0 application=setupEnv.sh::1
The batch install template for ISE13.1 should look like this:
destination_dir=/opt/Xilinx/13.1 copy_preferences=Y application=Acquire or Manage a License Key::0 application=Install Cable Drivers::0 package=ISE WebPACK::1 environment_variable=PATH::1 environment_variable=LD_LIBRARY_PATH::1 environment_variable=XILINX::1 environment_variable=XILINX_DSP::1 environment_variable=PATH::1 environment_variable=LD_LIBRARY_PATH::1 application=Configure WebTalk::1 application=Install Linux System Generator Info XML::0 application=Ensure Linux System Generator Symlinks::0 environment_variable=XILINX_PLANAHEAD::1 environment_variable=PATH::1 application=setupEnv.sh::0 environment_variable=XILINX_EDK::1 environment_variable=PATH::1 environment_variable=LD_LIBRARY_PATH::1
ISE litters its files all over the project directory by default,
  making proper version control a bit difficult.  Specifying a
  separate working directory in the project settings takes care of
  that.  Coregen when started from ISE, however always uses the source
  directory for re-generating the cores, no matter what the project
  settings in ISE are.  This can be improved by opening the
  ISE-generated project file coregen.cpg in Coregen and
  setting the temporary directory to some separate place in the ISE
  working directory and then cleaning up the mess that the first run
  has already created.  If you already have a Coregen project file
  someplace else, it is easy to modify it so that it can be used
  directly in the new project, saving you the cleanup. The remaining
  plumbing required is to make sure that git doesn't pick up the files
  that ISE generates, so that only the sources make it into the
  repository:
# put into .gitignore or .git/info/exclude # iseconfig isework cgwork .lso *.log cores/* !cores/*.xco
The directory structure implied by this is:
ProjectName/
      cgwork/
	cores/
	iseconfig/ (auto-generated)
	isework/
	ProjectName.xise 
      I prefer to put any sources (Verilog, VHDL) into a separate directory. Note that ISE doesn't require that the sources come from within the project hierarchy, but even if you use sources from someplace else they should probably be added to the project directory as a git submodule or subtree.
ISE tools on Windows seem not to care about CRLF or LF line endings at all. They do however place CRLF line endings on any lines you modify (and only those!) in the GUI. You now have mixed line endings in source files, which should never propagate into the repository. Configure Git appropriately to normalize line endings into the repository before checking in files.