aboutsummaryrefslogtreecommitdiff
path: root/t/t3503-cherry-pick-root.sh
Commit message (Collapse)AuthorAge
* Merge branch 'jn/plug-empty-tree-leak'Junio C Hamano2011-08-25
|\ | | | | | | | | | | * jn/plug-empty-tree-leak: merge-recursive: take advantage of hardcoded empty tree revert: plug memory leak in "cherry-pick root commit" codepath
| * revert: plug memory leak in "cherry-pick root commit" codepathJonathan Nieder2011-08-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The empty tree passed as common ancestor to merge_trees() when cherry-picking a parentless commit is allocated on the heap and never freed. Leaking such a small one-time allocation is not a very big problem, but now that "git cherry-pick" can cherry-pick multiple commits it can start to add up. Avoid the leak by storing the fake tree exactly once in the BSS section (i.e., use a static). While at it, let's add a test to make sure cherry-picking multiple parentless commits continues to work. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | t3503: test cherry picking and reverting root commitsJeff King2011-05-16
|/ | | | | | | | | | | We already tested cherry-picking a root commit, but only with the internal merge-recursive strategy. Let's also test the recently-allowed reverting of a root commit, as well as testing with external strategies (which until recently triggered a segfault). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Allow cherry-picking root commitsJohannes Schindelin2008-07-07
A root commit couldn't be cherry-picked. But its semantics can be defined as simply merging two trees by overlaying disjoint parts and merging overlapping files without any common ancestor. You should be able to rebase originally independent branches on top of another branch by using this. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>