Re: [PATCH v7 4/4] git-rebase: add keep_empty flag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/18/2012 09:18 PM, Neil Horman wrote:
Add a command line switch to git-rebase to allow a user the ability to specify
that they want to keep any commits in a series that are empty.

When git-rebase's type is am, then this option will automatically keep any
commit that has a tree object identical to its parent.

This patch changes the default behavior of interactive rebases as well.  With
this patch, git-rebase -i will produce a revision set passed to
git-revision-editor, in which empty commits are commented out.  Empty commits
may be kept manually by uncommenting them.  If the new --keep-empty option is
used in an interactive rebase the empty commits will automatically all be
uncommented in the editor.

Signed-off-by: Neil Horman<nhorman@xxxxxxxxxxxxx>

Hi,
this one seems to breaks many tests when /bin/sh=dash. (Both v6 in pu and this v7).

E.g. ./t3404-rebase-interactive.sh:

ok 1 - setup
not ok - 2 rebase -i with the exec command
not ok - 3 rebase -i with the exec command runs from tree root
not ok - 4 rebase -i with the exec command checks tree cleanness
not ok - 5 no changes are a nop
not ok - 6 test the [branch] option
not ok - 7 test --onto <branch>
not ok - 8 rebase on top of a non-conflicting commit
not ok - 9 reflog for the branch shows state before rebase
not ok - 10 exchange two commits
not ok - 11 stop on conflicting pick
not ok - 12 abort
not ok - 13 abort with error when new base cannot be checked out
not ok - 14 retain authorship
not ok - 15 squash
not ok - 16 retain authorship when squashing
not ok - 17 -p handles "no changes" gracefully
not ok 18 - exchange two commits with -p # TODO known breakage
not ok - 19 preserve merges with -p
not ok - 20 edit ancestor with -p
not ok - 21 --continue tries to commit
not ok - 22 verbose flag is heeded, even after --continue
not ok - 23 multi-squash only fires up editor once
not ok - 24 multi-fixup does not fire up editor
not ok - 25 commit message used after conflict
not ok - 26 commit message retained after conflict
not ok - 27 squash and fixup generate correct log messages
not ok - 28 squash ignores comments
not ok - 29 squash ignores blank lines
not ok - 30 squash works as expected
not ok - 31 interrupted squash works as expected
not ok - 32 interrupted squash works as expected (case 2)
not ok - 33 ignore patch if in upstream
not ok - 34 --continue tries to commit, even for "edit"
not ok - 35 aborted --continue does not squash commits after "edit"
not ok - 36 auto-amend only edited commits after "edit"
not ok - 37 clean error after failed "exec"
not ok - 38 rebase a detached HEAD
not ok - 39 rebase a commit violating pre-commit
not ok - 40 rebase with a file named HEAD in worktree
ok 41 - do "noop" when there is nothing to cherry-pick
ok 42 - submodule rebase setup
not ok - 43 submodule rebase -i
ok 44 - submodule conflict setup
not ok - 45 rebase -i continue with only submodule staged
not ok - 46 rebase -i continue with unstaged submodule
not ok - 47 avoid unnecessary reset
not ok - 48 reword
ok 49 - rebase -i can copy notes
not ok - 50 rebase -i can copy notes over a fixup
not ok - 51 rebase while detaching HEAD
not ok - 52 always cherry-pick with --no-ff
ok 53 - set up commits with funny messages
not ok - 54 rebase-i history with funny messages

The problem seems to be that git-rebase says "Nothing to do" and returns 1.

-
Zbyszek
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]