kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Martin von Zweigbergk	5d77298d08	tests: move test_cmp_rev to test-lib-functions A function for checking that two given parameters refer to the same revision was defined in several places, so move the definition to test-lib-functions.sh instead. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Martin von Zweigbergk	a73e22e963	cherry-pick/revert: respect order of revisions to pick When giving multiple individual revisions to cherry-pick or revert, as in 'git cherry-pick A B' or 'git revert B A', one would expect them to be picked/reverted in the order given on the command line. They are instead ordered by their commit timestamp -- in chronological order for "cherry-pick" and in reverse chronological order for "revert". This matches the order in which one would usually give them on the command line, making this bug somewhat hard to notice. Still, it has been reported at least once before [1]. It seems like the chronological sorting happened by accident because the revision walker has traditionally always sorted commits in reverse chronological order when rev_info.no_walk was enabled. In the case of 'git revert B A' where B is newer than A, this sorting is a no-op. For 'git cherry-pick A B', the sorting would reverse the arguments, but because the sequencer also flips the rev_info.reverse flag when picking (as opposed to reverting), the end result is a chronological order. The rev_info.reverse flag was probably flipped so that the revision walker emits B before C in 'git cherry-pick A..C'; that it happened to effectively undo the unexpected sorting done when not walking, was probably a coincidence that allowed this bug to happen at all. Fix the bug by telling the revision walker not to sort the commits when not walking. The only case we want to reverse the order is now when cherry-picking and walking revisions (rev_info.no_walk = 0). [1] http://thread.gmane.org/gmane.comp.version-control.git/164794 Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Martin von Zweigbergk	d023c248a3	demonstrate broken 'git cherry-pick three one two' Cherry-picking commits out of order (w.r.t. commit time stamp) doesn't currently work. Add a test case to demonstrate it. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jonathan Nieder	2593633f5a	test: test cherry-pick functionality and output separately Since v1.7.3-rc0~26^2~9 (revert: report success when using option --strategy, 2010-07-14), the cherry-pick-many-commits test checks the format of output written to the terminal during a cherry-pick sequence in addition to the functionality. There is no reason those have to be checked in the same test, though, and it has some downsides: - when progress output is broken, the test result does not convey whether the functionality was also broken or not - it is not immediately obvious when reading that these checks are meant to prevent regressions in details of the output format and are not just a roundabout way to check functional details like the number of commits produced - there is a temptation to include the same kind of output checking for every new cherry-pick test, which would make future changes to the output unnecessarily difficult Put the tests from v1.7.3-rc0~26^2~9 in separate assertions, following the principle "test one feature at a time". Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jonathan Nieder	fc5877a623	test: use test_i18ncmp when checking --stat output Ever since v1.7.9.2~13 (2012-02-01), git's diffstat-style summary line produced by "git apply --stat", "git diff --stat", and "git commit" varies by locale, producing test failures when GETTEXT_POISON is set. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Nguyễn Thái Ngọc Duy	7f814632f5	Use correct grammar in diffstat summary line "git diff --stat" and "git apply --stat" now learn to print the line "%d files changed, %d insertions(+), %d deletions(-)" in singular form whenever applicable. "0 insertions" and "0 deletions" are also omitted unless they are both zero. This matches how versions of "diffstat" that are not prehistoric produced their output, and also makes this line translatable. [jc: with help from Thomas Dickey in archaeology of "diffstat"] [jc: squashed Jonathan's updates to illustrations in tutorials and a test] Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Jonathan Nieder	130ab8ab9c	Eliminate “Finished cherry-pick/revert” message When cherry-pick was written (v0.99.6~63, 2005-08-27), “git commit” was quiet, and the output from cherry-pick provided useful information about the progress of a rebase. Now next to the output from “git commit”, the cherry-pick notification is so much noise (except for the name of the picked commit). $ git cherry-pick ..topic Finished cherry-pick of 499088b. [detached HEAD 17e1ff2] Move glob module to libdpkg Author: Guillem Jover <guillem@debian.org> 8 files changed, 12 insertions(+), 9 deletions(-) rename {src => lib/dpkg}/glob.c (98%) rename {src => lib/dpkg}/glob.h (93%) Finished cherry-pick of ae947e1. [detached HEAD 058caa3] libdpkg: Add missing symbols to Versions script Author: Guillem Jover <guillem@debian.org> 1 files changed, 2 insertions(+), 0 deletions(-) $ The noise is especially troublesome when sifting through the output of a rebase or multiple cherry-pick that eventually failed. With the commit subject, it is already not hard to figure out where the commit came from. So drop the “Finished” message. Cc: Christian Couder <chriscool@tuxfamily.org> Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Christian Couder	6bc83cdd0b	t3508: add check_head_differs_from() helper function and use it In a test like: test "$(git rev-parse --verify HEAD)" != "$(git rev-parse --verify fourth)" the --verify does not accomplish much, since the exit status of git rev-parse is not propagated to test. So it is more robust to define and use the helper functions check_head_differs_from() and check_head_equals() as done by this patch. Suggested-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Christian Couder	f29b5e06b3	revert: improve success message by adding abbreviated commit sha1 Instead of saying "Finished one cherry-pick." or "Finished one revert.", we now say "Finished cherry-pick of commit <abbreviated sha1>." or "Finished revert of commit <abbreviated sha1>." which is more informative, especially when cherry-picking or reverting many commits. In case of failure the message is now "Automatic cherry-pick of commit <abbreviated sha1> failed." instead of "Automatic cherry-pick failed." Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Christian Couder	7b53b92fdb	revert: report success when using option --strategy "git cherry-pick foo" has always reported success with "Finished one cherry-pick" but "cherry-pick --strategy" does not print anything. So move the code to write that message from do_recursive_merge() to do_cherry_pick() so other strategies can share it. This patch also refactors the code that prints a message like "Automatic cherry-pick failed. <help message>". This code was duplicated in both do_recursive_merge() and do_pick_commit(). To do that, now do_recursive_merge() returns an int to signal success or failure. And in case of failure we just return 1 from do_pick_commit() instead of doing "exit(1)" from either do_recursive_merge() or do_pick_commit(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Christian Couder	f873a273d1	revert: accept arbitrary rev-list options This can be useful to do something like: git rev-list --reverse master -- README \| git cherry-pick -n --stdin without using xargs. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jonathan Nieder	18c8ff4610	t3508 (cherry-pick): futureproof against unmerged files Each of the tests in t3508 begins by navigating to a sane state: git checkout master && git reset --hard $commit If a previous test left unmerged files around, they are untouched and the checkout fails, causing later tests to fail, too. This is not a problem in practice because no test except the final one produces unmerged files. But as a futureproofing measure, it is still best to avoid the problem with 'checkout -f'. In particular, this is needed for new tests to be added to the end of the script. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Christian Couder	aa29ccf4c0	revert: add tests to check cherry-picking many commits Note that there is an expected failure when running: git cherry-pick -3 fourth that's because: git rev-list --no-walk -3 fourth produce only one commit and not 3 as "--no-walk" seems to take over "-3". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago

14 Commits (11667316d0dc455131b3898fdd29fe080b5ae4e0)