summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-02-16Merge branch 'jc/maint-commit-ignore-i-t-a' into maintLibravatar Junio C Hamano2-6/+8
* jc/maint-commit-ignore-i-t-a: commit: ignore intent-to-add entries instead of refusing Conflicts: cache-tree.c
2012-02-16Merge branch 'mm/empty-loose-error-message' into maintLibravatar Junio C Hamano1-0/+5
* mm/empty-loose-error-message: fsck: give accurate error message on empty loose object files
2012-02-16Merge branch 'nk/ctype-for-perf' into maintLibravatar Junio C Hamano2-1/+16
* nk/ctype-for-perf: ctype: implement islower/isupper macro ctype.c only wants git-compat-util.h
2012-02-16Merge branch 'jx/i18n-more-marking' into maintLibravatar Junio C Hamano2-14/+24
* jx/i18n-more-marking: i18n: format_tracking_info "Your branch is behind" message i18n: git-commit whence_s "merge/cherry-pick" message
2012-02-16man: rearrange git synopsis to fit in 80 linesLibravatar Zbigniew Jędrzejewski-Szmek1-3/+3
The line was extended in 2dd8c3 ('git: add --info-path and --man-path options'), and the formatted man output stopped fitting into the 80 column window. Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-16completion: --list option for git-branchLibravatar Ralf Thielow1-1/+1
Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-16Merge branch 'rt/completion-branch-edit-desc' into maintLibravatar Junio C Hamano1-1/+1
* rt/completion-branch-edit-desc: completion: --edit-description option for git-branch
2012-02-14Git 1.7.9.1Libravatar Junio C Hamano3-2/+14
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-13Merge branch 'jk/maint-tag-show-fixes' into maintLibravatar Junio C Hamano2-32/+53
* jk/maint-tag-show-fixes: tag: do not show non-tag contents with "-n" tag: die when listing missing or corrupt objects tag: fix output of "tag -n" when errors occur Conflicts: t/t7004-tag.sh
2012-02-13Merge branch 'bw/inet-pton-ntop-compat' into maintLibravatar Junio C Hamano2-12/+0
* bw/inet-pton-ntop-compat: Drop system includes from inet_pton/inet_ntop compatibility wrappers
2012-02-13Merge branch 'mp/make-cleanse-x-for-exe' into maintLibravatar Junio C Hamano1-0/+3
* mp/make-cleanse-x-for-exe: Explicitly set X to avoid potential build breakage
2012-02-13Merge branch 'jn/merge-no-edit-fix' into maintLibravatar Junio C Hamano2-3/+19
* jn/merge-no-edit-fix: merge: do not launch an editor on "--no-edit $tag"
2012-02-13Update draft release notes to 1.7.9.1Libravatar Junio C Hamano1-3/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-13Merge branch 'js/add-e-submodule-fix' into maintLibravatar Junio C Hamano1-0/+1
* js/add-e-submodule-fix: add -e: do not show difference in a submodule that is merely dirty
2012-02-13Merge branch 'jc/parse-date-raw' into maintLibravatar Junio C Hamano4-1/+60
* jc/parse-date-raw: parse_date(): '@' prefix forces git-timestamp parse_date(): allow ancient git-timestamp
2012-02-13Merge branch 'jc/merge-ff-only-stronger-than-signed-merge' into maintLibravatar Junio C Hamano2-1/+15
* jc/merge-ff-only-stronger-than-signed-merge: merge: do not create a signed tag merge under --ff-only option
2012-02-13Merge branch 'jc/branch-desc-typoavoidance' into maintLibravatar Junio C Hamano3-4/+61
* jc/branch-desc-typoavoidance: branch --edit-description: protect against mistyped branch name tests: add write_script helper function
2012-02-13Merge branch 'jn/rpm-spec' into maintLibravatar Junio C Hamano1-0/+1
* jn/rpm-spec: git.spec: Workaround localized messages not put in any RPM
2012-02-13t: use sane_unset instead of unsetLibravatar Ævar Arnfjörð Bjarmason6-10/+10
Change several tests to use the sane_unset function introduced in v1.7.3.1-35-g00648ba instead of the built-in unset function. This fixes a failure I was having on t9130-git-svn-authors-file.sh on Solaris, and prevents several other issues from occurring. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-13Remove Git's support for smoke testingLibravatar Ævar Arnfjörð Bjarmason3-133/+1
I'm no longer running the Git smoke testing service at smoke.git.nix.is due to Smolder being a fragile piece of software not having time to follow through on making it easy for third parties to run and submit their own smoke tests. So remove the support in Git for sending smoke tests to smoke.git.nix.is, it's still easy to modify the test suite to submit smokes somewhere else. This reverts the following commits: Revert "t/README: Add SMOKE_{COMMENT,TAGS}= to smoke_report target" -- e38efac87d Revert "t/README: Document the Smoke testing" -- d15e9ebc5c Revert "t/Makefile: Create test-results dir for smoke target" -- 617344d77b Revert "tests: Infrastructure for Git smoke testing" -- b6b84d1b74 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-13Makefile: Change the default compiler from "gcc" to "cc"Libravatar Ævar Arnfjörð Bjarmason1-1/+1
Ever since the very first commit to git.git we've been setting CC to "gcc". Presumably this is behavior that Linus copied from the Linux Makefile. However unlike Linux Git is written in ANSI C and supports a multitude of compilers, including Clang, Sun Studio, xlc etc. On my Linux box "cc" is a symlink to clang, and on a Solaris box I have access to "cc" is Sun Studio's CC. Both of these are perfectly capable of compiling Git, and it's annoying to have to specify CC=cc on the command-line when compiling Git when that's the default behavior of most other portable programs. So change the default to "cc". Users who want to compile with GCC can still add "CC=gcc" to the make(1) command-line, but those users who don't have GCC as their "cc" will see expected behavior, and as a bonus we'll be more likely to smoke out new compilation warnings from our distributors since they'll me using a more varied set of compilers by default. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-10Update draft release notes to 1.7.9.1Libravatar Junio C Hamano1-0/+17
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-10Merge branch 'jc/maint-request-pull-for-tag' into maintLibravatar Junio C Hamano3-8/+4
* jc/maint-request-pull-for-tag: request-pull: explicitly ask tags/$name to be pulled
2012-02-10Merge branch 'tr/grep-l-with-decoration' into maintLibravatar Junio C Hamano2-2/+25
* tr/grep-l-with-decoration: grep: fix -l/-L interaction with decoration lines
2012-02-10Merge branch 'jl/submodule-re-add' into maintLibravatar Junio C Hamano2-0/+9
* jl/submodule-re-add: submodule add: fix breakage when re-adding a deep submodule
2012-02-10Merge branch 'da/maint-mergetool-twoway' into maintLibravatar Junio C Hamano2-5/+35
* da/maint-mergetool-twoway: mergetool: Provide an empty file when needed
2012-02-10ctype: implement islower/isupper macroLibravatar Namhyung Kim1-0/+15
"perf" uses a the forked copy of this file, and wants to use these two macros. Signed-off-by: Namhyung Kim <namhyung.kim@lge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-10ctype.c only wants git-compat-util.hLibravatar Namhyung Kim1-1/+1
The implementation of sane ctype macros only depends on symbols in git-compat-util.h not cache.h Signed-off-by: Namhyung Kim <namhyung.kim@lge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-09Explicitly set X to avoid potential build breakageLibravatar Michael Palimaka1-0/+3
$X is appended to binary names for Windows builds (ie. git.exe). Pollution from the environment can inadvertently trigger this behaviour, resulting in 'git' turning into 'gitwhatever' without warning. Signed-off-by: Michael Palimaka <kensington@astralcloak.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-09merge: do not launch an editor on "--no-edit $tag"Libravatar Junio C Hamano2-3/+19
When the user explicitly asked us not to, don't launch an editor. But do everything else the same way as the "edit" case, i.e. leave the comment with verification result in the log template and record the mergesig in the resulting merge commit for later inspection. Based on initiail analysis by Jonathan Nieder. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-08tag: do not show non-tag contents with "-n"Libravatar Junio C Hamano2-10/+25
"git tag -n" did not check the type of the object it is reading the top n lines from. At least, avoid showing the beginning of trees and blobs when dealing with lightweight tags that point at them. As the payload of a tag and a commit look similar in that they both start with a header block, which is skipped for the purpose of "-n" output, followed by human readable text, allow the message of commit objects to be shown just like the contents of tag objects. This avoids regression for people who have been using "tag -n" to show the log messages of commits that are pointed at by lightweight tags. Test script is from Jeff King. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-07commit: ignore intent-to-add entries instead of refusingLibravatar Junio C Hamano2-6/+8
Originally, "git add -N" was introduced to help users from forgetting to add new files to the index before they ran "git commit -a". As an attempt to help them further so that they do not forget to say "-a", "git commit" to commit the index as-is was taught to error out, reminding the user that they may have forgotten to add the final contents of the paths before running the command. This turned out to be a false "safety" that is useless. If the user made changes to already tracked paths and paths added with "git add -N", and then ran "git add" to register the final contents of the paths added with "git add -N", "git commit" will happily create a commit out of the index, without including the local changes made to the already tracked paths. It was not a useful "safety" measure to prevent "forgetful" mistakes from happening. It turns out that this behaviour is not just a useless false "safety", but actively hurts use cases of "git add -N" that were discovered later and have become popular, namely, to tell Git to be aware of these paths added by "git add -N", so that commands like "git status" and "git diff" would include them in their output, even though the user is not interested in including them in the next commit they are going to make. Fix this ancient UI mistake, and instead make a commit from the index ignoring the paths added by "git add -N" without adding real contents. Based on the work by Nguyễn Thái Ngọc Duy, and helped by injection of sanity from Jonathan Nieder and others on the Git mailing list. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-07add -e: do not show difference in a submodule that is merely dirtyLibravatar Johannes Schindelin1-0/+1
When the HEAD of the submodule matches what is recorded in the index of the superproject, and it has local changes or untracked files, the patch offered by "git add -e" for editing shows a diff like this: diff --git a/submodule b/submodule <header> -deadbeef... +deadbeef...-dirty Because applying such a patch has no effect to the index, this is a useless noise. Generate the patch with IGNORE_DIRTY_SUBMODULES flag to prevent such a change from getting reported. This patch also loses the "-dirty" suffix from the output when the HEAD of the submodule is different from what is in the index of the superproject. As such dirtiness expressed by the suffix does not affect the result of the patch application at all, there is no information lost if we remove it. The user could still run "git status" before "git add -e" if s/he cares about the dirtiness. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-06fsck: give accurate error message on empty loose object filesLibravatar Matthieu Moy1-0/+5
Since 3ba7a065527a (A loose object is not corrupt if it cannot be read due to EMFILE), "git fsck" on a repository with an empty loose object file complains with the error message fatal: failed to read object <sha1>: Invalid argument This comes from a failure of mmap on this empty file, which sets errno to EINVAL. Instead of calling xmmap on empty file, we display a clean error message ourselves, and return a NULL pointer. The new message is error: object file .git/objects/09/<rest-of-sha1> is empty fatal: loose object <sha1> (stored in .git/objects/09/<rest-of-sha1>) is corrupt The second line was already there before the regression in 3ba7a065527a, and the first is an additional message, that should help diagnosing the problem for the user. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-06tag: die when listing missing or corrupt objectsLibravatar Jeff King1-1/+5
We don't usually bother looking at tagged objects at all when listing. However, if "-n" is specified, we open the objects to read the annotations of the tags. If we fail to read an object, or if the object has zero length, we simply silently return. The first case is an indication of a broken or corrupt repo, and we should notify the user of the error. The second case is OK to silently ignore; however, the existing code leaked the buffer returned by read_sha1_file. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-06tag: fix output of "tag -n" when errors occurLibravatar Jeff King1-32/+34
When "git tag" is instructed to print lines from annotated tags via "-n", it first prints the tag name, then attempts to parse and print the lines of the tag object, and then finally adds a trailing newline. If an error occurs, we return early from the function and never print the newline, screwing up the output for the next tag. Let's factor the line-printing into its own function so we can manage the early returns better, and make sure that we always terminate the line. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-06Prepare for 1.7.9.1Libravatar Junio C Hamano2-1/+20
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-06completion: --edit and --no-edit for git-mergeLibravatar Adrian Weimann1-1/+1
Signed-off-by: Adrian Weimann <adrian.weimann@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-05Merge branch 'sp/smart-http-failure-to-push' into maintLibravatar Junio C Hamano2-4/+33
* sp/smart-http-failure-to-push: remote-curl: Fix push status report when all branches fail
2012-02-05Merge branch 'jc/maint-log-first-parent-pathspec' into maintLibravatar Junio C Hamano2-1/+10
* jc/maint-log-first-parent-pathspec: Making pathspec limited log play nicer with --first-parent
2012-02-05Merge branch 'cb/push-quiet' into maintLibravatar Junio C Hamano8-19/+78
* cb/push-quiet: t5541: avoid TAP test miscounting fix push --quiet: add 'quiet' capability to receive-pack server_supports(): parse feature list more carefully
2012-02-05Merge branch 'cb/maint-kill-subprocess-upon-signal' into maintLibravatar Junio C Hamano3-1/+72
* cb/maint-kill-subprocess-upon-signal: dashed externals: kill children on exit run-command: optionally kill children on exit
2012-02-05Sync with 1.7.6.6Libravatar Junio C Hamano2-24/+2
* maint-1.7.8: Git 1.7.6.6 imap-send: remove dead code
2012-02-05Sync with 1.7.6.6Libravatar Junio C Hamano2-24/+2
* maint-1.7.7: Git 1.7.6.6 imap-send: remove dead code
2012-02-05Sync with 1.7.6.6Libravatar Junio C Hamano2-24/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-05Git 1.7.6.6Libravatar Junio C Hamano2-2/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-05imap-send: remove dead codeLibravatar Jeff King1-23/+0
The imap-send code was adapted from another project, and still contains many unused bits of code. One of these bits contains a type "struct string_list" which bears no resemblence to the "struct string_list" we use elsewhere in git. This causes the compiler to complain if git's string_list ever becomes part of cache.h. Let's just drop the dead code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-05branch --edit-description: protect against mistyped branch nameLibravatar Junio C Hamano2-4/+52
It is very easy to mistype the branch name when editing its description, e.g. $ git checkout -b my-topic master : work work work : now we are at a good point to switch working something else $ git checkout master : ah, let's write it down before we forget what we were doing $ git branch --edit-description my-tpoic The command does not notice that branch 'my-tpoic' does not exist. It is not lost (it becomes description of an unborn my-tpoic branch), but is not very useful. So detect such a case and error out to reduce the grief factor from this common mistake. This incidentally also errors out --edit-description when the HEAD points at an unborn branch (immediately after "init", or "checkout --orphan"), because at that point, you do not even have any commit that is part of your history and there is no point in describing how this particular branch is different from the branch it forked off of, which is the useful bit of information the branch description is designed to capture. We may want to special case the unborn case later, but that is outside the scope of this patch to prevent more common mistakes before 1.7.9 series gains too much widespread use. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-05Drop system includes from inet_pton/inet_ntop compatibility wrappersLibravatar Ben Walton2-12/+0
As both of these compatibility wrappers include git-compat-utils.h, all of the system includes were redundant. Dropping these system includes also makes git-compat-utils.h the first include which avoids a compiler warning on Solaris due to the redefinition of _FILE_OFFSET_BITS. Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-05merge: do not create a signed tag merge under --ff-only optionLibravatar Junio C Hamano2-1/+15
Starting at release v1.7.9, if you ask to merge a signed tag, "git merge" always creates a merge commit, even when the tag points at a commit that happens to be a descendant of your current commit. Unfortunately, this interacts rather badly for people who use --ff-only to make sure that their branch is free of local developments. It used to be possible to say: $ git checkout -b frotz v1.7.9~30 $ git merge --ff-only v1.7.9 and expect that the resulting tip of frotz branch matches v1.7.9^0 (aka the commit tagged as v1.7.9), but this fails with the updated Git with: fatal: Not possible to fast-forward, aborting. because a merge that merges v1.7.9 tag to v1.7.9~30 cannot be created by fast forwarding. We could teach users that now they have to do $ git merge --ff-only v1.7.9^0 but it is far more pleasant for users if we DWIMmed this ourselves. When an integrator pulls in a topic from a lieutenant via a signed tag, even when the work done by the lieutenant happens to fast-forward, the integrator wants to have a merge record, so the integrator will not be asking for --ff-only when running "git pull" in such a case. Therefore, this change should not regress the support for the use case v1.7.9 wanted to add. Signed-off-by: Junio C Hamano <gitster@pobox.com>