kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Johannes Schindelin	21d0764c82	rebase -i --root: let the sequencer handle even the initial part In this developer's earlier attempt to accelerate interactive rebases by converting large parts from Unix shell script into portable, performant C, the --root handling was specifically excluded (to simplify the task a little bit; it still took over a year to get that reduced set of patches into Git proper). This patch ties up that loose end: now only --preserve-merges uses the slow Unix shell script implementation to perform the interactive rebase. As the rebase--helper reports progress to stderr (unlike the scripted interactive rebase, which reports it to stdout, of all places), we have to adjust a couple of tests that did not expect that for `git rebase -i --root`. This patch fixes -- at long last! -- the really old bug reported in `6a6bc5bdc4` (add tests for rebasing root, 2013-06-06) that rebasing with --root always rewrote the root commit, even if there were no changes. The bug still persists in --preserve-merges mode, of course, but that mode will be deprecated as soon as the new --rebase-merges mode stabilizes, anyway. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Phillip Wood	24293359cc	rebase --rebase-merges: add test for --keep-empty If there are empty commits on the left hand side of $upstream...HEAD then the empty commits on the right hand side that we want to keep are being pruned. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Phillip Wood	da27a6fbd5	rebase --keep-empty: always use interactive rebase rebase --merge accepts --keep-empty but just ignores it, by using an implicit interactive rebase the user still gets the rename detection of a merge based rebase but with with --keep-empty support. If rebase --keep-empty without --interactive or --merge stops for the user to resolve merge conflicts then 'git rebase --continue' will fail. This is because it uses a different code path that does not create $git_dir/rebase-apply. As rebase --keep-empty was implemented using cherry-pick it has never supported the am options and now that interactive rebases support --signoff there is no loss of functionality by using an implicit interactive rebase. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Phillip Wood	76ea235891	rebase -i --keep-empty: don't prune empty commits If there are empty commits on the left hand side of $upstream...HEAD then the empty commits on the right hand side that we want to keep are pruned by --cherry-pick. Fix this by using --cherry-mark instead of --cherry-pick and keeping the commits that are empty or are not marked as cherry-picks. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Ben Woosley	79f43447d2	git-rebase--merge: don't include absent parent as a base Absent this fix, attempts to rebase an orphan branch using "rebase -m" fails with: $ git rebase -m ORPHAN_TARGET_BASE First, rewinding head to replay your work on top of it... fatal: Could not parse object 'ORPHAN_ROOT_SHA^' Unknown exit code (128) from command: git-merge-recursive ORPHAN_ROOT_SHA^ -- HEAD ORPHAN_ROOT_SHA To fix, this will only include the rebase root's parent as a base if it exists, so that in cases of rebasing an orphan branch, it is a simple two-way merge. Note the default rebase behavior does not fail: $ git rebase ORPHAN_TARGET_BASE First, rewinding head to replay your work on top of it... Applying: ORPHAN_ROOT_COMMIT_MSG Using index info to reconstruct a base tree... A few tests were expecting the old behaviour to forbid rebasing such a history with "rebase -m", which now need to expect them to succeed. Signed-off-by: Ben Woosley <ben.woosley@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Johannes Sixt	984f78d278	rebase topology tests: fix commit names on case-insensitive file systems The recently introduced tests used uppercase letters to denote cherry-picks of commits having the corresponding lowercase letter names. The helper functions also set up tags with the names of the commits. But this constellation fails on case-insensitive file systems because there cannot be distinct tags with names that differ only in case. Use a less subtle convention for the names of cherry-picked commits. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Martin von Zweigbergk	6a6bc5bdc4	add tests for rebasing root Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Martin von Zweigbergk	00b8be5a4d	add tests for rebasing of empty commits Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Martin von Zweigbergk	5b5e1c7c78	add tests for rebasing with patch-equivalence present Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Martin von Zweigbergk	2aad7cace2	add simple tests of consistency across rebase types Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago