summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2012-04-09rebase -i continue: don't skip commits that only change submodulesLibravatar John Keeping1-0/+30
When git-rebase--interactive stops due to a conflict and the only change to be committed is in a submodule, the test for whether there is anything to be committed ignores the staged submodule change. This leads rebase to skip creating the commit for the change. While unstaged submodule changes should be ignored to avoid needing to update submodules during a rebase, it is safe to remove the --ignore-submodules option to diff-index because --cached ensures that it is only checking the index. This was discussed in [1] and a test is included to ensure that unstaged changes are still ignored correctly. [1] http://thread.gmane.org/gmane.comp.version-control.git/188713 Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-09Merge branch 'tr/cache-tree' into maint-1.7.8Libravatar Junio C Hamano1-0/+93
* 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 Hamano1-0/+28
* 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 'tr/maint-bundle-boundary' into maint-1.7.8Libravatar Junio C Hamano1-22/+35
* 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 Hamano1-24/+23
* 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-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 'jn/gitweb-unspecified-action' into maint-1.7.8Libravatar Junio C Hamano1-0/+8
* jn/gitweb-unspecified-action: gitweb: Fix actionless dispatch for non-existent objects
2012-03-01bundle: keep around names passed to add_pending_object()Libravatar Thomas Rast1-0/+15
The 'name' field passed to add_pending_object() is used to later deduplicate in object_array_remove_duplicates(). git-bundle had a bug in this area since 18449ab (git-bundle: avoid packing objects which are in the prerequisites, 2007-03-08): it passed the name of each boundary object in a static buffer. In other words, all that object_array_remove_duplicates() saw was the name of the *last* added boundary object. The recent switch to a strbuf in bc2fed4 (bundle: use a strbuf to scan the log for boundary commits, 2012-02-22) made this slightly worse: we now free the buffer at the end, so it is not even guaranteed that it still points into addressable memory by the time object_array_remove_ duplicates looks at it. On the plus side however, it was now detectable by valgrind. The fix is easy: pass a copy of the string to add_pending_object. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-01t5510: ensure we stay in the toplevel test dirLibravatar Thomas Rast1-8/+10
The last test descended into a subdir without ever re-emerging, which is not so nice to the next test writer. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-01t5510: refactor bundle->pack conversionLibravatar Thomas Rast1-14/+10
It's not so much a conversion as a "strip everything up to and including the first blank line", but it will come in handy again. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-26am: don't infloop for an empty input fileLibravatar Jim Meyering1-0/+10
git-am.sh's check_patch_format function would attempt to preview the patch to guess its format, but would go into an infinite loop when the patch file happened to be empty. The solution: exit the loop when "read" fails, not when the line var, "$l1" becomes empty. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-23t5704: match tests to modern styleLibravatar Thomas Rast1-25/+8
The test did not adhere to the current style on several counts: . empty lines around the test blocks, but within the test string . ': > file' or even just '> file' with an extra space . inconsistent indentation . hand-rolled commits instead of using test_commit Fix all of them. There's a catch to the last point: test_commit creates a tag, which the original test did not create. We still change it to test_commit, and explicitly delete the tags, so as to highlight that the test relies on not having them. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-23bundle: use a strbuf to scan the log for boundary commitsLibravatar Thomas Rast1-0/+16
The first part of the bundle header contains the boundary commits, and could be approximated by # v2 git bundle $(git rev-list --pretty=oneline --boundary <ARGS> | grep ^-) git-bundle actually spawns exactly this rev-list invocation, and does the grepping internally. There was a subtle bug in the latter step: it used fgets() with a 1024-byte buffer. If the user has sufficiently long subjects (e.g., by not adhering to the git oneline-subject convention in the first place), the 'oneline' format can easily overflow the buffer. fgets() then returns the rest of the line in the next call(s). If one of these remaining parts started with '-', git-bundle would mistakenly insert it into the bundle thinking it was a boundary commit. Fix it by using strbuf_getwholeline() instead, which handles arbitrary line lengths correctly. Note that on the receiving side in parse_bundle_header() we were already using strbuf_getwholeline_fd(), so that part is safe. Reported-by: Jannis Pohlmann <jannis.pohlmann@codethink.co.uk> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-13t5541: check error message against the real port number usedLibravatar Clemens Buchacher1-1/+1
Otherwise the test cannot be run with custom port set to LIB_HTTPD_PORT. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-22t/Makefile: Use $(sort ...) explicitly where neededLibravatar Kirill Smelkov1-3/+3
Starting from GNU Make 3.82 $(wildcard ...) no longer sorts the result (from NEWS): * WARNING: Backward-incompatibility! Wildcards were not documented as returning sorted values, but the results have been sorted up until this release.. If your makefiles require sorted results from wildcard expansions, use the $(sort ...) function to request it explicitly. http://repo.or.cz/w/make.git/commitdiff/2a59dc32aaf0681dec569f32a9d7ab88a379d34f I usually watch test progress visually, and if tests are sorted, even with make -j4 they go more or less incrementally by their t number. On the other side, without sorting, tests are executed in seemingly random order even for -j1. Let's please maintain sane tests order for perceived prettyness. Another note is that in GNU Make sort also works as uniq, so after sort being removed, we might expect e.g. $(wildcard *.sh a.*) to produce duplicates for e.g. "a.sh". From this point of view, adding sort could be seen as hardening t/Makefile from accidentally introduced dups. It turned out that prevous releases of GNU Make did not perform full sort in $(wildcard), only sorting results for each pattern, that's why explicit sort-as-uniq is relevant even for older makes. Signed-off-by: Kirill Smelkov <kirr@navytux.spb.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-20remote-curl: Fix push status report when all branches failLibravatar Shawn O. Pearce1-0/+28
The protocol between transport-helper.c and remote-curl requires remote-curl to always print a blank line after the push command has run. If the blank line is ommitted, transport-helper kills its container process (the git push the user started) with exit(128) and no message indicating a problem, assuming the helper already printed reasonable error text to the console. However if the remote rejects all branches with "ng" commands in the report-status reply, send-pack terminates with non-zero status, and in turn remote-curl exited with non-zero status before outputting the blank line after the helper status printed by send-pack. No error messages reach the user. This caused users to see the following from git push over HTTP when the remote side's update hook rejected the branch: $ git push http://... master Counting objects: 4, done. Delta compression using up to 6 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 301 bytes, done. Total 3 (delta 0), reused 0 (delta 0) $ Always print a blank line after the send-pack process terminates, ensuring the helper status report (if it was output) will be correctly parsed by the calling transport-helper.c. This ensures the helper doesn't abort before the status report can be shown to the user. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-09gitweb: Fix actionless dispatch for non-existent objectsLibravatar Jakub Narebski1-0/+8
When gitweb URL does not provide action explicitly, e.g. http://git.example.org/repo.git/branch dispatch() tries to guess action (view to be used) based on remaining parameters. Among others it is based on the type of requested object, which gave problems when asking for non-existent branch or file (for example misspelt name). Now undefined $action from dispatch() should not result in problems. Signed-off-by: Jakub Narebski <jnareb@gmail.com> 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-20t0090: be prepared that 'wc -l' writes leading blanksLibravatar Johannes Sixt1-4/+2
Use 'printf %d $(whatever|wc -l)' so that the shell removes the blanks for us. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Thomas Rast <trast@student.ethz.ch> 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-06reset: update cache-tree data when appropriateLibravatar Thomas Rast1-2/+2
In the case of --mixed and --hard, we throw away the old index and rebuild everything from the tree argument (or HEAD). So we have an opportunity here to fill in the cache-tree data, just as read-tree did. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>