- 14 1月, 2007 1 次提交
-
-
由 Eric Wong 提交于
Some of the recent changes and shortcuts to the tests broke things for people using older versions of svn: t9104-git-svn-follow-parent.sh: v1.2.3 (from SuSE 10.0 as reported by riddochc on #git (thanks!)) required an extra 'svn up'. I was also able to reproduce this with v1.1.4 (Debian Sarge). lib-git-svn.sh: SVN::Repos bindings in versions up to and including 1.1.4 (Sarge again) do not pass fs-config options to the underlying library. BerkeleyDB repositories also seem completely broken on all my Sarge machines; so not using FSFS does not seem to be an option for most people. Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 13 1月, 2007 5 次提交
-
-
由 Junio C Hamano 提交于
Steven Grimm noticed that git-repack's verbosity is inconsistent because pack-objects is chatty and prune-packed is not. This makes the latter a bit more chatty and gives -q option to squelch it. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Pointed out by Paul Witt <paul.witt@oxix.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Nicolas Pitre 提交于
While 'init-db' still is and probably will always remain a valid git command for obvious backward compatibility reasons, it would be a good idea to move shipped tools and docs to using 'init' instead. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Andy Parkins noticed that the error message some "whole tree" oriented commands emit is stated misleadingly when they refused to run from a subdirectory. We could probably allow some of them to work from a subdirectory but that is a semantic change that could have unintended side effects, so let's start at first by rewording the error message to be easier to read without doing anything else to be safe. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
It is not available in the outermost merge, and it is only useful for debugging merge-recursive in the inner merges. Sergey Vlasov noticed that the old code accesses an uninitialized location. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 12 1月, 2007 20 次提交
-
-
由 Bob Proulx 提交于
The code previously checked it's own name and called 'die' upon an error. However 'die' was not yet defined because git-sh-setup had not been sourced yet. Instead simply write the error message to stderr and exit with an error as was originally desired. Signed-off-by: NBob Proulx <bob@proulx.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Michael S. Tsirkin 提交于
Despite what the documentation claims, git-commit does not check commit for suspicious lines: all hooks are disabled by default, and the pre-comit hook could be changed to do something else. Signed-off-by: NMichael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Linus Torvalds 提交于
The "read_or_die()" function would silently NOT die for a partial read, and since it was of type "void" it obviously couldn't even return the partial number of bytes read. IOW, it was totally broken. This hopefully fixes it up. Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Linus Torvalds 提交于
With the new-and-improved write_in_full() semantics, where a partial write simply always returns a real error (and always sets 'errno' when that happens, including for the disk full case), a lot of the callers of write_in_full() were just unnecessarily complex. In particular, there's no reason to ever check for a zero length or return: if the length was zero, we'll return zero, otherwise, if a disk full resulted in the actual write() system call returning zero the write_in_full() logic would have correctly turned that into a negative return value, with 'errno' set to ENOSPC. I really wish every "write_in_full()" user would just check against "<0" now, but this fixes the nasty and stupid ones. Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
When --stale-fix is not passed, the code did not initialize the two commit objects properly. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
Recently git.git itself encountered a situation on its master and next branches where git-describe stopped reporting 'v1.5.0-rc0-gN' and instead started reporting 'v1.4.4.4-gN'. This appeared to be a backward jump in version numbering. maint o-------------------4 \ \ master o-o-o-o-o-o-o-5-o-C-o-W The issue is that commit C in the diagram claims it is version 1.5.0, as the tag v1.5.0 is placed on commit 5. Yet commit W claims it is version 1.4.4.4 as the tag v1.5.0 has an older tag date than the v1.4.4.4 tag. As it turns out this situation is very common. A bug fix applied to maint and later merged into master occurs frequently enough that it should Just Work Right(tm). Rather than taking the first tag that gets found git-describe will now generate a list of all possible tags and select the one which has the most number of commits in common with HEAD (or whatever revision the user requested the description of). This rule is based on the principle shown in the diagram above. There are a large number of commits on the primary development branch 'master' which do not appear in the 'maint' branch, and many of these are already tagged as part of v1.5.0-rc0. Additionally these commits are not in v1.4.4.4, as they are part of the v1.5.0 release still being developed. The v1.5.0-rc0 tag is more descriptive of W than v1.4.4.4 is, and therefore should be used. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
* jc/bare: Disallow working directory commands in a bare repository. git-fetch: allow updating the current branch in a bare repository. Introduce is_bare_repository() and core.bare configuration variable Move initialization of log_all_ref_updates
-
由 Junio C Hamano 提交于
* ar/merge-recursive: merge-recursive: do not use on-file index when not needed. Speed-up recursive by flushing index only once for all entries
-
由 Junio C Hamano 提交于
* jc/detached-head: git-checkout: handle local changes sanely when detaching HEAD git-checkout: safety check for detached HEAD checks existing refs git-checkout: fix branch name output from the command git-checkout: safety when coming back from the detached HEAD state. git-checkout: rewording comments regarding detached HEAD. git-checkout: do not warn detaching HEAD when it is already detached. Detached HEAD (experimental) git-branch: show detached HEAD git-status: show detached HEAD
-
由 Junio C Hamano 提交于
If you do: $ /bin/rm foo $ git status we used to say "git add ... to add content to commit". But suggsting "git add" to record the deletion of a file is simply insane. So this rewords various things: - The section header is the old "Changed but not updated", instead of "Changed but not added"; - Suggestion is "git add ... to update what will be committed", instead of "... to add content to commit"; - If there are removed paths, the above suggestion becomes "git add/rm ... to update what will be committed"; - For untracked files, the suggestion is "git add ... to include in what will be committed". Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Often the user would do "/bin/rm foo" before telling git, but then want to tell git about it. "git rm foo" however would fail because it cannot unlink(2) foo. Treat ENOENT error return from unlink(2) as if a successful removal happened. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Eric Wong 提交于
Unfortunately, while {read,write}_in_full do take into account zero-sized reads/writes; their die and whine variants do not. I have a repository where there are zero-sized files in the history that was triggering these things. Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Linus Torvalds 提交于
This fixes another problem that Andy's case showed: git-fsck-objects reports nonsensical results for corrupt objects. There were actually two independent and confusing problems: - when we had a zero-sized file and used map_sha1_file, mmap() would return EINVAL, and git-fsck-objects would report that as an insane and confusing error. I don't know when this was introduced, it might have been there forever. - when "parse_object()" returned NULL, fsck would say "object not found", which can be very confusing, since obviously the object might "exist", it's just unparseable because it's totally corrupt. So this just makes "xmmap()" return NULL for a zero-sized object (which is a valid thing pointer, exactly the same way "malloc()" can return NULL for a zero-sized allocation). That fixes the first problem (but we could have fixed it in the caller too - I don't personally much care whichever way it goes, but maybe somebody should check that the NO_MMAP case does something sane in this case too?). And the second problem is solved by just making the error message slightly clearer - the failure to parse an object may be because it's missing or corrupt, not necessarily because it's not "found". Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Linus Torvalds 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
These days, the command does a lot more than just initialise the object database (such as setting default config-variables, installing template hooks...), and "git init" is actually a more sensible name nowadays. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Linus Torvalds 提交于
It is not used after getting written, and just is leaking every time we write the index out. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 11 1月, 2007 11 次提交
-
-
由 Shawn O. Pearce 提交于
If the user tries to run a porcelainish command which requires a working directory in a bare repository they may get unexpected results which are difficult to predict and may differ from command to command. Instead we should detect that the current repository is a bare repository and refuse to run the command there, as there is no working directory associated with it. [jc: updated Shawn's original somewhat -- bugs are mine.] Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This revamps the merge-recursive implementation following the outline in: Message-ID: <7v8xgileza.fsf@assigned-by-dhcp.cox.net> There is no need to write out the index until the very end just once from merge-recursive. Also there is no need to write out the resulting tree object for the simple case of merging with a single merge base. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Alex Riesen 提交于
The merge-recursive implementation in C inherited the invariant that the on-file index file is written out and later read back after any index operations and writing trees from the original Python implementation. But it was only because the original implementation worked at the scripting level. There is no need to write out the index file after handling every path. Signed-off-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Jürgen Rühle 提交于
Since 98bf8a47 status would claim that git-commit could be useful even if there are no changes except untracked files. Since wt-status is already computing all the information needed go the whole way and actually track the (non-)emptiness of all three sections separately, unify the code, and provide useful messages for each individual case. Thanks to Junio and Michael Loeffler for suggestions. Signed-off-by: NJürgen Rühle <j-r@online.de>
-
由 Junio C Hamano 提交于
* js/reflog: Sanitize for_each_reflog_ent()
-
由 Junio C Hamano 提交于
On Cygwin, newly builtins are not recognized, because there exist both the executable binaries (with .exe extension) _and_ the now-obsolete scripts (without extension), but the script is executed. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Jürgen Rühle 提交于
git-send-email sends out the message taken from format-patch output without quoting nor encoding. When copying the From: line to form in-body From: field, it should not copy it verbatim, because the From: for the header is quoted according to RFC 2047 when not ASCII. The original came from Jürgen Rühle, but I moved the string munging into a separate function so that later other people can tweak it more easily. Bugs introduced during the translation are mine. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Nicolas Pitre 提交于
Oops. Commit 515377ea missed one file, git-init documentation. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Johannes Schindelin 提交于
Since c869753e, core.filemode is hardwired to false on Cygwin. So this test had no chance to succeed, since an early commit (changing just the filemode) failed, and therefore all subsequent tests. Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
The commit buffer (message of the commit) is not actually used by the git-describe process. We can save some memory by not keeping it around. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 10 1月, 2007 3 次提交
-
-
由 Pavel Roskin 提交于
Signed-off-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Originally from David Woodhouse, but also adjusts the callers of mailinfo to the new default. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
It has '-n' to disable it just in case, but do not even bother documenting it. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-