1. 16 5月, 2009 2 次提交
  2. 01 5月, 2009 1 次提交
  3. 21 4月, 2009 1 次提交
    • P
      gitk: Fix compare-commits function when we have local changes · 6f63fc18
      Paul Mackerras 提交于
      This fixes a bug in the compare-commits function added in commit
      010509f2 ("gitk: Add a command to compare two strings of commits")
      where gitk would show an error dialog if the comparison of commits
      got to a fake commit (one showing local changes).  It extends
      getpatchid to handle these fake commits by using [diffcmd] to get
      the git diff command variant to use, and also handles the situation
      where an error occurs.
      
      Now that we can have the fake commit IDs showing up, which are
      00..00 and 00..01, the short ID is ambiguous.  To make sure the links
      point to the right commit, this adds a new [appendshortlink] procedure
      which takes the full link destination, and uses that rather than
      appendwithlinks.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      6f63fc18
  4. 17 4月, 2009 7 次提交
  5. 09 4月, 2009 2 次提交
    • P
      gitk: Add a command to compare two strings of commits · 010509f2
      Paul Mackerras 提交于
      This adds a row context menu command to compare this commit and its
      descendants with the marked commit and its descendants.  The results
      are shown in the bottom-left pane.  Commits are compared by checking
      whether their headlines are the same and their patches have the same
      patch ID as generated by git patch-id.
      
      Merges are ignored and skipped over (as long as they have one
      descendant).  If two commits have the same patch ID then the process
      will continue and compare their descendants, as long as they both have
      exactly one descendant.  If either commit has 0 or 2 or more descendants,
      the comparison stops there.  There is currently a limit of 100
      comparisons.
      
      This can be useful for checking whether one string of commits is just
      a rebased version of another string of commits.  Mark the end of one
      string (i.e. the oldest commit in the string) and invoke "Compare with
      marked commit" on the end of the other string.
      
      As this is implemented, the UI will be unresponsive while the results
      are being generated.  This should be fixed.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      010509f2
    • P
      gitk: Add a way to mark a commit, plus a "find descendant" command · b9fdba7f
      Paul Mackerras 提交于
      This adds a context-menu command to put a mark on this commit.  There
      is at most one marked commit at any time, and it is indicated by a box
      drawn around the headline.  Once a commit is marked, two other
      context-menu commands become available: one to select the marked commit,
      and another to find the closest common descendant of this commit and
      the marked commit.
      
      The "find common descendant" command uses the displayed parent/child
      relationships (i.e. the rewritten parent pointers produced by git log),
      not the real parent/child relationships.  Currently the UI will be
      unresponsive while gitk is working out the nearest common descendant;
      this should be improved in future.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      b9fdba7f
  6. 23 3月, 2009 4 次提交
  7. 02 3月, 2009 1 次提交
    • P
      gitk: Fix possible infinite loop and display corruption · 52b8ea93
      Paul Mackerras 提交于
      This fixes an issue reported by Johannes Sixt on the git mailing list:
      
      > This recipe sends gitk into an endless loop. In git.git do:
      >
      > cd t
      > # remove chmod a+x A near the end of the file
      > sed -i 's/chmod/: chmod/' t3400-rebase.sh
      > sh t3400-rebase.sh --debug
      > cd trash\ directory.t3400-rebase/
      > gitk master modechange modechange@{1}
      >
      >
      > I briefly see the history chart, but the dot that should be modechange@{1}
      > is missing. One automatically selected commit is shown in the diff section
      > below. But then the commit list is cleared and gitk goes into an infinite
      > loop.
      >
      > Things work alright if either modechange@{1} is dropped, or the 'chmod'
      > line is left unchanged, which is a bit strange.
      >
      > This is with git version 1.6.1.2.390.gba743
      
      There were actually two problems.  This recipe created a situation where
      git log would output a child commit after its parent.  This meant that
      we called fix_reversal which called splitvarc, which should call modify_arc
      to note the fact that it has modified the arc that it has just split.  It
      wasn't, which meant that displayorder and other variables got into an
      inconsistent state (a commit appearing twice in displayorder).
      
      This then meant that the targetrow/targetid logic in drawvisible thought
      it need to redraw each time.  That, together with the fact that drawvisible
      called drawcommits which called drawvisible if a redraw was needed, led
      to the infinite loop.
      
      In fact drawvisible is now the only caller of drawcommits.  Thus, the
      start and end row arguments to drawcommits always encompass the whole
      visible area, so drawcommits doesn't need to call drawvisible to redraw;
      it just needs to clear the screen and draw what it's been asked to.
      
      This fixes these two problems by adding a call to modify_arc in
      splitvarc and by taking out the call to drawvisible in drawcommits.
      It also removes an unrelated left-over debugging puts in external_blame.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      52b8ea93
  8. 22 12月, 2008 7 次提交
  9. 06 12月, 2008 1 次提交
    • P
      gitk: Fix bugs in blaming code · 9712b81a
      Paul Mackerras 提交于
      The "show origin of this line" function wasn't working when gitk was
      run in a subdirectory, since it passed the path relative to the
      top-level directory to git blame.  This fixes it by passing the
      absolute path to the file instead of the relative path.
      
      The same problem occurs when running git gui blame, except that
      git gui blame appears not to be able to accept an absolute path to the
      file, so we make a relative path using a new [make_relative] function.
      
      Finally, this fixes a bug in [show_line_source] where we weren't
      setting id, resulting in an error when trying to find the origin of
      a line in the fake commit for local changes not checked in, when its
      parent was a real commit (i.e. there were no changes checked in).
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      9712b81a
  10. 02 12月, 2008 5 次提交
  11. 18 11月, 2008 4 次提交
    • P
      gitk: Fix context menu items for generating diffs when in tree mode · e1160138
      Paul Mackerras 提交于
      Currently, if you invoke the "diff this -> selected" or "diff selected
      -> this" and gitk is in "Tree" mode rather than "Patch" mode, the
      diff display pane will just show the header but not the actual diff,
      unless gitk has done the diff before and thus has the list of files
      that differ.  This was because the logic in gettreediffline that
      checked whether we had moved on to doing something else checked the
      mode (Tree or Patch) before checking whether the ids we're diffing
      had changed.
      
      This fixes it.  The new logic in gettreediffline is slightly hacky
      and relies on the fact that the Tree/Patch mode only applies when
      we're looking at a single commit, not at the diff between two commits.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e1160138
    • A
      gitk: Avoid handling the Return key twice in Add Branch · 68149a71
      Alexander Gavrilov 提交于
      This reverts commit 63767d5f.
      
      A similar change was made as part of commit 76f15947, that added
      bindings to all dialogs, and this duplication causes mkbrgo to be
      called twice, the second time after the window has been destroyed.
      As a result, an error window appears when the code tries to access
      widgets.
      Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      68149a71
    • P
      gitk: Show local changes properly when we have a path limit · cdc8429c
      Paul Mackerras 提交于
      Since gitk looks for the HEAD commit to attach the fake commits for
      local changes to, we can miss out on seeing the fake commits if we
      have a path limit and the HEAD commit doesn't alter any of the files
      in the path limit.
      
      This fixes it by running
      
      	git rev-list -1 $head -- $paths
      
      if we have a path limit, and taking the result of that as the commit
      to attach the fake commits to.  This means that we can be attaching
      the fake commits to a different commit in each view, so we use a new
      $viewmainhead($view) for that.
      
      This also fixes a buglet where updatecommits would only fix up the
      fake commits if the HEAD changed since the last call to updatecommits,
      whereas it should fix them up if the HEAD has changed since this view
      was last created or updated.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      cdc8429c
    • P
      gitk: Fix switch statement in parseviewargs · 29582284
      Paul Mackerras 提交于
      In Tcl, a comment in a switch command where a pattern would be expected
      doesn't do what one would expect, so this moves the comments inside the
      actions.  Doing that shows up an extra "-" which this also removes.
      
      With this, --merge is now handled properly.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      29582284
  12. 15 11月, 2008 1 次提交
  13. 13 11月, 2008 4 次提交
    • P
      gitk: Fix linehtag undefined error with file highlighting · d98d50e2
      Paul Mackerras 提交于
      Occasionally gitk will throw a Tcl error complaining that linehtag(n)
      is undefined when.  It happens when the commit list is still growing
      (e.g. when updating the commit list) and gitk is set to highlight
      commits that affect certain file(s).  What happens is that the changes
      to the commit list set need_redisplay to indicate that the display
      needs to be redrawn.  That causes the next call to drawcommits to call
      clear_display, which unsets iddrawn and thus ensures that readfhighlight
      won't call bolden on any rows that have moved.  However, it is possible
      for readfhighlight to be called after the commit list has changed but
      before drawcommits has run, meaning that readfhighlight will potentially
      think that rows have been drawn when they haven't, because of the
      change in the id -> row mapping (and the fact that iddrawn is indexed
      by id but line[hnd]tag are indexed by row number).
      
      This fixes it (and also optimizes things a little) by making bolden
      and bolden_name check need_redisplay before doing anything.  If
      need_redisplay is set, then there is no point doing anything because
      the whole display is about to get cleared and redrawn, and it avoids
      looking up line[hn]tag using stale row numbers.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d98d50e2
    • A
      gitk: Fix commit encoding support · 590915da
      Alexander Gavrilov 提交于
      This commit fixes two problems with commit encodings:
      
      1) git-log actually uses i18n.logoutputencoding to generate
         its output, and falls back to i18n.commitencoding only
         when that option is not set.  Thus, gitk should use its
         value to read the results, if available.
      
      2) The readcommit function did not process encodings at all.
         This led to randomly appearing misconverted commits if
         the commit encoding differed from the current locale.
      
      Now commit messages should be displayed correctly, except
      when logoutputencoding is set to an encoding that cannot
      represent charecters in the message.  For example, it is
      impossible to convert Japanese characters from Shift-JIS
      to CP-1251 (although the reverse conversion works).
      
      The reason for using git log to read the commit and then getting
      Tcl to convert its output is that is essentially what happens in
      the normal path through getcommitlines, hence there is less chance
      for unintended differences in how commits are processed in
      getcommitlines and do_readcommit.
      Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      590915da
    • A
      gitk: Fix transient windows on Win32 and MacOS · e7d64008
      Alexander Gavrilov 提交于
      Transient windows cause problems on these platforms:
      
      - On Win32 the windows appear in the top left corner
        of the screen. In order to fix it, this patch causes
        them to be explicitly centered on their parents by
        an idle handler.
      
      - On MacOS with Tk 8.4 they appear without a title bar.
        Since it is clearly unacceptable, this patch disables
        transient on that platform.
      Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e7d64008
    • A
      gitk: Add accelerators to frequently used menu commands · cea07cf8
      Alexander Gavrilov 提交于
      This commit documents keyboard accelerators used for menu
      commands in the menu, as it is usually done, and adds some
      more, e.g. F4 to invoke Edit View (or New View if the current
      view is the un-editable "All files" view).
      
      The changes include a workaround for handling Shift-F4 on
      systems where XKB binds special XF86_Switch_VT_* symbols
      to Ctrl-Alt-F* combinations.  Tk often receives these codes
      when Shift-F* is pressed, so it is necessary to bind the
      relevant actions to them as well.
      Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      cea07cf8