- 07 1月, 2007 6 次提交
-
-
由 Fredrik Kuivinen 提交于
Signed-off-by: NFredrik Kuivinen <frekui@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Alexandre Julliard 提交于
It doesn't make a difference for git.el, but it helps when interacting with git-rebase and friends. Signed-off-by: NAlexandre Julliard <julliard@winehq.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Alexandre Julliard 提交于
The 'quiet' flag is set by -q, but it's not used anywhere. Remove it and set the 'echo1' variable instead. Signed-off-by: NAlexandre Julliard <julliard@winehq.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Steven Grimm 提交于
Signed-off-by: NSteven Grimm <koreth@midwinter.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Steven Grimm 提交于
If a branch other than "master" is checked out in the origin repository, git-clone makes a local copy of that branch rather than the origin's "master" branch. This patch describes the actual behavior. Signed-off-by: NSteven Grimm <koreth@midwinter.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 René Scharfe 提交于
In order to make the generated tar files more friendly to users who extract them as root using GNU tar and its implied -p option, change the default umask to 002 and change the owner name and group name to root. This ensures that a) the extracted files and directories are not world-writable and b) that they belong to user and group root. Before they would have been assigned to a user and/or group named git if it existed. This also answers the question in the removed comment: uid=0, gid=0, uname=root, gname=root is exactly what we want. Normal users who let tar apply their umask while extracting are only affected if their umask allowed the world to change their files (e.g. a umask of zero). This case is so unlikely and strange that we don't need to support it. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 06 1月, 2007 2 次提交
-
-
由 Junio C Hamano 提交于
The earlier test timestamp was too old; I forgot that the bare unixtime integer had to be after Jan 1, 2000. This changes test_tick to use the git-epoch timestamp. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Somehow we forgot to turn save_commit_buffer off while walking the reachable objects. Releasing the memory for commit object data that we do not use matters for large projects (for example, about 90MB is saved while traversing linux-2.6 history). Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 05 1月, 2007 10 次提交
-
-
由 Luben Tuikov 提交于
Blame currently displays the commit id which introduced a block of one or more lines, the line numbers wrt the current listing of the file and the file's line contents. The commit id displayed is hyperlinked to the commit. Currently the linenr links are hyperlinked to the same commit id displayed to the left, which is _no_ different than the block of lines displayed, since it is the _same commit_ that is hyperlinked. And thus clicking on it leads to the same state of the file for that chunk of lines. I.e. data mining is not currently possible with gitweb given a chunk of lines introduced by a commit. This patch makes such data mining possible. The line numbers are now hyperlinked to the parent of the commit id of the block of lines. Furthermore they are linked to the line where that block was introduced. Thus clicking on a linenr link will show you the file's line(s) state prior to the commit id you were viewing. So clicking continually on a linenr link shows you how this line and its line number changed over time, leading to the initial commit where it was first introduced. Signed-off-by: NLuben Tuikov <ltuikov@yahoo.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Jakub Narebski 提交于
Fix "Use of uninitialized value" warning in git_tags_body generated for lightweight tags of tree and blob object; those don't have age ($tag{'age'}) defined. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Eric Wong 提交于
Since fetch reforks itself at most every 1000 revisions, we need to update the counter in the parent process to have a working count if we set our repack interval to be > ~1000 revisions. multi-fetch has always done this correctly because of an extra process; now fetch uses the extra process; as well. While we're at it, only compile the $sha1 regex that checks for repacking once. Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Eric Wong 提交于
Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Eric Wong 提交于
It now requires at least one of the (trunk|branch|tags) arguments (either from the command-line or in .git/config). Also we make sure that anything that is passed as a URL ('help') in David's case is actually a URL. Thanks to David Kågedal for reporting this issue. Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 René Scharfe 提交于
The variable named entry is allocated using malloc() and then forgotten, it being shadowed by an automatic variable of the same name. Fixing the array size at 3 worked so far because the only caller of traverse_trees() needed only as much entries. Simply remove the shadowing varaible and we're able to traverse more than three trees and save stack space at the same time! Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 René Scharfe 提交于
This fixes sparse complaining about a missing include file if 'make check' is run on clean sources. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
There was an obvious thinko in memmove() to remove an entry that was resolved from the in-core data structure. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
* maint: pack-check.c::verify_packfile(): don't run SHA-1 update on huge data Fix infinite loop when deleting multiple packed refs.
-
由 Junio C Hamano 提交于
Running the SHA1_Update() on the whole packfile in a single call revealed an overflow problem we had in the SHA-1 implementation on POWER architecture some time ago, which was fixed with commit b47f509b (June 19, 2006). Other SHA-1 implementations may have a similar problem. The sliding mmap() series already makes chunked calls to SHA1_Update(), so this patch itself will become moot when it graduates to "master", but in the meantime, run the hash function in smaller chunks to prevent possible future problems. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 04 1月, 2007 11 次提交
-
-
由 Robert Fitzsimons 提交于
My change in 190d7fdc had a small bug found by Michael Krufky which caused the passed in hash value to be ignored, so shortlog would only show the HEAD revision. Signed-off-by: NRobert Fitzsimons <robfitz@273k.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Santi Béjar 提交于
This way "git tag -v $tag" is the UI for git-verify-tag. Signed-off-by: NSanti Béjar <sbejar@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Lars Hjemli 提交于
This moves the guts of print_ref_list() into a revamped print_ref_info(), which at the same time gets renamed to print_ref_item(). Signed-off-by: NLars Hjemli <hjemli@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Jakub Narebski 提交于
We now do not skip over empty patches in git_patchset_body (where empty means that they consist only of git diff header, and of extended diff header), so uncomment branch of code dealing with empty patches (patches which do not have even two-line from/to header) Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Jakub Narebski 提交于
Fix bug in git_difftree_body subroutine; it was used '!=' comparison operator for strings (file type) instead of correct 'ne'. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Santi Béjar 提交于
- Teach how to delete a branch with "git branch -d name". - Usually a commit has one parent; merge has more. - Teach "git show" instead of "git cat-file -p". Signed-off-by: NSanti Béjar <sbejar@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Lars Hjemli 提交于
This modifies pretty_print_commit() to make the output of git-rev-list and friends a bit more predictable. A commit body starting with blank lines might be unheard-of, but still possible to create using git-commit-tree (so is bound to appear somewhere, sometime). Signed-off-by: NLars Hjemli <hjemli@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Brian Gernhardt 提交于
Added color.branch and color.branch.<slot> to configuration list. Style copied from color.status and meanings derived from the code. Moved the color meanings from color.diff.<slot> to color.branch.<slot> since the latter comes first alphabetically. Added --color and --no-color to git-branch's usage and documentation. Signed-off-by: NBrian Gernhardt <benji@silverinsanity.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Jakub Narebski 提交于
Instead of "$projectroot/$pr->{'path'}" to get the path to project GIT_DIR, it was used "$projectroot/$project" which is valid only for actions where project parameter is set, and 'project_index' is not one of them. Signed-off-by: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 03 1月, 2007 4 次提交
-
-
由 Junio C Hamano 提交于
It was stupid to link the same element twice to lock_file_list and end up in a loop, so we certainly need a fix. But it is not like we are taking a lock on multiple files in this case. It is just that we leave the linked element on the list even after commit_lock_file() successfully removes the cruft. We cannot remove the list element in commit_lock_file(); if we are interrupted in the middle of list manipulation, the call to remove_lock_file_on_signal() will happen with a broken list structure pointed by lock_file_list, which would cause the cruft to remain, so not removing the list element is the right thing to do. Instead we should be reusing the element already on the list. There is already a code for that in lock_file() function in lockfile.c. The code checks lk->next and the element is linked only when it is not already on the list -- which is incorrect for the last element on the list (which has NULL in its next field), but if you read the check as "is this element already on the list?" it actually makes sense. We do not want to link it on the list again, nor we would want to set up signal/atexit over and over. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Andy Whitcroft 提交于
When passing the revisions list to pack-objects we do not check for errors nor short writes. Introduce a new write_in_full which will handle short writes and report errors to the caller. Use this to short cut the send on failure, allowing us to wait for and report the child in case the failure is its fault. Signed-off-by: NAndy Whitcroft <apw@shadowen.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Eric Wong 提交于
I've noticed that Apache 2.2 on a Debian etch machine has these compiled as modules. Also set ServerName to avoid a warning at startup. Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
They are used in atexit() for clean-up, and you will be accessing unallocated memory at that point. See 31f584c2 for the fix for a similar problem. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 02 1月, 2007 7 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
"Use it with care" is a wrong wording to say "this is purely internal and you are supposed to know what you are doing if you use this". Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
* 'sp/merge' (early part): Use merge-recursive in git-am -3. Allow merging bare trees in merge-recursive. Move better_branch_name above get_ref in merge-recursive.
-
由 J. Bruce Fields 提交于
This is no longer a useful example. Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 J. Bruce Fields 提交于
Update examples, stop using branch named "origin" as an example. Remove large example of use of remotes; that particular case is nicely automated by default, so it's not so pressing to explain, and we can refer to git-repo-config for the details. Signed-off-by: N"J. Bruce Fields" <bfields@citi.umich.edu> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Removal of them is needed regardless of errors. The original code had the removal outside of the process which sets the flag to tell the later step what to remove, but it runs as a downstream of a pipeline and its effect was lost. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-