summaryrefslogtreecommitdiff
path: root/t/t6007-rev-list-cherry-pick-file.sh
AgeCommit message (Collapse)AuthorFilesLines
2017-10-07tests: fix diff order arguments in test_cmpLibravatar Stefan Beller1-16/+16
Fix the argument order for test_cmp. When given the expected result first the diff shows the actual output with '+' and the expectation with '-', which is the convention for our tests. Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-23name-rev: add support to exclude refs by pattern matchLibravatar Jacob Keller1-0/+12
Extend git-name-rev to support excluding refs which match shell patterns using --exclude. These patterns can be used to limit the scope of refs by excluding any ref that matches one of the --exclude patterns. A ref will only be used for naming when it matches at least one --refs pattern but does not match any of the --exclude patterns. Thus, --exclude patterns are given precedence over --refs patterns. For example, suppose you wish to name a series of commits based on an official release tag of the form "v*" but excluding any pre-release tags which match "*rc*". You can use the following to do so: git name-rev --refs="v*" --exclude="*rc*" --all Add tests and update Documentation for this change. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-23name-rev: extend --refs to accept multiple patternsLibravatar Jacob Keller1-0/+26
Teach git name-rev to take multiple --refs stored as a string list of patterns. The list of patterns will be matched inclusively, and each ref only needs to match one pattern to be included. A ref will only be excluded if it does not match any of the given patterns. Additionally, if any of the patterns would allow abbreviation, then we will abbreviate the ref, even if another pattern is more strict and would not have allowed abbreviation on its own. Add tests and documentation for this change. The tests expected output is dynamically generated. This is in order to avoid hard-coding a commit object name in the test results (as the expected output is to simply leave the commit object unnamed). Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11rebase: avoid computing unnecessary patch IDsLibravatar Kevin Willford1-0/+21
The `rebase` family of Git commands avoid applying patches that were already integrated upstream. They do that by using the revision walking option that computes the patch IDs of the two sides of the rebase (local-only patches vs upstream-only ones) and skipping those local patches whose patch ID matches one of the upstream ones. In many cases, this causes unnecessary churn, as already the set of paths touched by a given commit would suffice to determine that an upstream patch has no local equivalent. This hurts performance in particular when there are a lot of upstream patches, and/or large ones. Therefore, let's introduce the concept of a "diff-header-only" patch ID, compare those first, and only evaluate the "full" patch ID lazily. Please note that in contrast to the "full" patch IDs, those "diff-header-only" patch IDs are prone to collide with one another, as adjacent commits frequently touch the very same files. Hence we now have to be careful to allow multiple hash entries with the same hash. We accomplish that by using the hashmap_add() function that does not even test for hash collisions. This also allows us to evaluate the full patch ID lazily, i.e. only when we found commits with matching diff-header-only patch IDs. We add a performance test that demonstrates ~1-6% improvement. In practice this will depend on various factors such as how many upstream changes and how big those changes are along with whether file system caches are cold or warm. As Git's test suite has no way of catching performance regressions, we also add a regression test that verifies that the full patch ID computation is skipped when the diff-header-only computation suffices. Signed-off-by: Kevin Willford <kcwillford@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-26rev-list --count: separate count for --cherry-markLibravatar Michael J Gruber1-0/+27
When --count is used with --cherry-mark, omit the patch equivalent commits from the count for left and right commits and print the count of equivalent commits separately. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09t6007: test rev-list --cherryLibravatar Michael J Gruber1-0/+12
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09rev-list: documentation and test for --cherry-markLibravatar Michael J Gruber1-0/+28
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-21rev-list: documentation and test for --left/right-onlyLibravatar Michael J Gruber1-4/+28
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-21t6007: Make sure we test --cherry-pickLibravatar Michael J Gruber1-8/+41
Test 5 wants to test --cherry-pick but limits by pathspec in such a way that there are no commits on the left side of the range. Add a test without "--cherry-pick" which displays this, and add two more commits and another test which tests what we're after. This also shortens the last test. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-12rev-list: introduce --count optionLibravatar Thomas Rast1-0/+29
Add a --count option that, instead of actually listing the commits, merely counts them. This is mostly geared towards script use, and to this end it acts specially when used with --left-right: it outputs the left and right counts separately. Previously, scripts would have to run a shell loop or small inline script over to achieve the same. (Without --left-right, a simple |wc -l does the job.) Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-15revision walker: --cherry-pick is a limited operationLibravatar Johannes Schindelin1-0/+14
We used to rely on the fact that cherry-pick would trigger the code path to set limited = 1 in handle_commit(), when an uninteresting commit was encountered. However, when cherry picking between two independent branches, i.e. when there are no merge bases, and there is only linear development (which can happen when you cvsimport a fork of a project), no uninteresting commit will be encountered. So set limited = 1 when --cherry-pick was asked for. Noticed by Martin Bähr. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-11Fix --cherry-pick with given pathsLibravatar Johannes Schindelin1-0/+43
If you say --cherry-pick, you do not want to see patches which are in the upstream. If you specify paths with that, what you usually expect is that only those parts of the patches are looked at which actually touch the given paths. With this patch, that expectation is met. Noticed by Sam Vilain. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>