summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2012-01-18Merge branch 'maint-1.7.7' into maintLibravatar Junio C Hamano1-0/+8
* maint-1.7.7: Git 1.7.7.6 diff-index: enable recursive pathspec matching in unpack_trees Conflicts: GIT-VERSION-GEN
2012-01-18diff-index: enable recursive pathspec matching in unpack_treesLibravatar Nguyen Thai Ngoc Duy1-0/+8
The pathspec structure has a few bits of data to drive various operation modes after we unified the pathspec matching logic in various codepaths. For example, max_depth field is there so that "git grep" can limit the output for files found in limited depth of tree traversal. Also in order to show just the surface level differences in "git diff-tree", recursive field stops us from descending into deeper level of the tree structure when it is set to false, and this also affects pathspec matching when we have wildcards in the pathspec. The diff-index has always wanted the recursive behaviour, and wanted to match pathspecs without any depth limit. But we forgot to do so when we updated tree_entry_interesting() logic to unify the pathspec matching logic. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-11Merge branch 'maint-1.7.7' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.7.7: attr: fix leak in free_attr_elem t2203: fix wrong commit command
2012-01-11Merge branch 'maint-1.7.6' into maint-1.7.7Libravatar Junio C Hamano1-1/+1
* maint-1.7.6: attr: fix leak in free_attr_elem t2203: fix wrong commit command
2012-01-11t2203: fix wrong commit commandLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Add commit message to avoid commit's aborting due to the lack of commit message, not because there are INTENT_TO_ADD entries in index. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-10Merge the attributes fix in from maint-1.6.7 branchLibravatar Junio C Hamano1-0/+10
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-10Merge the attributes fix in from maint-1.6.6 branchLibravatar Junio C Hamano1-0/+10
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-10attr: don't confuse prefixes with leading directoriesLibravatar Jeff King1-0/+10
When we prepare the attribute stack for a lookup on a path, we start with the cached stack from the previous lookup (because it is common to do several lookups in the same directory hierarchy). So the first thing we must do in preparing the stack is to pop any entries that point to directories we are no longer interested in. For example, if our stack contains gitattributes for: foo/bar/baz foo/bar foo but we want to do a lookup in "foo/bar/bleep", then we want to pop the top element, but retain the others. To do this we walk down the stack from the top, popping elements that do not match our lookup directory. However, the test do this simply checked strncmp, meaning we would mistake "foo/bar/baz" as a leading directory of "foo/bar/baz_plus". We must also check that the character after our match is '/', meaning we matched the whole path component. There are two special cases to consider: 1. The top of our attr stack has the empty path. So we must not check for '/', but rather special-case the empty path, which always matches. 2. Typically when matching paths in this way, you would also need to check for a full string match (i.e., the character after is '\0'). We don't need to do so in this case, though, because our path string is actually just the directory component of the path to a file (i.e., we know that it terminates with "/", because the filename comes after that). Helped-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-04t5550: repack everything into one fileLibravatar Clemens Buchacher1-2/+1
Subsequently we assume that there is only one pack. Currently this is true only by accident. Pass '-a -d' to repack in order to guarantee that assumption to hold true. The prune-packed command is now redundant since repack -d already calls it. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-03fix hang in git fetch if pointed at a 0 length bundleLibravatar Brian Harring1-0/+6
git-repo if interupted at the exact wrong time will generate zero length bundles- literal empty files. git-repo is wrong here, but git fetch shouldn't effectively spin loop if pointed at a zero length bundle. Signed-off-by: Brian Harring <ferringb@chromium.org> Helped-by: Johannes Sixt Helped-by: Nguyen Thai Ngoc Duy Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-28Merge branch 'jc/checkout-m-twoway' into maintLibravatar Junio C Hamano1-0/+49
* jc/checkout-m-twoway: t/t2023-checkout-m.sh: fix use of test_must_fail checkout_merged(): squelch false warning from some gcc Test 'checkout -m -- path' checkout -m: no need to insist on having all 3 stages
2011-12-28Merge branch 'jk/http-push-to-empty' into maintLibravatar Junio C Hamano1-0/+32
* jk/http-push-to-empty: remote-curl: don't pass back fake refs Conflicts: remote-curl.c
2011-12-28Merge branch 'jn/maint-sequencer-fixes' into maintLibravatar Junio C Hamano2-58/+156
* jn/maint-sequencer-fixes: revert: stop creating and removing sequencer-old directory Revert "reset: Make reset remove the sequencer state" revert: do not remove state until sequence is finished revert: allow single-pick in the middle of cherry-pick sequence revert: pass around rev-list args in already-parsed form revert: allow cherry-pick --continue to commit before resuming revert: give --continue handling its own function
2011-12-28Merge branch 'jk/maint-push-over-dav' into maintLibravatar Junio C Hamano2-0/+37
* jk/maint-push-over-dav: http-push: enable "proactive auth" t5540: test DAV push with authentication
2011-12-28Merge branch 'jk/fetch-no-tail-match-refs' into maintLibravatar Junio C Hamano2-3/+32
* jk/fetch-no-tail-match-refs: connect.c: drop path_match function fetch-pack: match refs exactly t5500: give fully-qualified refs to fetch-pack drop "match" parameter from get_remote_heads
2011-12-28Merge branch 'jh/fast-import-notes' into maintLibravatar Junio C Hamano1-5/+58
* jh/fast-import-notes: fast-import: Fix incorrect fanout level when modifying existing notes refs t9301: Add 2nd testcase exposing bugs in fast-import's notes fanout handling t9301: Fix testcase covering up a bug in fast-import's notes fanout handling
2011-12-28Merge branch 'jn/branch-move-to-self' into maintLibravatar Junio C Hamano2-4/+21
* jn/branch-move-to-self: Allow checkout -B <current-branch> to update the current branch branch: allow a no-op "branch -M <current-branch> HEAD"
2011-12-21Merge branch 'bc/maint-apply-check-no-patch' into maintLibravatar Junio C Hamano2-1/+20
* bc/maint-apply-check-no-patch: builtin/apply.c: report error on failure to recognize input t/t4131-apply-fake-ancestor.sh: fix broken test
2011-12-21Merge branch 'jk/maint-upload-archive' into maintLibravatar Junio C Hamano1-0/+8
* jk/maint-upload-archive: archive: don't let remote clients get unreachable commits
2011-12-20t/t2023-checkout-m.sh: fix use of test_must_failLibravatar Ævar Arnfjörð Bjarmason1-1/+3
Change an invocation of test_must_fail() to be inside a test_expect_success() as is our usual pattern. Having it outside caused our tests to fail under prove(1) since we wouldn't print a newline before TAP output: CONFLICT (content): Merge conflict in both.txt # GETTEXT POISON #ok 2 - -m restores 2-way conflicted+resolved file Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-19remote-curl: don't pass back fake refsLibravatar Jeff King1-0/+32
When receive-pack advertises its list of refs, it generally hides the capabilities information after a NUL at the end of the first ref. However, when we have an empty repository, there are no refs, and therefore receive-pack writes a fake ref "capabilities^{}" with the capabilities afterwards. On the client side, git reads the result with get_remote_heads(). We pick the capabilities from the end of the line, and then call check_ref() to make sure the ref name is valid. We see that it isn't, and don't bother adding it to our list of refs. However, the call to check_ref() is enabled by passing the REF_NORMAL flag to get_remote_heads. For the regular git transport, we pass REF_NORMAL in get_refs_via_connect() if we are doing a push (since only receive-pack uses this fake ref). But in remote-curl, we never use this flag, and we accept the fake ref as a real one, passing it back from the helper to the parent git-push. Most of the time this bug goes unnoticed, as the fake ref won't match our refspecs. However, if "--mirror" is used, then we see it as remote cruft to be pruned, and try to pass along a deletion refspec for it. Of course this refspec has bogus syntax (because of the ^{}), and the helper complains, aborting the push. Let's have remote-curl mirror what the builtin get_refs_via_connect() does (at least for the case of using git protocol; we can leave the dumb info/refs reader as it is). This also fixes pushing with --mirror to a smart-http remote that uses alternates. The fake ".have" refs the server gives to avoid unnecessary network transfer has a similar bad interactions with the machinery. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13http-push: enable "proactive auth"Libravatar Jeff King1-1/+1
Before commit 986bbc08, git was proactive about asking for http passwords. It assumed that if you had a username in your URL, you would also want a password, and asked for it before making any http requests. However, this could interfere with the use of .netrc (see 986bbc08 for details). And it was also unnecessary, since the http fetching code had learned to recognize an HTTP 401 and prompt the user then. Furthermore, the proactive prompt could interfere with the usage of .netrc (see 986bbc08 for details). Unfortunately, the http push-over-DAV code never learned to recognize HTTP 401, and so was broken by this change. This patch does a quick fix of re-enabling the "proactive auth" strategy only for http-push, leaving the dumb http fetch and smart-http as-is. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13t5540: test DAV push with authenticationLibravatar Jeff King2-0/+37
We don't currently test this case at all, and instead just test the DAV mechanism over an unauthenticated push. That isn't very realistic, as most people will want to authenticate pushes. Two of the tests expect_failure as they reveal bugs: 1. Pushing without a username in the URL fails to ask for credentials when we get an HTTP 401. This has always been the case, but it would be nice if it worked like smart-http. 2. Pushing with a username fails to ask for the password since 986bbc0 (http: don't always prompt for password, 2011-11-04). This is a severe regression in v1.7.8, as authenticated push-over-DAV is now totally unusable unless you have credentials in your .netrc. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13fetch-pack: match refs exactlyLibravatar Jeff King1-0/+29
When we are determining the list of refs to fetch via fetch-pack, we have two sets of refs to compare: those on the remote side, and a "match" list of things we want to fetch. We iterate through the remote refs alphabetically, seeing if each one is wanted by the "match" list. Since def88e9 (Commit first cut at "git-fetch-pack", 2005-07-04), we have used the "path_match" function to do a suffix match, where a remote ref is considered wanted if any of the "match" elements is a suffix of the remote refname. This enables callers of fetch-pack to specify unqualified refs and have them matched up with remote refs (e.g., ask for "A" and get remote's "refs/heads/A"). However, if you provide a fully qualified ref, then there are corner cases where we provide the wrong answer. For example, given a remote with two refs: refs/foo/refs/heads/master refs/heads/master asking for "refs/heads/master" will first match "refs/foo/refs/heads/master" by the suffix rule, and we will erroneously fetch it instead of refs/heads/master. As it turns out, all callers of fetch_pack do provide fully-qualified refs for the match list. There are two ways fetch_pack can get match lists: 1. Through the transport code (i.e., via git-fetch) 2. On the command-line of git-fetch-pack In the first case, we will always be providing the names of fully-qualified refs from "struct ref" objects. We will have pre-matched those ref objects already (since we have to handle more advanced matching, like wildcard refspecs), and are just providing a list of the refs whose objects we need. In the second case, users could in theory be providing non-qualified refs on the command-line. However, the fetch-pack documentation claims that refs should be fully qualified (and has always done so since it was written in 2005). Let's change this path_match call to simply check for string equality, matching what the callers of fetch_pack are expecting. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13t5500: give fully-qualified refs to fetch-packLibravatar Jeff King1-3/+3
The fetch-pack documentation is very clear that refs given on the command line are to be full refs: <refs>...:: The remote heads to update from. This is relative to $GIT_DIR (e.g. "HEAD", "refs/heads/master"). When unspecified, update from all heads the remote side has. and this has been the case since fetch-pack was originally documented in 8b3d9dc ([PATCH] Documentation: clone/fetch/upload., 2005-07-14). Let's follow our own documentation to set a good example, and to avoid breaking when this restriction is enforced in the next patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12Revert "reset: Make reset remove the sequencer state"Libravatar Jonathan Nieder2-53/+1
This reverts commit 95eb88d8ee588d89b4f06d2753ed4d16ab13b39f, which was a UI experiment that did not reflect how "git reset" actually gets used. The reversion also fixes a test, indicated in the patch. Encouraged-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12revert: do not remove state until sequence is finishedLibravatar Jonathan Nieder1-3/+3
As v1.7.8-rc0~141^2~4 (2011-08-04) explains, git cherry-pick removes the sequencer state just before applying the final patch. In the single-pick case, that was a good thing, since --abort and --continue work fine without access to such state and removing it provides a signal that git should not complain about the need to clobber it ("a cherry-pick or revert is already in progress") in sequences like the following: git cherry-pick foo git read-tree -m -u HEAD; # forget that; let's try a different one git cherry-pick bar After the recent patch "allow single-pick in the middle of cherry-pick sequence" we don't need that hack any more. In the new regime, a traditional "git cherry-pick <commit>" command never looks at .git/sequencer, so we do not need to cripple "git cherry-pick <commit>..<commit>" for it any more. So now you can run "git cherry-pick --abort" near the end of a multi-pick sequence and it will abort the entire sequence, instead of misbehaving and aborting just the final commit. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12revert: allow single-pick in the middle of cherry-pick sequenceLibravatar Jonathan Nieder1-0/+12
After messing up a difficult conflict resolution in the middle of a cherry-pick sequence, it can be useful to be able to git checkout HEAD . && git cherry-pick that-one-commit to restart the conflict resolution. The current code however errors out saying that another cherry-pick is already in progress. Suggested-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12revert: pass around rev-list args in already-parsed formLibravatar Jonathan Nieder1-0/+5
Since 7e2bfd3f (revert: allow cherry-picking more than one commit, 2010-07-02), the pick/revert machinery has kept track of the set of commits to be cherry-picked or reverted using commit_argc and commit_argv variables, storing the corresponding command-line parameters. Future callers as other commands are built in (am, rebase, sequencer) may find it easier to pass rev-list options to this machinery in already-parsed form. Teach cmd_cherry_pick and cmd_revert to parse the rev-list arguments in advance and pass the commit set to pick_revisions() as a rev_info structure. Original patch by Jonathan, tweaks and test from Ram. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Improved-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12revert: allow cherry-pick --continue to commit before resumingLibravatar Jonathan Nieder1-3/+136
When "git cherry-pick ..bar" encounters conflicts, permit the operator to use cherry-pick --continue after resolving them as a shortcut for "git commit && git cherry-pick --continue" to record the resolution and carry on with the rest of the sequence. This improves the analogy with "git rebase" (in olden days --continue was the way to preserve authorship when a rebase encountered conflicts) and fits well with a general UI goal of making "git cmd --continue" save humans the trouble of deciding what to do next. Example: after encountering a conflict from running "git cherry-pick foo bar baz": CONFLICT (content): Merge conflict in main.c error: could not apply f78a8d98c... bar! hint: after resolving the conflicts, mark the corrected paths hint: with 'git add <paths>' or 'git rm <paths>' hint: and commit the result with 'git commit' We edit main.c to resolve the conflict, mark it acceptable with "git add main.c", and can run "cherry-pick --continue" to resume the sequence. $ git cherry-pick --continue [editor opens to confirm commit message] [master 78c8a8c98] bar! 1 files changed, 1 insertions(+), 1 deletions(-) [master 87ca8798c] baz! 1 files changed, 1 insertions(+), 1 deletions(-) This is done for both codepaths to pick multiple commits and a single commit. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11Test 'checkout -m -- path'Libravatar Pete Harlan1-0/+47
Signed-off-by: Pete Harlan <pgit@pcharlan.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-05builtin/apply.c: report error on failure to recognize inputLibravatar Brandon Casey1-0/+19
When git apply is passed something that is not a patch, it does not produce an error message or exit with a non-zero status if it was not actually "applying" the patch i.e. --check or --numstat etc were supplied on the command line. Fix this by producing an error when apply fails to find any hunks whatsoever while parsing the patch. This will cause some of the output formats (--numstat, --diffstat, etc) to produce an error when they formerly would have reported zero changes and exited successfully. That seems like the correct behavior though. Failure to recognize the input as a patch should be an error. Plus, add a test. Reported-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-05t/t4131-apply-fake-ancestor.sh: fix broken testLibravatar Brandon Casey1-1/+1
The third test "apply --build-fake-ancestor in a subdirectory" has been broken since it was introduced. It intended to modify a tracked file named 'sub/3.t' and then produce a diff which could be git apply'ed, but the file named 'sub/3.t' does not exist. The file that exists in the repo is called 'sub/3'. Since no tracked files were modified, an empty diff was produced, and the test succeeded. Correct this test by supplying the intended name of the tracked file, 'sub/3.t', to test_commit in the first test. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-28fast-import: Fix incorrect fanout level when modifying existing notes refsLibravatar Johan Herland1-4/+4
This fixes the bug uncovered by the tests added in the previous two patches. When an existing notes ref was loaded into the fast-import machinery, the num_notes counter associated with that ref remained == 0, even though the true number of notes in the loaded ref was higher. This caused a fanout level of 0 to be used, although the actual fanout of the tree could be > 0. Manipulating the notes tree at an incorrect fanout level causes removals to silently fail, and modifications of existing notes to instead produce an additional note (leaving the old object in place at a different fanout level). This patch fixes the bug by explicitly counting the number of notes in the notes tree whenever it looks like the num_notes counter could be wrong (when num_notes == 0). There may be false positives (i.e. triggering the counting when the notes tree is truly empty), but in those cases, the counting should not take long. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-28t9301: Add 2nd testcase exposing bugs in fast-import's notes fanout handlingLibravatar Johan Herland1-0/+54
The previous patch exposed a bug in fast-import where _removing_ an existing note fails (when that note resides on a non-zero fanout level, and was added prior to this fast-import run). This patch demostrates the same issue when _changing_ an existing note (subject to the same circumstances). Discovered-by: Henrik Grubbström <grubba@roxen.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-28t9301: Fix testcase covering up a bug in fast-import's notes fanout handlingLibravatar Johan Herland1-7/+6
There is a bug in fast-import where the fanout levels of an existing notes tree being loaded into the fast-import machinery is disregarded. Instead, any tree loaded is assumed to have a fanout level of 0. If the true fanout level is deeper, any attempt to remove a note from that tree will silently fail (as the note will not be found at fanout level 0). However, this bug was covered up by the way in which the t9301 testcase was written: When generating the fast-import commands to test mass removal of notes, we appended these commands to an already existing 'input' file which happened to already contain the fast-import commands used in the previous subtest to generate the very same notes tree. This would normally be harmless (but suboptimal) as the notes created were identical to the notes already present in the notes tree. But the act of repeating all the notes additions caused the internal fast-import data structures to recalculate the fanout, instead of hanging on to the initial (incorrect) fanout (that causes the bug described above). Thus, the subsequent removal of notes in the same 'input' file would succeed, thereby covering up the bug described above. This patch creates a new 'input' file instead of appending to the file from the previous subtest. Thus, we end up properly testing removal of notes that were added by a previous fast-import command. As a side effect, the notes removal can no longer refer to commits using the marks set by the previous fast-import run, instead the commits names must be referenced directly. The underlying fast-import bug is still present after this patch, but now we have at least uncovered it. Therefore, the affected subtests are labeled as expected failures until the underlying bug is fixed. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-28Allow checkout -B <current-branch> to update the current branchLibravatar Jonathan Nieder1-4/+5
When on master, "git checkout -B master <commit>" is a more natural way to say "git reset --keep <commit>", which was originally invented for the exact purpose of moving to the named commit while keeping the local changes around. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-28branch: allow a no-op "branch -M <current-branch> HEAD"Libravatar Jonathan Nieder1-0/+16
Overwriting the current branch with a different commit is forbidden, as it will make the status recorded in the index and the working tree out of sync with respect to the HEAD. There however is no reason to forbid it if the current branch is renamed to itself, which admittedly is something only an insane user would do, but is handy for scripts. Test script is by Conrad Irwin. Reported-by: Soeren Sonnenburg <sonne@debian.org> Reported-by: Josh Chia (谢任中) Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-23revert --abort: do not leave behind useless sequencer-old directoryLibravatar Jonathan Nieder1-0/+8
The "git cherry-pick --abort" command currently renames the .git/sequencer directory to .git/sequencer-old instead of removing it on success due to an accident. cherry-pick --abort is designed to work in three steps: 1) find which commit to roll back to 2) call "git reset --merge <commit>" to move to that commit 3) remove the .git/sequencer directory But the careless author forgot step 3 entirely. The only reason the command worked anyway is that "git reset --merge <commit>" renames the .git/sequencer directory as a secondary effect --- after moving to <commit>, or so the logic goes, it is unlikely but possible that the caller of git reset wants to continue the series of cherry-picks that was in progress, so git renames the sequencer state to .git/sequencer-old to be helpful while allowing the cherry-pick to be resumed if the caller did not want to end the sequence after all. By running "git cherry-pick --abort", the operator has clearly indicated that she is not planning to continue cherry-picking. Remove the (renamed) .git/sequencer directory as intended all along. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22revert: remove --reset compatibility optionLibravatar Jonathan Nieder1-2/+2
Remove the "git cherry-pick --reset" option, which has a different preferred spelling nowadays ("--quit"). Luckily the old --reset name was not around long enough for anyone to get used to it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22revert: introduce --abort to cancel a failed cherry-pickLibravatar Jonathan Nieder1-0/+96
After running some ill-advised command like "git cherry-pick HEAD..linux-next", the bewildered novice may want to return to more familiar territory. Introduce a "git cherry-pick --abort" command that rolls back the entire cherry-pick sequence and places the repository back on solid ground. Just like "git merge --abort", this internally uses "git reset --merge", so local changes not involved in the conflict resolution are preserved. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22revert: write REVERT_HEAD pseudoref during conflicted revertLibravatar Jonathan Nieder1-0/+54
When conflicts are encountered while reverting a commit, it can be handy to have the name of that commit easily available. For example, to produce a copy of the patch to refer to while resolving conflicts: $ git revert 2eceb2a8 error: could not revert 2eceb2a8... awesome, buggy feature $ git show -R REVERT_HEAD >the-patch $ edit $(git diff --name-only) Set a REVERT_HEAD pseudoref when "git revert" does not make a commit, for cases like this. This also makes it possible for scripts to distinguish between a revert that encountered conflicts and other sources of an unmerged index. After successfully committing, resetting with "git reset", or moving to another commit with "git checkout" or "git reset", the pseudoref is no longer useful, so remove it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22revert: rename --reset option to --quitLibravatar Jonathan Nieder2-6/+27
The option to "git cherry-pick" and "git revert" to discard the sequencer state introduced by v1.7.8-rc0~141^2~6 (revert: Introduce --reset to remove sequencer state, 2011-08-04) has a confusing name. Change it now, while we still have the time. The new name for "cherry-pick, please get out of my way, since I've long forgotten about the sequence of commits I was cherry-picking when you wrote that old .git/sequencer directory" is --quit. Mnemonic: this is analagous to quiting a program the user is no longer using --- we just want to get out of the multiple-command cherry-pick procedure and not to reset HEAD or rewind any other old state. The "--reset" option is kept as a synonym to minimize the impact. We might consider dropping it for simplicity in a separate patch, though. Adjust documentation and tests to use the newly preferred name (--quit) instead of --reset. While at it, let's clarify the short descriptions of these operations in "-h" output. Before: --reset forget the current operation --continue continue the current operation After: --quit end revert or cherry-pick sequence --continue resume revert or cherry-pick sequence Noticed-by: Phil Hord <phil.hord@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-21Merge branch 'jk/maint-1.6.2-upload-archive' into jk/maint-upload-archiveLibravatar Junio C Hamano1-0/+8
* jk/maint-1.6.2-upload-archive: archive: don't let remote clients get unreachable commits Conflicts: archive.c archive.h builtin-archive.c builtin/upload-archive.c t/t5000-tar-tree.sh
2011-11-21archive: don't let remote clients get unreachable commitsLibravatar Jeff King1-0/+8
Usually git is careful not to allow clients to fetch arbitrary objects from the database; for example, objects received via upload-pack must be reachable from a ref. Upload-archive breaks this by feeding the client's tree-ish directly to get_sha1, which will accept arbitrary hex sha1s, reflogs, etc. This is not a problem if all of your objects are publicly reachable anyway (or at least public to anybody who can run upload-archive). Or if you are making the repo available by dumb protocols like http or rsync (in which case the client can read your whole object db directly). But for sites which allow access only through smart protocols, clients may be able to fetch trees from commits that exist in the server's object database but are not referenced (e.g., because history was rewound). This patch tightens upload-archive's lookup to use dwim_ref rather than get_sha1. This means a remote client can only fetch the tip of a named ref, not an arbitrary sha1 or reflog entry. This also restricts some legitimate requests, too: 1. Reachable non-tip commits, like: git archive --remote=$url v1.0~5 2. Sub-trees of reachable commits, like: git archive --remote=$url v1.7.7:Documentation Local requests continue to use get_sha1, and are not restricted at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-20t5501-*.sh: Fix url passed to clone in setup testLibravatar Ramsay Jones1-1/+1
In particular, the url passed to git-clone has an extra '/' given after the 'file://' schema prefix, thus: git clone --reference=original "file:///$(pwd)/original one Once the prefix is removed, the remainder of the url looks something like "//home/ramsay/git/t/...", which is then interpreted as an network path. This then results in a "Permission denied" error, like so: ramsay $ ls //home ls: cannot access //home: No such host or network path ramsay $ ls //home/ramsay ls: cannot access //home/ramsay: Permission denied ramsay $ In order to fix the problem, we simply remove the extraneous '/' character from the url. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-16refs: loosen over-strict "format" checkLibravatar Junio C Hamano1-0/+7
The add_extra_ref() interface is used to add an extra-ref that is _not_ our ref for the purpose of helping auto-following of tags and reducing object transfer from remote repository, and they are typically formatted as a tagname followed by ^{} to make sure no valid refs match that pattern. In other words, these entries are deliberately formatted not to pass check-refname-format test. A recent series however added a test unconditionally to the add_ref() function that is called from add_extra_ref(). The check may be sensible for other two callsites of the add_ref() interface, but definitely is a wrong thing to do in add_extra_ref(). Disable it. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Michael Haggerty <mhagger@alum.mit.edu>
2011-11-15Revert "upload-archive: use start_command instead of fork"Libravatar Junio C Hamano1-5/+5
This reverts commit c09cd77ea2fe3580b33918a99fe138d239ac2aaf, expecting a better version to be rerolled soon.
2011-11-06Merge branch 'ab/i18n-test-fix'Libravatar Junio C Hamano2-3/+3
* ab/i18n-test-fix: t/t7508-status.sh: use test_i18ncmp t/t6030-bisect-porcelain.sh: use test_i18ngrep
2011-11-06Merge branch 'pw/p4-appledouble-fix'Libravatar Junio C Hamano1-0/+31
* pw/p4-appledouble-fix: git-p4: ignore apple filetype