- 12 12月, 2006 3 次提交
-
-
由 Shawn O. Pearce 提交于
There are some baseless merge cases where git-merge-recursive will try to compare one of the branches against the empty tree. However most projects won't have the empty tree object in their object database as Git does not normally create empty tree objects. If the empty tree object is missing then the merge process will die, as it cannot load the object from the database. The error message may make the user think that their database is corrupt when its actually not. So instead we should just create the empty tree object whenever it is needed. If the object already exists as a loose object then no harm done. Otherwise that loose object will be pruned away later by either git-prune or git-prune-packed. Thanks goes to Junio for suggesting this fix. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Jim Meyering 提交于
git-index-pack can call memcpy with overlapping source and destination buffers. The patch below makes it use memmove instead. If you want to demonstrate a failure, add the following two lines + if (input_offset < input_len) + abort (); before the existing memcpy call (shown in the patch below), and then run this: (cd t; sh ./t5500-fetch-pack.sh) Signed-off-by: NJim Meyering <jim@meyering.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Chris Wright 提交于
No need to install manpages as executable. Noticed by Ville Skytt,Ad(B. Signed-off-by: NChris Wright <chrisw@sous-sol.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 07 12月, 2006 2 次提交
-
-
由 Martin Langhoff 提交于
At some point between v5.6 and 5.8 Perl started to assume its input, output and filehandles are UTF-8. This breaks the counting of bytes for the CVS protocol, resulting in the client expecting less data than we actually send, and storing truncated files. Signed-off-by: NMartin Langhoff <martin@catalyst.net.nz> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
An earlier commit a9cb3c6e changed git-commit to use the contents of MERGE_MSG even when we do not have MERGE_HEAD (the rationale is in its log message). However, the change tricks the following sequence to include a merge message in a completely unrelated commit: $ git pull somewhere : oops, the conflicts are too much. forget it. $ git reset --hard : work work work $ git commit To fix this confusion, this patch makes "git reset" to remove the leftover MERGE_MSG that was prepared when the user abandoned the merge. Signed-off-by: NJunio C Hamano <junkio@cox.net> Acked-by: Luben Tuikov <ltuikov@yahoo.com
-
- 05 12月, 2006 2 次提交
-
-
由 Junio C Hamano 提交于
The structure that ends with a flexible array member (or 0 length array with older GCC) "char name[FLEX_ARRAY]" is allocated on the stack and we use it after clearing its entire size with memset. That does not guarantee that "name" is properly NUL terminated as we intended on platforms with more forgiving structure alignment requirements. Reported breakage on m68k by Roman Zippel. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Especially refs/tags/ hierarchy should match what git-fetch checks. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 04 12月, 2006 1 次提交
-
-
由 Johannes Schindelin 提交于
A move of a directory should find the entries in the index by searching for the name _including_ the slash. Otherwise, the directory can be shadowed by a file when it matches the prefix and is lexicographically smaller, e.g. "ab.c" shadows "ab/". Noticed by Sergey Vlasov. [jc: added Sergey's original reproduction recipe as a test case at the end of t7001.] Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 03 12月, 2006 1 次提交
-
-
由 Eric Wong 提交于
SVN is not entirely consistent in returning log information and sometimes returns file information when adding subdirectories, and sometimes it does not (only returning information about the directory that was added). This caused git-svn to occasionally add a file to the list of files to be fetched twice. Now we change the data structure to be hash to avoid repeated fetches. As of now (in master), this only affects repositories fetched without deltas enabled (file://, and when manually overriden with GIT_SVN_DELTA_FETCH=0); so this bug mainly affects users of 1.4.4.1 and maint. Thanks to Florian Weimer for reporting this bug. [jc: backported for maint] Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 30 11月, 2006 3 次提交
-
-
由 Andy Parkins 提交于
Signed-off-by: NAndy Parkins <andyparkins@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Introducing yourself to git early would be a good idea; otherwise the user may not find the mistake until much later when "git log" is learned. Teaching "commit -a" without saying that it is a shortcut for listing the paths to commit leaves the user puzzled. Teach the form with explicit paths first. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Alex Riesen 提交于
We lacked "--" termination in the underlying init_revisions() call which made it impossible to specify a revision that happens to have the same name as an existing file. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 29 11月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
We used to get the case that more than two paths came from the same commit wrong when computing the output width and deciding to turn on --show-name option automatically. When we find that lines that came from a path that is different from what we started digging from, we should always turn --show-name on, and we should count the name length for all files involved. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 24 11月, 2006 5 次提交
-
-
由 Andy Parkins 提交于
In xemit.c:xdl_emit_diff() a buffer for showing the function name as commentary is allocated; this buffer was 40 characters. This is a bit small; particularly for C++ function names where there is often an identical prefix (like void LongNamespace::LongClassName) on multiple functions, which makes the context the same everywhere. In other words the context is useless. This patch increases that buffer to 80 characters - which may still not be enough, but is better Signed-off-by: NAndy Parkins <andyparkins@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Eric Wong 提交于
Using dcommit could cause the user to lose uncommitted changes during the reset --hard operation, so change it to reset --mixed. If dcommit chooses the rebase path, then git-rebase will already error out when local changes are made. Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Eric Wong 提交于
some SVN repositories have a revision 0 (committed by no author and no date) when created; so when we need to ensure that we check any revision variables are defined, and not just non-zero. Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Eric Wong 提交于
dcommit would unconditionally append "~1" to a commit in order to generate a diff. Now we generate a meaningful error message if we try to generate an impossible diff. Signed-off-by: NEric Wong <normalperson@yhbt.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 René Scharfe 提交于
We can't rely on sizeof(struct zip_*) returning the sum of all struct members. At least on ARM padding is added at the end, as Gerrit Pape reported. This fixes the problem but still lets the compiler do the summing by introducing explicit padding at the end of the structs and then taking its offset as the combined size of the preceding members. As Junio correctly notes, the _end[] marker array's size must be greater than zero for compatibility with compilers other than gcc. The space wasted by the markers can safely be neglected because we only have one instance of each struct, i.e. in sum 3 wasted bytes on i386, and 0 on ARM. :) We still rely on the compiler to not add padding between the struct members, but that's reasonable given that all of them are unsigned char arrays. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 23 11月, 2006 3 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
An earlier commit f28b34a broke symlinks when trust-executable-bit is not set because it incorrectly assumed that everything was a regular file. Reported by Juergen Ruehle. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Chris Riddoch 提交于
Asciidoc-include it into the manuals for programs that use the --pretty command-line option, for consistency among the docs. This describes all the pretty-formats currently listed in the cmit_fmt enum in commit.h, and also briefly describes the presence and format of the 'Merge: ' line in some pretty formats. There's a hedge that limiting your view of history can affect what goes in the Merge: line, and that --abbrev/--no-abbrev do nothing to the 'raw' format. Signed-off-by: NChris Riddoch <chris@syntacticsugar.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 22 11月, 2006 3 次提交
-
-
由 Paolo Ciarrocchi 提交于
Rephrased a sentence in order to make more clear the concept of pull . branch Signed-off-by: NPaolo Ciarrocchi <paolo.ciarrocchi@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Michal Rokos 提交于
This tiny patch makes GIT compile again on HP-UX 11i. [jc: The setlinebuf() is described as unportable to BSD before 4.2; it's not even in POSIX, while setvbuf() is in ISO C.] Signed-off-by: NMichal Rokos <michal.rokos@nextsoft.cz> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Paolo Ciarrocchi 提交于
As discussed on git mailing list let's teach the reader about the possiblity to have automatically signed off the commit running the git-commit -s command Signed-off-by: NPaolo Ciarrocchi <paolo.ciarrocchi@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 20 11月, 2006 2 次提交
-
-
由 Junio C Hamano 提交于
An earlier commit b37a562a added a check to see if the ref points at a valid object (as a part of 'negative ref' support which we currently do not use), but did so only while iterating over both packed and loose refs, and forgot to apply the same check while iterating over the remaining ones. We might want to replace the "if null then omit it" check with "eh --- what business does a 0{40} value have here?" complaint later since we currently do not use negative refs, but that is a separate issue. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This side-ports commit fd19f620 from Cogito, in which I fixed exactly the same bug. Somehow nobody noticed this for a long time in git. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 19 11月, 2006 8 次提交
-
-
由 Petr Baudis 提交于
For one, the documentation invalidly claimed that the paths have to be absolute when that's not the case and in fact there is a very valid reason not to use absolute paths (documented the reason as well). Signed-off-by: NPetr Baudis <pasky@suse.cz> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Petr Baudis 提交于
HEAD was still described as a symlink instead of a symref. Signed-off-by: NPetr Baudis <pasky@suse.cz> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Rene Scharfe 提交于
I copied most of the text from git-status.txt. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Rene Scharfe 提交于
This patch fixes a sparse warning about inaccurate_eof being a "dubious one-bit signed bitfield", makes three more binary variables members of this (now unsigned) bitfield and adds a short comment to indicate the nature of two ternary variables. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Rene Scharfe 提交于
Z_NULL is defined as 0, use a proper NULL pointer in its stead. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Rene Scharfe 提交于
The declaration of discard_cache() in cache.h already has its "void". Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Petr Baudis 提交于
inacurate -> inaccurate, sorry if it was a pun. ;-) Signed-off-by: NPetr Baudis <pasky@suse.cz> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Petr Baudis 提交于
Unfortunately, git-for-each-refs is currently unusable for peeking into tag comments, since it uses freed pointers, so it just prints out all sort of garbage. This makes it strdup() contents and body values. Signed-off-by: NPetr Baudis <pasky@suse.cz> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 17 11月, 2006 2 次提交
-
-
由 Linus Torvalds 提交于
Ok, this is a _really_ stupid case, and I don't think it matters, but hey, we should never SIGSEGV. Steps to reproduce: mkdir duh cd duh git init-db git-fmt-merge-msg < /dev/null will cause a SIGSEGV in cmd_fmt_merge_msg(), because we're doing a strncmp() with a NULL current_branch. And yeah, it's an insane schenario, and no, it doesn't really matter. The only reason I noticed was that a broken version of my "git pull" into an empty directory would cause this. This silly patch just replaces the SIGSEGV with a controlled exit with an error message. Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Linus Torvalds 提交于
We used to complain that we cannot merge anything we fetched with a local branch that does not exist yet. Just treat the case as a natural extension of fast forwarding and make the local branch'es tip point at the same commit we just fetched. After all an empty repository without an initial commit is an ancestor of any commit. [jc: I added a trivial test. We've become sloppy but we should stick to the discipline of covering new behaviour with new tests. ] Signed-off-by: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 16 11月, 2006 4 次提交
-
-
由 Junio C Hamano 提交于
Otherwise OpenBSD header files drop S_ISLNK() definition which is used in an inline defined in cache.h Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Jim Meyering 提交于
Although I converted upstream coreutils to git last month, I just reconverted coreutils once again, as a test, and ended up with a git repository of about 130MB (contrast with my packed git repo of size 52MB). That was because there were a lot of commits (but < 1024) after the final automatic "git-repack -a -d". Running a final git-repack -a -d && git-prune-packed cut the final repository size down to the expected size. So this looks like an easy way to improve git-cvsimport. Just run "git repack ..." at the end if there's more than some reasonable amount of not-packed data. My choice of 1MB is a little arbitrarily. I wouldn't mind missing the minimal repo size by 1MB. At the other end of the spectrum, it's probably not worthwhile to pack everything when the total repository size is less than 1MB. Here's the patch: Signed-off-by: NJim Meyering <jim@meyering.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Alexandre Julliard 提交于
Looks like a repo.or.cz-specific change slipped in. Signed-off-by: NAlexandre Julliard <julliard@winehq.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
It is often wanted on the #git channel that this were to work to recover removed directory: rm -fr Documentation git checkout -- Documentation git checkout HEAD -- Documentation ;# alternatively Now it does. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-