- 16 6月, 2007 8 次提交
-
-
由 Junio C Hamano 提交于
It turns out that the attribute definition we have had for a long time to hide "^" character from AsciiDoc 7 was not honored by AsciiDoc 8 even under "-a asciidoc7compatible" mode. There is a similar breakage with the "compatible" mode with + characters. The double colon at the end of definition list term needs to be attached to the term, without a whitespace. After this minimum fixups, AsciiDoc 8 (I used 8.2.1 on Debian) with compatibility mode seems to produce reasonably good results. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Johannes and Marco discovered that "git log -z" spent cycles in diff even though there is no need to actually compute diffs. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
The original code did not take hierarchical branch names into account at all. [jc: cherry-picked 11f68d90 from 'master'] Tested-by: NGerrit Pape <pape@smarden.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
$EMAIL is a system-wide setup that is used for many many many applications. If the git user chose a specific user.email setup, then _this_ should be honoured rather than $EMAIL. [jc: cherry-picked ec563e81 from 'master'] Signed-off-by: NPierre Habouzit <madcoder@debian.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
[jc: cherry-picked 9f30855d from 'master'] Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Schindelin 提交于
We already have two instances where we want to determine if a buffer contains binary data as opposed to text. [jc: cherry-picked 6bfce93e from 'master'] Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Alex Riesen 提交于
The function converts the value of h_errno (last error of name resolver library, see netdb.h). One of systems which supposedly do not have the function is SunOS. POSIX does not mandate its presence. Signed-off-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jakub Narebski 提交于
Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 6月, 2007 2 次提交
-
-
由 Junio C Hamano 提交于
* ar/clone: Fix clone to setup the origin if its name ends with .git
-
由 Junio C Hamano 提交于
* sv/objfixes: Don't assume tree entries that are not dirs are blobs
-
- 12 6月, 2007 6 次提交
-
-
由 Kristian Høgsberg 提交于
This makes --suppress-from actually work when you're unfortunate enough to have non-ASCII in your name. Also, if there's a match use the optionally RFC2047 quoted version from the email. Signed-off-by: NKristian Høgsberg <krh@redhat.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
Signed-off-by: NLuiz Fernando N. Capitulino <lcapitulino@mandriva.com.br> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
git://repo.or.cz/git-gui由 Junio C Hamano 提交于
* 'maint' of git://repo.or.cz/git-gui: git-gui: Save geometry before the window layout is damaged git-gui: Give amend precedence to HEAD over MERGE_MSG git-gui: Include 'war on whitespace' fixes from git.git
-
由 Shawn O. Pearce 提交于
Because Tk does not assure us the order that it will process children in before it destroys the main toplevel we cannot safely save our geometry data during a "bind . <Destroy>" event binding. The geometry may have already changed as a result of a one or more children being removed from the layout. This was pointed out in gitk by Mark Levedahl, and patched over there by commit b6047c5a. So we now also use "wm protocol . WM_DELETE_WINDOW" to detect when the window is closed by the user, and forward that close event to our main do_quit routine. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Apparently git-commit.sh (the command line commit user interface in core Git) always gives precedence to the prior commit's message if `commit --amend` is used and a $GIT_DIR/MERGE_MSG file also exists. We actually were doing the same here in git-gui, but the amended message got lost if $GIT_DIR/MERGE_MSG already existed because we started a rescan immediately after loading the prior commit's body into the edit buffer. When that happened the rescan found MERGE_MSG existed and replaced the commit message buffer with the contents of that file. This meant the user never saw us pick up the commit message of the prior commit we are about to replace. Johannes Sixt <J.Sixt@eudaptics.com> found this bug in git-gui by running `git cherry-pick -n $someid` and then trying to amend the prior commit in git-gui, thus combining the contents of $someid with the contents of HEAD, and reusing the commit message of HEAD, not $someid. With the recent changes to make cherry-pick use the $GIT_DIR/MERGE_MSG file Johannes saw git-gui pick up the message of $someid, not HEAD. Now we always use HEAD if we are amending. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Earlier git.git applied a large "war on whitespace" patch that was created using 'apply --whitespace=strip'. Unfortunately a few of git-gui's own files got caught in the mix and were also cleaned up. That was a6080a0a. This patch is needed in git-gui.git to reapply those exact same changes here, otherwise our version generator script is unable to obtain our version number from git-describe when we are hosted in the git.git repository. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 11 6月, 2007 6 次提交
-
-
git://repo.or.cz/git-gui由 Junio C Hamano 提交于
* 'maint' of git://repo.or.cz/git-gui: (46 commits) git-gui: Changed blame header bar background to match main window git-gui: Favor the original annotations over the recent ones git-gui: Improve our labeling of blame annotation types git-gui: Use three colors for the blame viewer background git-gui: Jump to original line in blame viewer git-gui: Display both commits in our tooltips git-gui: Run blame twice on the same file and display both outputs git-gui: Display the "Loading annotation..." message in italic git-gui: Rename fields in blame viewer to better descriptions git-gui: Label the uncommitted blame history entry git-gui: Switch internal blame structure to Tcl lists git-gui: Cleanup redundant column management in blame viewer git-gui: Better document our blame variables git-gui: Remove unused commit_list from blame viewer git-gui: Automatically expand the line number column as needed git-gui: Make the line number column slightly wider in blame git-gui: Use lighter colors in blame view git-gui: Remove unnecessary space between columns in blame viewer git-gui: Remove the loaded column from the blame viewer git-gui: Clip the commit summaries in the blame history menu ...
-
由 J. Bruce Fields 提交于
The word "changelog" seems a little too much like jargon to me, and beginners must understand section headers so they know where to look for help. Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
-
由 J. Bruce Fields 提交于
Some more user-manual todo's: how to share objects between repositories, how to recover. Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
-
由 J. Bruce Fields 提交于
I forgot to give an ID for this section. Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
-
由 Gerrit Pape 提交于
In Documentation/user-manual.txt the example $ git checkout --track -b origin/maint maint under "Getting updates with git pull", should read $ git checkout --track -b maint origin/maint This was noticed by Ron, and reported through http://bugs.debian.org/427502Signed-off-by: NGerrit Pape <pape@smarden.org> Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
-
由 J. Bruce Fields 提交于
Update text to reflect new position in appendix. Update the name to reflect the fact that this is closer to reference than tutorial documentation (as suggested by Jonas Fonseca). Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu>
-
- 10 6月, 2007 1 次提交
-
-
由 william pursell 提交于
In several of the text messages, the tense of the verb is inconsistent. For example, "Add" vs "Creates". It is customary to use imperative for command description. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 08 6月, 2007 2 次提交
-
-
由 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>
-
由 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>
-
- 07 6月, 2007 5 次提交
-
-
由 Alex Riesen 提交于
The problem is visible when cloning a local repo. The cloned repository will have the origin url setup incorrectly: the origin name will be copied verbatim in origin url of the cloned repository. Normally, the name is to be expanded into absolute path. Signed-off-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Sam Vilain 提交于
When scanning the trees in track_tree_refs() there is a "lazy" test that assumes that entries are either directories or files. Don't do that. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Milligan 提交于
CVS import was failing on a couple repos I was trying to import. I was setting GIT_DIR=newproj.git and using the -i flag, but this bug was thwarting the effort... evil CVS. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Sam Vilain 提交于
unpack-objects -n didn't print the object list as promised on the manual page, so alter the documentation to reflect the behaviour Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Sixt 提交于
Tests with git-filter-branch on a repository that was converted from CVS and that has commits reaching back to 1999 revealed that it is necessary to parse dates before 2000/01/01 when they are specified as seconds since 1970/01/01. There is now still a limit, 100000000, which is 1973/03/03 09:46:40 UTC, in order to allow that dates are represented as 8 digits. Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 6月, 2007 10 次提交
-
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-
由 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>
-