summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-11-04t1005: add test for "read-tree --reset -u A B"Libravatar Junio C Hamano1-0/+15
With a conflicted index, this used to give us an error. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-04t1005: reindentLibravatar Junio C Hamano2-89/+89
Just to update the style of this ancient test script to match our house style. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-04unpack-trees: fix "read-tree -u --reset A B" with conflicted indexLibravatar Jeff King1-8/+17
When we call "read-tree --reset -u HEAD ORIG_HEAD", the first thing we do with the index is to call read_cache_unmerged. Originally that would read the index, leaving aside any unmerged entries. However, as of d1a43f2 (reset --hard/read-tree --reset -u: remove unmerged new paths, 2008-10-15), it actually creates a new cache entry to serve as a placeholder, so that we later know to update the working tree. However, we later noticed that the sha1 of that unmerged entry was just copied from some higher stage, leaving you with random content in the index. That was fixed by e11d7b5 ("reset --merge": fix unmerged case, 2009-12-31), which instead puts the null sha1 into the newly created entry, and sets a CE_CONFLICTED flag. At the same time, it teaches the unpack-trees machinery to pay attention to this flag, so that oneway_merge throws away the current value. However, it did not update the code paths for twoway_merge, which is where we end up in the two-way read-tree with --reset. We notice that the HEAD and ORIG_HEAD versions are the same, and say "oh, we can just reuse the current version". But that's not true. The current version is bogus. Notice this case and make sure we do not keep the bogus entry; either we do not have that path in the tree we are moving to (i.e. remove it), or we want to have the cache entry we created for the tree we are moving to (i.e. resolve by explicitly saying the "newtree" version is what we want). [jc: this is from the almost year-old $gmane/212316] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-29fsck: detect null sha1 in tree entriesLibravatar Jeff King2-1/+33
Short of somebody happening to beat the 1 in 2^160 odds of actually generating content that hashes to the null sha1, we should never see this value in a tree entry. So let's have fsck warn if it it seen. As in the previous commit, we test both blob and submodule entries to future-proof the test suite against the implementation depending on connectivity to notice the error. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-29do not write null sha1s to on-disk indexLibravatar Jeff King2-0/+21
We should never need to write the null sha1 into an index entry (short of the 1 in 2^160 chance that somebody actually has content that hashes to it). If we attempt to do so, it is much more likely that it is a bug, since we use the null sha1 as a sentinel value to mean "not valid". The presence of null sha1s in the index (which can come from, among other things, "update-index --cacheinfo", or by reading a corrupted tree) can cause problems for later readers, because they cannot distinguish the literal null sha1 from its use a sentinel value. For example, "git diff-files" on such an entry would make it appear as if it is stat-dirty, and until recently, the diff code assumed such an entry meant that we should be diffing a working tree file rather than a blob. Ideally, we would stop such entries from entering even our in-core index. However, we do sometimes legitimately add entries with null sha1s in order to represent these sentinel situations; simply forbidding them in add_index_entry breaks a lot of the existing code. However, we can at least make sure that our in-core sentinel representation never makes it to disk. To be thorough, we will test an attempt to add both a blob and a submodule entry. In the former case, we might run into problems anyway because we will be missing the blob object. But in the latter case, we do not enforce connectivity across gitlink entries, making this our only point of enforcement. The current implementation does not care which type of entry we are seeing, but testing both cases helps future-proof the test suite in case that changes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-29diff: do not use null sha1 as a sentinel valueLibravatar Jeff King14-32/+135
The diff code represents paths using the diff_filespec struct. This struct has a sha1 to represent the sha1 of the content at that path, as well as a sha1_valid member which indicates whether its sha1 field is actually useful. If sha1_valid is not true, then the filespec represents a working tree file (e.g., for the no-index case, or for when the index is not up-to-date). The diff_filespec is only used internally, though. At the interfaces to the diff subsystem, callers feed the sha1 directly, and we create a diff_filespec from it. It's at that point that we look at the sha1 and decide whether it is valid or not; callers may pass the null sha1 as a sentinel value to indicate that it is not. We should not typically see the null sha1 coming from any other source (e.g., in the index itself, or from a tree). However, a corrupt tree might have a null sha1, which would cause "diff --patch" to accidentally diff the working tree version of a file instead of treating it as a blob. This patch extends the edges of the diff interface to accept a "sha1_valid" flag whenever we accept a sha1, and to use that flag when creating a filespec. In some cases, this means passing the flag through several layers, making the code change larger than would be desirable. One alternative would be to simply die() upon seeing corrupted trees with null sha1s. However, this fix more directly addresses the problem (while bogus sha1s in a tree are probably a bad thing, it is really the sentinel confusion sending us down the wrong code path that is what makes it devastating). And it means that git is more capable of examining and debugging these corrupted trees. For example, you can still "diff --raw" such a tree to find out when the bogus entry was introduced; you just cannot do a "--patch" diff (just as you could not with any other corrupted tree, as we do not have any content to diff). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26Git 1.7.9.7Libravatar Junio C Hamano3-2/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26Sync with 1.7.8.6Libravatar Junio C Hamano4-3/+40
2012-04-26Git 1.7.8.6Libravatar Junio C Hamano4-3/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26Sync with 1.7.7.7Libravatar Junio C Hamano3-2/+16
2012-04-26Git 1.7.7.7Libravatar Junio C Hamano4-3/+18
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26bundle: remove stray single-quote from error messageLibravatar Jonathan Nieder1-1/+1
After running rev-list --boundary to retrieve the list of boundary commits, "git bundle create" runs its own revision walk. If in this stage git encounters an unfamiliar option, it writes a message with an unbalanced quotation mark: error: unrecognized argument: --foo' Drop the stray quote to match the "unrecognized argument: %s" message used elsewhere and save translators some work. This is mostly a futureproofing measure: for now, the "rev-list --boundary" command catches most strange arguments on its own and the above message is not seen unless you try something esoteric like "git bundle create test.bundle --header HEAD". Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-10Merge branch 'maint-1.7.8' into maint-1.7.9Libravatar Junio C Hamano2-6/+6
* maint-1.7.8: Documentation/gitweb: trivial English fixes fetch/receive: remove over-pessimistic connectivity check
2012-04-09Merge branch 'jc/maint-verify-objects-remove-pessimism' into maint-1.7.8Libravatar Junio C Hamano1-4/+4
* jc/maint-verify-objects-remove-pessimism: fetch/receive: remove over-pessimistic connectivity check
2012-04-09Merge branch 'dw/gitweb-doc-grammo' into maint-1.7.8Libravatar Junio C Hamano1-2/+2
* dw/gitweb-doc-grammo: Documentation/gitweb: trivial English fixes
2012-04-09Merge branch 'tr/cache-tree' into maint-1.7.8Libravatar Junio C Hamano10-11/+142
* tr/cache-tree: t0090: be prepared that 'wc -l' writes leading blanks reset: update cache-tree data when appropriate commit: write cache-tree data when writing index anyway Refactor cache_tree_update idiom from commit Test the current state of the cache-tree optimization Add test-scrap-cache-tree
2012-04-09Merge branch 'cb/maint-t5541-make-server-port-portable' into maint-1.7.8Libravatar Junio C Hamano2-4/+33
* cb/maint-t5541-make-server-port-portable: t5541: check error message against the real port number used remote-curl: Fix push status report when all branches fail
2012-04-09Merge branch 'cn/maint-rev-list-doc' into maint-1.7.8Libravatar Junio C Hamano1-6/+6
* cn/maint-rev-list-doc: Documentation: use {asterisk} in rev-list-options.txt when needed
2012-04-09Merge branch 'tr/maint-bundle-boundary' into maint-1.7.8Libravatar Junio C Hamano2-23/+36
* tr/maint-bundle-boundary: bundle: keep around names passed to add_pending_object() t5510: ensure we stay in the toplevel test dir t5510: refactor bundle->pack conversion
2012-04-09Merge branch 'tr/maint-bundle-long-subject' into maint-1.7.8Libravatar Junio C Hamano5-51/+67
* tr/maint-bundle-long-subject: t5704: match tests to modern style strbuf: improve strbuf_get*line documentation bundle: use a strbuf to scan the log for boundary commits bundle: put strbuf_readline_fd in strbuf.c with adjustments
2012-04-09Merge branch 'ph/rerere-doc' into maint-1.7.8Libravatar Junio C Hamano1-7/+12
* ph/rerere-doc: rerere: Document 'rerere remaining'
2012-04-02Git 1.7.9.6Libravatar Junio C Hamano4-4/+18
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-02Merge branch 'jc/maint-merge-autoedit' into maintLibravatar Junio C Hamano2-3/+40
* jc/maint-merge-autoedit: merge: backport GIT_MERGE_AUTOEDIT support
2012-03-30string-list: document that string_list_insert() inserts unique stringsLibravatar Heiko Voigt1-1/+3
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-26Git 1.7.9.5Libravatar Junio C Hamano4-3/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-26Merge branch 'jn/maint-fast-import-empty-ls' into maintLibravatar Junio C Hamano2-0/+43
* jn/maint-fast-import-empty-ls: fast-import: don't allow 'ls' of path with empty components fast-import: leakfix for 'ls' of dirty trees
2012-03-26Merge branch 'ph/rerere-doc' into maintLibravatar Junio C Hamano1-7/+12
* ph/rerere-doc: rerere: Document 'rerere remaining'
2012-03-26Merge branch 'ms/maint-config-error-at-eol-linecount' into maintLibravatar Junio C Hamano2-4/+40
* ms/maint-config-error-at-eol-linecount: config: report errors at the EOL with correct line number
2012-03-26grep doc: add --break / --heading / -W to synopsisLibravatar Mark Lodato1-0/+2
All of the other options were included in the synopsis, so it makes sense to include these as well. Signed-off-by: Mark Lodato <lodatom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-26Documentation: improve description of GIT_EDITOR and preference orderLibravatar Rodrigo Silva (MestreLion)1-0/+6
Previously GIT_EDITOR was not listed in git(1) "Environment Variables" section, which could be very confusing to users. Include it in "other" subsection along with a link to git-var(1), since that is the page that fully describes all places where editor can be set and also their preference order. Also, git-var(1) did not say that hardcoded fallback 'vi' may have been changed at build time. A user could be puzzled if 'nano' pops up even when none of the mentioned environment vars or config.editor are set. Clarify this. Ideally, the build system should be changed to reflect the chosen fallback editor when creating the man pages. Not sure if that is even possible though. Signed-off-by: Rodrigo Silva (MestreLion) <linux@rodrigosilva.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-26documentation: fix alphabetic ordered list for git-rebase man pageLibravatar Nelson Benitez Leon1-2/+5
An alphabetic ordered list (a.) is converted to numerical in the man page (1.) so context comments naming 'a' were confusing, fix that by not using ordered list notation for 'a' anb 'b' items. Signed-off-by: Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-23Documentation/gitweb: trivial English fixesLibravatar D Waitzman1-2/+2
Change "it's" to "its" where a possessive is intended. Also add two missing "the" that were noticed by Ben Walton. Signed-off-by: David Waitzman <djw@bbn.com>
2012-03-20Merge branch 'maint-1.7.8' into maintLibravatar Junio C Hamano5-16/+34
* maint-1.7.8: t/Makefile: Use $(sort ...) explicitly where needed gitweb: Fix actionless dispatch for non-existent objects i18n of multi-line advice messages
2012-03-20merge: backport GIT_MERGE_AUTOEDIT supportLibravatar Junio C Hamano2-3/+40
Even though 1.7.9.x series does not open the editor by default when merging in general, it does do so in one occassion: when merging an annotated tag. And worse yet, there is no good way for older scripts to decline this. Backport the support for GIT_MERGE_AUTOEDIT environment variable from 1.7.10 track to help those stuck on 1.7.9.x maintenance track. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-20Merge branch 'ks/sort-wildcard-in-makefile' into maint-1.7.8Libravatar Junio C Hamano1-3/+3
* ks/sort-wildcard-in-makefile: t/Makefile: Use $(sort ...) explicitly where needed
2012-03-20Merge branch 'jc/advise-i18n' into maint-1.7.8Libravatar Junio C Hamano2-12/+20
* jc/advise-i18n: i18n of multi-line advice messages
2012-03-20Merge branch 'jn/gitweb-unspecified-action' into maint-1.7.8Libravatar Junio C Hamano2-1/+11
* jn/gitweb-unspecified-action: gitweb: Fix actionless dispatch for non-existent objects
2012-03-15fetch/receive: remove over-pessimistic connectivity checkLibravatar Junio C Hamano1-4/+4
Git 1.7.8 introduced an object and history re-validation step after "fetch" or "push" causes new history to be added to a receiving repository. This is to protect a malicious server or pushing client from corrupting the repository by taking advantage of an existing corrupt object that is unconnected to existing history. But this check is way over-pessimistic. During "fetch" or "receive-pack" (the server side of "push"), unpack-objects and index-pack already validate individual objects that are received, and the only thing we would want to catch are corrupted objects that already happen to exist in our repository but are not referenced from our refs. Such objects must have been written by an earlier run of our codepaths that write out loose objects or packfiles, and they must have done the validation of individual objects when they did so. The only thing left to worry about is the connectivity integrity, which can be checked with "rev-list --objects", which is much cheaper. We have been paying the 5x to 8x runtime overhead the --verify-objects often adds for no real gain. Revert check_everything_connected() not to use this over-pessimistic check. Credit goes to Nguyễn Thái Ngọc Duy, who originally identified the performance regression and endured multiple rounds of reviews to fix it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-12Git 1.7.9.4Libravatar Junio C Hamano4-3/+28
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-12Merge branch 'tr/maint-bundle-boundary' into maintLibravatar Junio C Hamano2-23/+36
"git bundle" did not record boundary commits correctly when there are many of them. By Thomas Rast * tr/maint-bundle-boundary: bundle: keep around names passed to add_pending_object() t5510: ensure we stay in the toplevel test dir t5510: refactor bundle->pack conversion
2012-03-12Merge branch 'jc/maint-diff-patch-header' into maintLibravatar Junio C Hamano2-86/+111
"git diff-index" and its friends at the plumbing level showed the "diff --git" header and nothing else for a path whose cached stat info is dirty without actual difference when asked to produce a patch. This was a longstanding bug that we could have fixed long time ago. By Junio C Hamano * jc/maint-diff-patch-header: diff -p: squelch "diff --git" header for stat-dirty paths t4011: illustrate "diff-index -p" on stat-dirty paths t4011: modernise style
2012-03-12Merge branch 'jn/maint-do-not-match-with-unsanitized-searchtext' into maintLibravatar Junio C Hamano1-8/+8
"gitweb" did use quotemeta() to prepare search string when asked to do a fixed-string project search, but did not use it by mistake and used the user-supplied string instead. By Jakub Narebski * jn/maint-do-not-match-with-unsanitized-searchtext: gitweb: Fix fixed string (non-regexp) project search
2012-03-12Merge branch 'jc/am-3-nonstandard-popt' into maintLibravatar Junio C Hamano2-4/+22
The code to synthesize the fake ancestor tree used by 3-way merge fallback in "git am" was not prepared to read a patch created with a non-standard -p<num> value. * jc/am-3-nonstandard-popt: test: "am -3" can accept non-standard -p<num> am -3: allow nonstandard -p<num> option
2012-03-12config: report errors at the EOL with correct line numberLibravatar Martin Stenberg2-4/+40
A section in a config file with a missing "]" reports the next line as bad, same goes to a value with a missing end quote. This happens because the error is not detected until the end of the line, when line number is already increased. Fix this by decreasing line number by one for these cases. Signed-off-by: Martin Stenberg <martin@gnutiken.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-09fast-import: don't allow 'ls' of path with empty componentsLibravatar Jonathan Nieder2-0/+41
As the fast-import manual explains: The value of <path> must be in canonical form. That is it must not: . contain an empty directory component (e.g. foo//bar is invalid), . end with a directory separator (e.g. foo/ is invalid), . start with a directory separator (e.g. /foo is invalid), Unfortunately the "ls" command accepts these invalid syntaxes and responds by declaring that the indicated path is missing. This is too subtle and causes importers to silently misbehave; better to error out so the operator knows what's happening. The C, R, and M commands already error out for such paths. Reported-by: Andrew Sayers <andrew-git@pileofstuff.org> Analysis-by: David Barr <davidbarr@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2012-03-09fast-import: leakfix for 'ls' of dirty treesLibravatar Jonathan Nieder1-0/+2
When the chosen directory has changed since it was last written to pack, "tree_content_get" makes a deep copy of its content to scribble on while computing the tree name, which we forgot to free. This leak has been present since the 'ls' command was introduced in v1.7.5-rc0~3^2~33 (fast-import: add 'ls' command, 2010-12-02). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2012-03-08rerere: Document 'rerere remaining'Libravatar Phil Hord1-7/+12
This adds the 'remaining' command to the documentation of 'git rerere'. This command was added in ac49f5ca (Feb 16 2011; Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>) but it was never documented. Touch up the other rerere commands to reduce noise. First noticed by Vincent van Ravesteijn. Signed-off-by: Phil Hord <phil.hord@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-06gitweb: Fix fixed string (non-regexp) project searchLibravatar Jakub Narebski1-8/+8
Use $search_regexp, where regex metacharacters are quoted, for searching projects list, rather than $searchtext, which contains original search term. Reported-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-06t5704: fix nonportable sed/grep usagesLibravatar Thomas Rast1-2/+2
OS X's sed and grep would complain with (respectively) sed: 1: "/^-/{p;q}": extra characters at the end of q command grep: Regular expression too big For sed, use an explicit ; to terminate the q command. For grep, spell the "40 hex digits" explicitly in the regex, which should be safe as other tests already use this and we haven't got breakage reports on OS X about them. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-06Merge branch 'maint-1.7.8' into maintLibravatar Junio C Hamano1-0/+3
By Thomas Rast * maint-1.7.8: Document the --histogram diff option