Revision d17ec3a9daffd7f525f39b52011dc653afcbd275 authored by Johannes Schindelin on 18 June 2015, 16:38:44 UTC, committed by Junio C Hamano on 29 June 2015, 20:11:37 UTC
When rev-list's --cherry option does not detect that a patch has already been applied upstream, an interactive rebase would offer to reapply it and consequently stop at that patch with a failure, mentioning that the diff is empty. Traditionally, a `git rebase --continue` simply skips the commit in such a situation. However, as pointed out by Gábor Szeder, this leaves a CHERRY_PICK_HEAD behind, making the Git prompt believe that a cherry pick is still going on. This commit adds a test case demonstrating this bug. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
1 parent fdf96a2
tar.h
#define TYPEFLAG_AUTO '\0'
#define TYPEFLAG_REG '0'
#define TYPEFLAG_LNK '2'
#define TYPEFLAG_DIR '5'
#define TYPEFLAG_GLOBAL_HEADER 'g'
#define TYPEFLAG_EXT_HEADER 'x'
struct ustar_header {
char name[100]; /* 0 */
char mode[8]; /* 100 */
char uid[8]; /* 108 */
char gid[8]; /* 116 */
char size[12]; /* 124 */
char mtime[12]; /* 136 */
char chksum[8]; /* 148 */
char typeflag[1]; /* 156 */
char linkname[100]; /* 157 */
char magic[6]; /* 257 */
char version[2]; /* 263 */
char uname[32]; /* 265 */
char gname[32]; /* 297 */
char devmajor[8]; /* 329 */
char devminor[8]; /* 337 */
char prefix[155]; /* 345 */
};
Computing file changes ...
