kernel/git - git - PowerEL Git System

42708 Commits

6 Branches

36 Tags

131 MiB

Tree: eed2707202

Commit Graph

Author	SHA1	Message	Date
Jonathan Nieder	127f045222	revert: plug memory leak in "cherry-pick root commit" codepath 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>	14 years ago
Jeff King	e9fe74cba4	t3503: test cherry picking and reverting root commits 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>	14 years ago
Johannes Schindelin	f95ebf7429	Allow cherry-picking root commits 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>	17 years ago

Author

SHA1

Message

Date

Jonathan Nieder

127f045222

revert: plug memory leak in "cherry-pick root commit" codepath

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>

14 years ago

Jeff King

e9fe74cba4

t3503: test cherry picking and reverting root commits

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>

14 years ago

Johannes Schindelin

f95ebf7429

Allow cherry-picking root commits

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>

17 years ago

4 Commits (eed270720227c761213a61fb6d75a44ac5a6f290)