summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-04-27git-remote-testgit: avoid process substitutionLibravatar Johannes Sixt1-6/+7
The implementation of bash on Windows does not offer process substitution. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-25t5801: "VAR=VAL shell_func args" is forbiddenLibravatar Junio C Hamano1-1/+3
It is not a portable expectation that a single-shot environment variable assignment works when calling a shell function, not a command. Set and export the variable before calling "test_must_fail git push" instead. This change would not hurt because this is the last command in the subprocess and the environment will not seep through to later tests without using a single-shot assignment. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17transport-helper: update remote helper namespaceLibravatar Felipe Contreras2-4/+31
When pushing, the remote namespace is updated correctly (e.g. refs/origin/master), but not the remote helper's (e.g. refs/testgit/origin/master), which currently is only updated while fetching. Since the remote namespace is used to tell fast-export which commits to avoid (because they were already imported/exported), it makes sense to have them in sync so they don't get generated twice. If the remote helper was implemented properly, they would be ignored, if not, they probably would end up repeated. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17transport-helper: trivial code shuffleLibravatar Felipe Contreras1-5/+3
Just shuffle the die() part to make it more explicit, and cleanup the code-style. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17transport-helper: warn when refspec is not usedLibravatar Felipe Contreras2-2/+6
For the modes that need it. In the future we should probably error out, instead of providing half-assed support. The reason we want to do this is because if it's not present, the remote helper might be updating refs/heads/*, or refs/remotes/origin/*, directly, and in the process fetch will get confused trying to update refs that are already updated, or older than what they should be. We shouldn't be messing with the rest of git. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17transport-helper: clarify pushing without refspecsLibravatar Felipe Contreras3-7/+8
This has never worked, since it's inception the code simply skips all the refs, essentially telling fast-export to do nothing. Let's at least tell the user what's going on. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17transport-helper: update refspec documentationLibravatar Felipe Contreras1-5/+5
The refspec capability is not only used by 'import', also by 'export', and it's recommended in both. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17transport-helper: clarify *:* refspecLibravatar Felipe Contreras3-18/+3
The *:* refspec doesn't work, and never has, clarify the code and documentation to reflect that. This in effect reverts commit 9e7673e (gitremote-helpers(1): clarify refspec behaviour). Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-11transport-helper: improve push messagesLibravatar Felipe Contreras2-0/+15
If there's already a remote-helper tracking ref, we can fetch the SHA-1 to report proper push messages (as opposed to always reporting [new branch]). The remote-helper currently can specify the old SHA-1 to avoid this problem, but there's no point in forcing all remote-helpers to be aware of git commit ids; they should be able to be agnostic of them. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-11transport-helper: mention helper name when it diesLibravatar Jeff King2-5/+5
When we try to read from a remote-helper and get EOF or an error, we print a message indicating that the helper died. However, users may not know that a remote helper was in use (e.g., when using git-over-http), or even what a remote helper is. Let's print the name of the helper (e.g., "git-remote-https"); this makes it more obvious what the program is for, and provides a useful token for reporting bugs or searching for more information (e.g., in manpages). Signed-off-by: Jeff King <peff@peff.net> Acked-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-11transport-helper: report errors properlyLibravatar Felipe Contreras3-1/+40
If a push fails because the remote-helper died (with fast-export), the user may not see any error message. We do correctly die with a failed exit code, as we notice that the helper has died while reading back the ref status from the helper. However, we don't print any message. This is OK if the helper itself printed a useful error message, but we cannot count on that; let's let the user know that the helper failed. In the long run, it may make more sense to propagate the error back up to push, so that it can present the usual status table and give a nicer message. But this is a much simpler fix that can help immediately. While we're adding tests, let's also confirm that the remote-helper dying is also detected when importing refs. We currently do so robustly when the helper uses the "done" feature (and that is what we test). We cannot do so reliably when the helper does not use the "done" feature, but it is not even worth testing; the right solution is for the helper to start using "done". Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Acked-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07Sync with 1.8.2.1Libravatar Junio C Hamano4-3/+15
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07Git 1.8.2.1Libravatar Junio C Hamano3-2/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07Update draft release notes to 1.8.3Libravatar Junio C Hamano1-0/+20
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07Merge branch 'jk/rm-removed-paths'Libravatar Junio C Hamano3-2/+67
A handful of test cases and a corner case bugfix for "git rm". * jk/rm-removed-paths: t3600: document failure of rm across symbolic links t3600: test behavior of reverse-d/f conflict rm: do not complain about d/f conflicts during deletion
2013-04-07Merge branch 'tb/shared-perm'Libravatar Junio C Hamano2-35/+25
Simplifies adjust_shared_perm() implementation. * tb/shared-perm: path.c: optimize adjust_shared_perm() path.c: simplify adjust_shared_perm()
2013-04-07Merge branch 'cn/commit-amend-doc'Libravatar Junio C Hamano1-8/+9
* cn/commit-amend-doc: Documentation/git-commit: reword the --amend explanation
2013-04-07Merge branch 'fc/remote-helpers-test-updates'Libravatar Junio C Hamano3-16/+2
* fc/remote-helpers-test-updates: remote-hg: fix hg-git test-case remote-bzr: remove stale check code for tests remote-helpers: fix the run of all tests remote-bzr: avoid echo -n
2013-04-07Merge branch 'mg/texinfo-5'Libravatar Junio C Hamano1-0/+1
Strip @anchor elements in the texinfo output of the documentation, as a single document created by concatenating our entire manual set will produce many duplicates that makes newer texinfo unhappy. * mg/texinfo-5: Documentation: Strip texinfo anchors to avoid duplicates
2013-04-07Merge branch 'jk/diffcore-break-divzero'Libravatar Junio C Hamano1-0/+3
* jk/diffcore-break-divzero: diffcore-break: don't divide by zero
2013-04-07Merge branch 'jk/bisect-prn-unsigned'Libravatar Junio C Hamano1-2/+2
* jk/bisect-prn-unsigned: bisect: avoid signed integer overflow
2013-04-07Merge branch 'rr/triangle'Libravatar Junio C Hamano5-149/+241
Support "pull from one place, push to another place" workflow better by introducing remote.pushdefault (overrides the "origin" thing) and branch.*.pushremote (overrides the branch.*.remote). * rr/triangle: remote.c: introduce branch.<name>.pushremote remote.c: introduce remote.pushdefault remote.c: introduce a way to have different remotes for fetch/push t5516 (fetch-push): drop implicit arguments from helper functions t5516 (fetch-push): update test description remote.c: simplify a bit of code using git_config_string()
2013-04-07Merge branch 'mm/status-during-revert'Libravatar Junio C Hamano3-0/+87
"git status" learned to report that you are in the middle of a revert session, just like it does for a cherry-pick and a bisect session. * mm/status-during-revert: status: show commit sha1 in "You are currently reverting" message status: show 'revert' state and status hint
2013-04-07Merge branch 'jk/set-upstream-error-cases'Libravatar Junio C Hamano4-3/+41
The handing by "git branch --set-upstream-to" against various forms of errorneous inputs were suboptimal. * jk/set-upstream-error-cases: branch: give advice when tracking start-point is missing branch: mention start_name in set-upstream error messages branch: improve error message for missing --set-upstream-to ref branch: factor out "upstream is not a branch" error messages t3200: test --set-upstream-to with bogus refs
2013-04-07Merge branch 'jk/filter-branch-come-back-to-original'Libravatar Junio C Hamano2-2/+17
When used with "-d temporary-directory" option, "git filter-branch" failed to come back to the original working tree to perform the final clean-up procedure. * jk/filter-branch-come-back-to-original: filter-branch: return to original dir after filtering
2013-04-07Sync with 1.8.1.6Libravatar Junio C Hamano6-21/+99
2013-04-07Git 1.8.1.6Libravatar Junio C Hamano3-2/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07Merge branch 'jc/directory-attrs-regression-fix' into maint-1.8.1Libravatar Junio C Hamano3-17/+89
A pattern "dir" (without trailing slash) in the attributes file stopped matching a directory "dir" by mistake with an earlier change that wanted to allow pattern "dir/" to also match. * jc/directory-attrs-regression-fix: t: check that a pattern without trailing slash matches a directory dir.c::match_pathname(): pay attention to the length of string parameters dir.c::match_pathname(): adjust patternlen when shifting pattern dir.c::match_basename(): pay attention to the length of string parameters attr.c::path_matches(): special case paths that end with a slash attr.c::path_matches(): the basename is part of the pathname
2013-04-07remote-helpers/test-bzr.sh: do not use "grep '\s'"Libravatar Torsten Bögershausen1-1/+1
Using grep "devel\s\+3:" to find at least one whitspace is not portable on all grep versions; not all grep versions understand "\s" as a "whitespace". Use a literal TAB followed by SPACE. The + as a qualifier for "one or more" is not a basic regular expression; use egrep instead of grep. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07gitremote-helpers(1): clarify refspec behaviourLibravatar John Keeping1-2/+2
The documentation says that "If no 'refspec' capability is advertised, there is an implied `refspec *:*`" but this is only the case for the "import" command. Since there is a comment in transport-helper.c indicating that this default is for historical reasons, change the documentation to clarify that a refspec should always be specified. Signed-off-by: John Keeping <john@keeping.me.uk> Acked-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07fast-export: Allow pruned-references in mark fileLibravatar Antoine Pelisse2-4/+9
fast-export can fail because of some pruned-reference when importing a mark file. The problem happens in the following scenario: $ git fast-export --export-marks=MARKS master (rewrite master) $ git prune $ git fast-export --import-marks=MARKS master This might fail if some references have been removed by prune because some marks will refer to no longer existing commits. git-fast-export will not need these objects anyway as they were no longer reachable. We still need to update last_numid so we don't change the mapping between marks and objects for remote-helpers. Unfortunately, the mark file should not be rewritten without lost marks if no new objects has been exported, as we could lose track of the last last_numid. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07remote-bzr: add utf-8 support for pushingLibravatar Felipe Contreras2-0/+37
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07remote-bzr: add utf-8 support for fetchingLibravatar Timotheus Pokorra2-2/+27
[fc: added tests] Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07remote-bzr: avoid unreferred tagsLibravatar Felipe Contreras1-0/+4
They have no content, there's nothing we can do with them. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07remote-bzr: only update workingtree on local reposLibravatar Felipe Contreras1-2/+1
Apparently, that's the only way it's possible. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07remote-bzr: set author if availableLibravatar David Engster2-1/+21
[fc: added tests] Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07remote-bzr: remove files before modificationsLibravatar Christophe Simonis1-2/+2
Allow re-add of a deleted file in the same commit. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07remote-bzr: fix directory renamingLibravatar Christophe Simonis2-1/+31
Git does not handle directories, renaming a directory is renaming every files in this directory. [fc: added tests] Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-05Update draft release notes to 1.8.3Libravatar Junio C Hamano1-0/+12
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-05Merge branch 'mh/rev-parse-verify-doc'Libravatar Junio C Hamano1-4/+15
"rev-parse --verify" was documented in a misleading way. * mh/rev-parse-verify-doc: rev-parse: clarify documentation for the --verify option
2013-04-05Merge branch 'sg/gpg-sig'Libravatar Junio C Hamano13-82/+219
Teach "merge/pull" to optionally verify and reject commits that are not signed properly. * sg/gpg-sig: pretty printing: extend %G? to include 'N' and 'U' merge/pull Check for untrusted good GPG signatures merge/pull: verify GPG signatures of commits being merged commit.c/GPG signature verification: Also look at the first GPG status line Move commit GPG signature verification to commit.c
2013-04-05Merge branch 'jl/submodule-deinit'Libravatar Junio C Hamano2-7/+20
A finishing touch to the new topic in 1.8.3. * jl/submodule-deinit: submodule deinit: clarify work tree removal message
2013-04-05Merge branch 'rr/send-email-perl-critique'Libravatar Junio C Hamano1-8/+10
Update "git send-email" for issues noticed by PerlCritic. * rr/send-email-perl-critique: send-email: use the three-arg form of open in recipients_cmd send-email: drop misleading function prototype send-email: use "return;" not "return undef;" on error codepaths
2013-04-05Merge branch 'jc/merge-tag-object'Libravatar Junio C Hamano2-32/+81
"git merge $(git rev-parse v1.8.2)" behaved quite differently from "git merge v1.8.2" as if v1.8.2 were written as v1.8.2^0 and did not pay much attention to the annotated tag payload. This makes the code notice the type of the tag object, in addition to the dwim_ref() based classification the current code uses (i.e. the name appears in refs/tags/) to decide when to special case merging of tags. * jc/merge-tag-object: t6200: test message for merging of an annotated tag t6200: use test_config/test_unconfig merge: a random object may not necssarily be a commit
2013-04-05path.c: optimize adjust_shared_perm()Libravatar Torsten Bögershausen1-19/+23
Sometimes the chown() function is called even when not needed (This can be provoked by running t1301, and adding some debug code). Save a chmod from 400 to 400, or from 600 to 600 on these files: .git/info/refs+ .git/objects/info/packs+ Save chmod on directories from 2770 to 2770: .git/refs .git/refs/heads .git/refs/tags Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-05path.c: simplify adjust_shared_perm()Libravatar Torsten Bögershausen2-22/+8
All calls to set_shared_perm() use mode == 0, so simplify the function. Because all callers use the macro adjust_shared_perm(path) from cache.h to call this function, convert it to a proper function, losing set_shared_perm(). Since path.c has much more functions than just mkpath() these days, drop the stale comment about it. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-05Documentation/git-commit: reword the --amend explanationLibravatar Carlos Martín Nieto1-8/+9
The explanation for 'git commit --amend' talks about preparing a tree object, which shouldn't be how user-facing documentation talks about commit. Reword it to say it works as usual, but replaces the current commit. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-04t3600: document failure of rm across symbolic linksLibravatar Jeff King1-0/+28
If we have a symlink "d" that points to a directory, we should not be able to remove "d/f". In the normal case, where "d/f" does not exist in the index, we already disallow this, as we only remove things that git knows about in the index. So for something like: ln -s /outside/repo foo git add foo git rm foo/bar we will properly produce an error (as there is no index entry for foo/bar). However, if there is an index entry for the path (e.g., because the movement is due to working tree changes that have not yet been reflected in the index), we will happily delete it, even though the path we delete from the filesystem is not the same as the path in the index. This patch documents that failure with a test. While this is a bug, it should not be possible to cause serious data loss with it. For any path that does not have an index entry, we will complain and bail. For a path which does have an index entry, we will do the usual up-to-date content check. So even if the deleted path in the filesystem is not the same as the one we are removing from the index, we do know that they at least have the same content, and that the content is included in HEAD. That means the worst case is not the accidental loss of content, but rather confusion by the user when a copy of a file another part of the tree is removed. Which makes this bug a minor and hard-to-trigger annoyance rather than a data-loss bug (and hence the fix can be saved for a rainy day when somebody feels like working on it). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-04Sync with maintLibravatar Junio C Hamano2-1/+2
* maint: mailmap: update Pasky's address git-remote-mediawiki: new wiki URL in documentation
2013-04-04mailmap: update Pasky's addressLibravatar Junio C Hamano1-0/+1
Eric Wong noticed that the address at suse.cz no longer works. We may want to update in-code addresses as well, but let's do this first in 'maint'. Signed-off-by: Junio C Hamano <gitster@pobox.com>