[PATCH 0/4] Enhance git-rebases flexibiilty in handling empty commits

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

 



Hey all-
	Based on your feedback from my earlier thread on this subject, I've come
up with this series as a first pass in enhancing git-rebases ability to handle
empty commits.  I'm not sure if its exactly what everyone wants, but I think its
a good start, and it works for what I need it to do here.

I started with adding a -keep-empty option to git-cherry-pick, which allows
non-fast forward commits that are empty to be cherry-pick without failing, and
requiring a separate git commit --allow-empty.

Building on that, I've added --keep-empty option to git-rebase.  For an
automatic rebase adding --keep-empty simply passes the --keep-empty flag along
to git cherry-pick so that the empty commits are preserved instead of discarded

for interactive rebases, I changed the default selection editor text somewhat.
By default, empty commits are allowed in this list.  With patch 4 here, empty
commits are commented out automatically, unless --keep-empty is selected (in
which case all commits are pick-ed).  The user sees additional text indicating
that empty commits are commented and if they wish to be kept, then they must be
uncommented.  The pick_one function then intellegently passes the --keep-empty
option allong to cherry-pick as needed.

Signed-off-by: Neil Horman <nhorman@xxxxxxxxxxxxx>
CC: Jeff King <peff@xxxxxxxx>
CC: Phil Hord <phil.hord@xxxxxxxxx>
CC: Junio C Hamano <gitster@xxxxxxxxx>

--
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]