Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 27 6月, 2007 11 次提交
  3. 26 6月, 2007 1 次提交
    • P
      gitk: Add a progress bar to show progress while resetting · 706d6c3e
      由 Paul Mackerras 提交于 
      Since git reset now gets chatty while resetting, we were getting errors
reported when a reset was done using the "reset branch to here" menu
item.  With this we now read the progress messages from git reset and
update a progress bar.  Because git reset outputs the progress messages
to standard error, and Tcl treats messages to standard error as error
messages, we have to invoke git reset via a shell and redirect standard
error into standard output.

This also fixes a bug in computing descendent heads when head ids
are changed via a reset.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      706d6c3e
  5. 24 6月, 2007 7 次提交
  7. 23 6月, 2007 21 次提交
    • P
      gitk: Improve handling of whitespace and special chars in filenames · 9396cd38
      由 Paul Mackerras 提交于 
      The main thing here is better parsing of the diff --git lines in the
output of git diff-tree -p.  We now cope with filenames in quotes with
special chars escaped.  If the filenames contain spaces they aren't
quoted, however, which can create difficulties in parsing.  We get
around the difficulties by detecting the case when the filename hasn't
changed (chop the part after "diff --git " in two and see if the halves
match apart from a/ in one and b/ in the other), and if it hasn't
changed, we just use one half.  If the filename has changed we wait
for the "rename from" and "rename to" lines, which give the old and
new filenames unambiguously.

This also improves the parsing of the output of git diff-tree.
Instead of using lindex to extract the filename, we take the part from
the first tab on, and if it starts with a quote, we use [lindex $str 0]
to remove the quotes and convert the escapes.

This also gets rid of some unused tagging of the diff text, uses
[string compare] instead of [regexp] in some places, and fixes the
regexp for detecting the @@ hunk-separator lines (the regexp wasn't
accepting a single number, as in "-0,0 +1" for example).
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      9396cd38
    • P
      gitk: Fix bug causing nearby tags/heads to sometimes not be displayed · f3326b66
      由 Paul Mackerras 提交于 
      When we compute descendent heads and descendent/ancestor tags, we
cache the results.  We need to be careful to invalidate the cache
when we add stuff to the graph.  Also make sure that when we cache
descendent heads for a node we only cache the heads that are actually
descendents of that node.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      f3326b66
    • P
      gitk: Limit how often we change the canvas scrolling region · a2c22362
      由 Paul Mackerras 提交于 
      For some unknown reason, changing the scrolling region on the canvases
provokes multiple milliseconds worth of computation in the X server,
and this can end up slowing gitk down significantly.  This works around
the problem by limiting the rate at which we update the scrolling region
after the first 100 rows to at most 2 per second.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a2c22362
    • P
      gitk: Add a "reset branch to here" row context-menu operation · 6fb735ae
      由 Paul Mackerras 提交于 
      This adds an entry to the menu that comes up when the user does a
right-click on a row.  The new entry allows the user to reset the
currently checked-out head to the commit for the row that they did
the right-click on.  The user has to select what type of reset to
do, and confirm the reset, via a dialog box that pops up.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      6fb735ae
    • P
      gitk: Get rid of the childlist variable · 6a90bff1
      由 Paul Mackerras 提交于 
      The information in childlist is a duplicate of what's in the children
array, and it wasn't being accessed often enough to be really worth
keeping the list around as well.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      6a90bff1
    • P
      gitk: Speed up the reading of references · 62d3ea65
      由 Paul Mackerras 提交于 
      We were doing two execs for each tag - one to map the tag ID to a
commit ID and one to read the contents of the tag for later display.
This speeds up the process by not reading the contents of the tag
(instead it is read later if needed), and by using the -d flag to
git show-ref, which gives us refs/tags/foo^{} lines which give us
the commit ID.  Also this uses string operations instead of regexps.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      62d3ea65
    • P
      gitk: Show local uncommitted changes as a fake commit · 219ea3a9
      由 Paul Mackerras 提交于 
      If there are local changes in the repository, i.e., git-diff-index HEAD
produces some output, then this optionally displays an extra row in
the graph as a child of the HEAD commit (but with a red circle to
indicate that it's not a real commit).  There is a checkbox in the
preferences window to control whether gitk does this or not.

Clicking on the extra row shows the diffs between the working directory
and the HEAD (using git diff-index -p).  The right-click menu on the
extra row allows the user to generate a patch containing the local diffs,
or to display the diffs between the working directory and any commit.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      219ea3a9
    • P
      gitk: New algorithm for drawing the graph lines · 322a8cc9
      由 Paul Mackerras 提交于 
      This only draws as much of the graph lines as is visible.  This can
happen by adding coordinates on to an existing graph line or by
creating a new line.  This means that we only need to have laid out
and optimized as much of the graph as is actually visible in order to
draw it, including the lines (previously we didn't draw a graph
line until we had laid out and optimized to the end of a segment of
the line, i.e. down to a down-arrow or to the row where the line's
commit is displayed).  This also lets us get rid of the linesegends
list, and gives us an easy workaround for the X server bug that
causes long lines to be misdrawn.  This also gets rid of the use
of rowoffsets in drawlineseg et al.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      322a8cc9
    • P
      gitk: Store ids in rowrangelist and idrowranges rather than row numbers · 66e46f37
      由 Paul Mackerras 提交于 
      This removes the need for insertrow to go through rowrangelist and
idrowranges and adjust a lot of entries.  The first entry for a given
id is now the row number of the first child, not that row number + 1,
and rowranges compensates for that so its callers didn't have to
change.  This adds a ranges argument to drawlineseg so that we can
avoid calling rowranges a second time inside drawlineseg (all its
callers already called rowranges).
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      66e46f37
    • P
      gitk: Disable the head context menu entries for the checked-out branch · 00609463
      由 Paul Mackerras 提交于 
      Neither the "check out this branch" nor the "remove this branch"
menu item can be used on the currently-checked out branch, so disable
them.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      00609463
    • P
      gitk: Cope with commit messages with carriage-returns and initial blank lines · 43c25074
      由 Paul Mackerras 提交于 
      In some repositories imported from other systems we can get carriage
return characters in the commit message, which leads to a multi-line
headline being displayed in the summary window, which looks bad.
Also some commit messages start with one or more blank lines, which
leads to an empty headline.  This fixes these problems.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      43c25074
    • P
      gitk: Implement a simple scheduler for the compute-intensive stuff · 7eb3cb9c
      由 Paul Mackerras 提交于 
      This allows us to do compute-intensive processing, such as laying out
the graph, relatively efficiently while also having the GUI be
reasonably responsive.  The problem previously was that file events
were serviced before X events, so reading from another process which
supplies data quickly (hi git rev-list :) could mean that X events
didn't get processed for a long time.

With this, gitk finishes laying out the graph slightly sooner and
still responds to the GUI while doing so.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      7eb3cb9c
    • P
      gitk: Improve the behaviour of the initial selection · e507fd48
      由 Paul Mackerras 提交于 
      It used to be that if you clicked on a line while gitk was still drawing
stuff, it would immediately re-select the first line of the display.
This fixes that.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e507fd48
    • P
      gitk: Add some more comments to the optimize_rows procedure · 3fc4279a
      由 Paul Mackerras 提交于 
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      3fc4279a
    • P
      gitk: Don't try to list large numbers of tags or heads in the details pane · 0a4dd8b8
      由 Paul Mackerras 提交于 
      With some large repositories, a commit can end up on thousands of
branches, which results in an extremely long "Branches:" line in the
details window, and that results in the window being extremely slow
to scroll.

This fixes it by just showing "many (N)" after "Branches:", "Follows:"
or "Precedes:", where N is the number of heads or tags.  The limit
is currently set at 20 but could be made configurable (and the "many"
could be a link to pop up a window listing them all in case anyone
really wants to know).
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      0a4dd8b8
    • P
      gitk: New infrastructure for working out branches & previous/next tags · e11f1233
      由 Paul Mackerras 提交于 
      Instead of working out descendent heads and descendent & ancestor
branches in a two-pass algorithm, this reads and stores a simplified
version of the graph topology, and works out descendent/ancestor
tags and descendent heads on demand (with a bit of caching).

The advantages of this are, first, that we now don't have to use
--topo-order on the git rev-list process.  Secondly, we don't have
to re-read the whole graph when tags or heads change or even when
the graph changes.  Since we can cope with parents coming before
children, we can update the graph by running a git rev-list with
arguments that just give us the new commits, and merge the new
commits into the simplified graph.

The graph is simplified in the sense that commits with exactly one
parent and one child (which is >90% of them in most cases) are grouped
together into arcs joining nodes or 'branch/merge points', which are
the commits that don't have exactly 1 parent and 1 child.  This reduces
the size of the graph substantially and decreases the time to traverse
it correspondingly.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e11f1233
    • L
      Fix up "git log --follow" a bit.. · 9f38e1ef
      由 Linus Torvalds 提交于 
      This fixes "git log --follow" to hopefully not leak memory any more, and
also cleans it up a bit to look more like some of the other functions that
use "diff_queued_diff" (by *not* using it directly as a global in the
code, but by instead just taking a pointer to the diff queue and using
that).

As to "diff_queued_diff", I think it would be better off not as a global
at all, but as being just an entry in the "struct diff_options" structure,
but that's a separate issue, and there may be some subtle reason for why
it's currently a global.

Anyway, no real changes. Instead of having a magical first entry in the
diff-queue, we now end up just keeping the diff-queue clean, and keeping
our "preferred" file pairing in an internal "choice" variable. That makes
it easy to switch the choice around when we find a better one.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      9f38e1ef
    • L
      Finally implement "git log --follow" · 750f7b66
      由 Linus Torvalds 提交于 
      Ok, I've really held off doing this too damn long, because I'm lazy, and I
was always hoping that somebody else would do it.

But no, people keep asking for it, but nobody actually did anything, so I
decided I might as well bite the bullet, and instead of telling people
they could add a "--follow" flag to "git log" to do what they want to do,
I decided that it looks like I just have to do it for them..

The code wasn't actually that complicated, in that the diffstat for this
patch literally says "70 insertions(+), 1 deletions(-)", but I will have
to admit that in order to get to this fairly simple patch, you did have to
know and understand the internal git diff generation machinery pretty
well, and had to really be able to follow how commit generation interacts
with generating patches and generating the log.

So I suspect that while I was right that it wasn't that hard, I might have
been expecting too much of random people - this patch does seem to be
firmly in the core "Linus or Junio" territory.

To make a long story short: I'm sorry for it taking so long until I just
did it.

I'm not going to guarantee that this works for everybody, but you really
can just look at the patch, and after the appropriate appreciative noises
("Ooh, aah") over how clever I am, you can then just notice that the code
itself isn't really that complicated.

All the real new code is in the new "try_to_follow_renames()" function. It
really isn't rocket science: we notice that the pathname we were looking
at went away, so we start a full tree diff and try to see if we can
instead make that pathname be a rename or a copy from some other previous
pathname. And if we can, we just continue, except we show *that*
particular diff, and ever after we use the _previous_ pathname.

One thing to look out for: the "rename detection" is considered to be a
singular event in the _linear_ "git log" output! That's what people want
to do, but I just wanted to point out that this patch is *not* carrying
around a "commit,pathname" kind of pair and it's *not* going to be able to
notice the file coming from multiple *different* files in earlier history.

IOW, if you use "git log --follow", then you get the stupid CVS/SVN kind
of "files have single identities" kind of semantics, and git log will just
pick the identity based on the normal move/copy heuristics _as_if_ the
history could be linearized.

Put another way: I think the model is broken, but given the broken model,
I think this patch does just about as well as you can do. If you have
merges with the same "file" having different filenames over the two
branches, git will just end up picking _one_ of the pathnames at the point
where the newer one goes away. It never looks at multiple pathnames in
parallel.

And if you understood all that, you probably didn't need it explained, and
if you didn't understand the above blathering, it doesn't really mtter to
you. What matters to you is that you can now do

	git log -p --follow builtin-rev-list.c

and it will find the point where the old "rev-list.c" got renamed to
"builtin-rev-list.c" and show it as such.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      750f7b66
    • J
      Merge branch 'jc/oneline' · 4d9b5807
      由 Junio C Hamano 提交于 
      * jc/oneline:
  pp_header(): work around possible memory corruption
      4d9b5807
    • J
      Merge branch 'ei/oneline+add-empty' · 9bee7aab
      由 Junio C Hamano 提交于 
      * ei/oneline+add-empty:
  Fix ALLOC_GROW calls with obsolete semantics
  Fix ALLOC_GROW off-by-one
  builtin-add: simplify (and increase accuracy of) exclude handling
  dir_struct: add collect_ignored option
  Extend --pretty=oneline to cover the first paragraph,
  Lift 16kB limit of log message output
      9bee7aab
    • J
      filter-branch: add example to move everything into a subdirectory · 55f22ff2
      由 Johannes Schindelin 提交于 
      This is based on Jeff King's example in

	20070621130137.GB4487@coredump.intra.peff.net
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      55f22ff2