1. 25 Feb, 2008 3 commits
  2. 24 Feb, 2008 2 commits
  3. 23 Feb, 2008 2 commits
  4. 22 Feb, 2008 5 commits
    • Jeff King's avatar
      hash: fix lookup_hash semantics · 9ea0980a
      Jeff King authored
      We were returning the _address of_ the stored item (or NULL)
      instead of the item itself. While this sort of indirection
      is useful for insertion (since you can lookup and then
      modify), it is unnecessary for read-only lookup. Since the
      hash code splits these functions between the internal
      lookup_hash_entry function and the public lookup_hash
      function, it makes sense for the latter to provide what
      users of the library expect.
      
      The result of this was that the index caching returned bogus
      results on lookup. We unfortunately didn't catch this
      because we were returning a "struct cache_entry **" as a
      "void *", and accidentally assigning it to a "struct
      cache_entry *".
      
      As it happens, this actually _worked_ most of the time,
      because the entries were defined as:
      
        struct cache_entry {
      	  struct cache_entry *next;
      	  ...
        };
      
      meaning that interpreting a "struct cache_entry **" as a
      "struct cache_entry *" would yield an entry where all fields
      were totally bogus _except_ for the next pointer, which
      pointed to the actual cache entry. When walking the list, we
      would look at the bogus "name" field, which was unlikely to
      match our lookup, and then proceed to the "real" entry.
      
      The reading of bogus data was silently ignored most of the
      time, but could cause a segfault for some data (which seems
      to be more common on OS X).
      Signed-off-by: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      9ea0980a
    • Shawn O. Pearce's avatar
      git-gui: Focus insertion point at end of strings in repository chooser · 3baee1f3
      Shawn O. Pearce authored
      When selecting a local working directory for a new repository or a
      location to clone an existing repository into we now set the insert
      point at the end of the selected path, allowing the user to type in
      any additional parts of the path if they so desire.
      Signed-off-by: default avatarShawn O. Pearce <[email protected]>
      3baee1f3
    • Shawn O. Pearce's avatar
      git-gui: Avoid hardcoded Windows paths in Cygwin package files · df4ec4cf
      Shawn O. Pearce authored
      When we are being built by the Cygwin package maintainers we need to
      embed the POSIX path to our library files and not the Windows path.
      Embedding the Windows path means all end-users who install our Cygwin
      package would be required to install Cygwin at the same Windows path
      as the package maintainer had Cygwin installed to.  This requirement
      is simply not user-friendly and may be infeasible for a large number
      of our users.
      
      We now try to auto-detect if the Tcl/Tk binary we will use at runtime
      is capable of translating POSIX paths into Windows paths the same way
      that cygpath does the translations.  If the Tcl/Tk binary gives us the
      same results then it understands the Cygwin path translation process
      and should be able to read our library files from a POSIX path name.
      
      If it does not give us the same answer as cygpath then the Tcl/Tk
      binary might actually be a native Win32 build (one that is not
      linked against Cygwin) and thus requires the native Windows path
      to our library files.  We can assume this is not a Cygwin package
      as the Cygwin maintainers do not currently ship a pure Win32 build
      of Tcl/Tk.
      
      Reported on the git mailing list by Jurko Gospodnetić.
      Signed-off-by: default avatarShawn O. Pearce <[email protected]>
      df4ec4cf
    • Shawn O. Pearce's avatar
      git-gui: Default TCL_PATH to same location as TCLTK_PATH · 651fbba2
      Shawn O. Pearce authored
      Most users set TCLTK_PATH to tell git-gui where to find wish, but they
      fail to set TCL_PATH to the same Tcl installation.  We use the non-GUI
      tclsh during builds so headless systems are still able to create an
      index file and create message files without GNU msgfmt.  So it matters
      to us that we find a working TCL_PATH at build time.
      
      If TCL_PATH hasn't been set yet we can take a better guess about what
      tclsh executable to use by replacing 'wish' in the executable path with
      'tclsh'.  We only do this replacement on the filename part of the path,
      just in case the string "wish" appears in the directory paths.  Most of
      the time the tclsh will be installed alongside wish so this replacement
      is a sensible and safe default.
      Signed-off-by: default avatarShawn O. Pearce <[email protected]>
      651fbba2
    • Shawn O. Pearce's avatar
      git-gui: Paper bag fix error dialogs opening over the main window · 85ec3e77
      Shawn O. Pearce authored
      If the main window is the only toplevel we have open then we
      don't have a valid grab right now, so we need to assume the
      best toplevel to use for the parent is ".".
      Signed-off-by: default avatarShawn O. Pearce <[email protected]>
      85ec3e77
  5. 21 Feb, 2008 2 commits
  6. 20 Feb, 2008 8 commits
  7. 17 Feb, 2008 1 commit
  8. 16 Feb, 2008 15 commits
  9. 15 Feb, 2008 2 commits