Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 16 6月, 2007 6 次提交
  3. 13 6月, 2007 2 次提交
  5. 12 6月, 2007 6 次提交
  7. 11 6月, 2007 6 次提交
  9. 10 6月, 2007 1 次提交
  11. 08 6月, 2007 2 次提交
    • J
      checkout: do not get confused with ambiguous tag/branch names · 5035242c
      由 Junio C Hamano 提交于 
      Although it is not advisable, we have always allowed a branch
and a tag to have the same basename (i.e. it is not illegal to
have refs/heads/frotz and refs/tags/frotz at the same time).
When talking about a specific commit, the interpretation of
'frotz' has always been "use tag and then check branch",
although we warn when ambiguities exist.

However "git checkout $name" is defined to (1) first see if it
matches the branch name, and if so switch to that branch; (2)
otherwise it is an instruction to detach HEAD to point at the
commit named by $name.  We did not follow this definition when
$name appeared under both refs/heads/ and refs/tags/ -- we
switched to the branch but read the tree from the tagged commit,
which was utterly bogus.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      5035242c
    • S
      git-gui: Changed blame header bar background to match main window · d80ded01
      由 Shawn O. Pearce 提交于 
      The main window's diff header bar background switched from orange
to gold recently, and I liked the effect it had on readability of
the text.  Since I wanted the blame viewer to match, here it is.

Though this probably should be a user defined color, or at least
a constant somewhere that everyone can reference.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      d80ded01
  13. 07 6月, 2007 5 次提交
  15. 06 6月, 2007 12 次提交
    • S
      git-gui: Favor the original annotations over the recent ones · 0f32da53
      由 Shawn O. Pearce 提交于 
      Usually when you are looking at blame annotations for a region of
a file you are more interested in why something was originally
done then why it is here now.  This is because most of the time
when we get original annotation data we are looking at a simple
refactoring performed to better organize code, not to change its
semantic meaning or function.  Reorganizations are sometimes of
interest, but not usually.

We now show the original commit data first in the tooltip.  This
actually looks quite nice as the original commit will usually have an
author date prior to the current (aka move/copy) annotation's commit,
so the two commits will now tend to appear in chronological order.

I also found myself to always be clicking on the line of interest
in the file column but I always wanted the original tracking data
and not the move/copy data.  So I changed our default commit from
$asim_data (the simple move/copy annotation) to the more complex
$amov_data (the -M -C -C original annotation).
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      0f32da53
    • S
      git-gui: Improve our labeling of blame annotation types · 949da61b
      由 Shawn O. Pearce 提交于 
      It feels wrong to call the -M -C -C annotations "move/copy tracking"
as they are actually the original locations.  So I'm relabeling
the status bar to show "copy/move tracking annotations" for the
current file (no -M -C -C) as that set of annotations tells us who
put the hunk here (who moved/copied it).  I'm now calling the -M
-C -C pass "original location annotations" as that's what we're
really digging for.

I also tried to clarify some of the text in the hover tooltip.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      949da61b
    • S
      git-gui: Use three colors for the blame viewer background · 5d198d67
      由 Shawn O. Pearce 提交于 
      To prevent neighboring lines that are different commits from using
the same background color we now use 3 colors and assign them
by selecting the color that is not used before or after the line
in question.  We still color "on the fly" as we receive hunks from
git-blame, but we delay our color decisions until we are getting
the original location data (the slower -M -C -C pass) as that is
usually more fine-grained than the current location data.

Credit goes to Martin Waitz for the tri-coloring concept.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      5d198d67
    • S
      git-gui: Jump to original line in blame viewer · 0dfed77b
      由 Shawn O. Pearce 提交于 
      When the user clicks on a commit link within one of the columns
in the blame viewer we now jump them not just to that commit/file
pair but also to the line of the original file.  This saves the
user a lot of time, as they don't need to search through the new
file data for the chunk they were previously looking at.

We also restore the prior view when the user clicks the back button
to return to a pior commit/file pair that they were looking at.

Turned out this was quite tricky to get working in Tk.  Every time
I tried to jump the text widgets to the correct locations by way
of the "yview moveto" or "see" subcommands Tk performed the change
until the current event finished dispatching, and then reset the
views back to 0, making the change never take place.  Forcing Tk
to run the pending events before we jump the UI resolves the issue.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      0dfed77b
    • S
      git-gui: Display both commits in our tooltips · 383d4e0f
      由 Shawn O. Pearce 提交于 
      If we have commit data from both the simple blame and the
rename/move tracking blame and they differ than there is a
bigger story to tell.  We now include data from both commits
so that the user can see that this link as moved, who moved
it, and where it originated from.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      383d4e0f
    • S
      git-gui: Run blame twice on the same file and display both outputs · 172c92b4
      由 Shawn O. Pearce 提交于 
      We now perform two passes over any input file given to the blame
viewer.  Our first pass is a quick "git-blame" with no options,
getting the details of how each line arrived into this file.  We
are specifically ignoring/omitting the rename detection logic as
this first pass is to determine why things got into the state they
are in.

Once the first pass is complete and is displayed in the UI we run
a second pass, using the much more CPU intensive "-M -C -C" options
to perform extensive rename/movement detection.  The output of this
second pass is shown in a different column, allowing the user to see
for any given line how it got to be, and if it came from somewhere
else, where that is.

This is actually very instructive when run on our own lib/branch.tcl
script.  That file grew recently out of a very large block of code
in git-gui.sh.  The first pass shows when I created that file, while
the second pass shows the original commit information.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      172c92b4
    • S
      git-gui: Display the "Loading annotation..." message in italic · debcd0fd
      由 Shawn O. Pearce 提交于 
      If the user clicks on a line region that we haven't yet received
an annotation for from git-blame we show them "Loading annotation".
But I don't want the user to confuse this loading message with a
commit whose first line is "Loading annotation" and think we messed
up our display somehow.  Since we never use italics for anything
else, I'm going with the idea that italic slant can be used to show
data is missing/elided out at the time being.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      debcd0fd
    • S
      git-gui: Rename fields in blame viewer to better descriptions · fc816d7b
      由 Shawn O. Pearce 提交于 
      Calling the commit message pane $w_cmit is a tad confusing when
we also have the $w_cgrp column that shows the abbreviated SHA-1s.

So w_cmit -> w_cviewer, as it is the "commit viewer"; and
w_cgrp -> w_amov as it is the "annotated commit + move tracking"
column.  Also changed line_data -> amov_data, as that list is
exactly the results shown in w_amov.

Why call the column "move tracking"?  Because this column holds
data from "git blame -M -C".  I'm considering adding an additional
column that holds the data from "git blame" without -M/-C, showing
who did the copy/move, and when they did it.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      fc816d7b
    • S
      git-gui: Label the uncommitted blame history entry · c5db65ae
      由 Shawn O. Pearce 提交于 
      If the user runs the blame viewer on a working directory file
instead of a specific commit-ish then we have no value for the
commit SHA1 or the summary line; this causes the history menu
to get an empty entry at the very bottom.  We now look for this
odd case and call the meny entry "Working Directory".
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      c5db65ae
    • S
      git-gui: Switch internal blame structure to Tcl lists · 2f85b7e4
      由 Shawn O. Pearce 提交于 
      The Tcl list datatype is significantly faster to work with than
the array type, especially if our indexes are a consecutive set
of numbers, like say line numbers in a file.

This rather large change reorganizes the internal data structure
of the blame viewer to use a proper Tcl list for the annotation
information about a line.  Each line is given its own list within
the larger line_data list, where the indexes correspond to various
facts about that particular line.

The interface does seem to be more responsive this way, with less
time required by Tcl to process blame, and to switch to another
version of the same file.  It could just be a placebo effect, but
either way most Tcl experts perfer lists for this type of work over
arrays.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      2f85b7e4
    • S
      git-gui: Cleanup redundant column management in blame viewer · 14c4dfd3
      由 Shawn O. Pearce 提交于 
      The code to handle our three different text widgets is a bit
on the messy side as we issue the same command on all three
widgets one at a time.  Adding (or removing) columns from the
viewer is messy, as a lot of locations need to have the new
column added into the sequence, or removed from it.

We also now delete the tags we create for each commit when
we switch to display another "commit:path" pair.  This way the
text viewer doesn't get bogged down with a massive number of tags
as we traverse through history.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      14c4dfd3
    • S
      git-gui: Better document our blame variables · c17c1751
      由 Shawn O. Pearce 提交于 
      The array variable "order" used to be used to tell us in what
order each commit was received in.  Recent changes have removed
that need for an ordering and the "order" array is now just a
boolean 'do we have that commit yet' flag.

The colors were moved to fields, so they appear inside of the
blame viewer instance.  This keeps two different concurrently
running blame viewers from stepping on each other's ordering
of the colors in group_colors.

Most of the other fields were moved around a little bit so
that they are organized by major category and value lifespan.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      c17c1751