On 3/26/2012 12:20 PM, Neil Horman wrote:
On Mon, Mar 26, 2012 at 10:12:48AM -0700, Junio C Hamano wrote:
Neil Horman<nhorman@xxxxxxxxxxxxx> writes:
I agree, I think perhaps adding an --allow-empty option to the rebase logic, so
that empty commits (or perhaps just initially empty, as opposed to commits made
empty) would be very beneficial.
Yeah, that probably may make sense.
Ok, cool, I'll have a patch in a few days, thanks!
IMO, it seems like --allow-empty is an appropriate patch for git-rebase
(non-interactive), and that git-rebase -i would need a command like
"k"eep to distinguish which empty commits are not to be discarded and
which empty commits are ok to discard automatically. git-rebase -i
should allow explicit control on a commit by commit basis as opposed to
blanket rules like "discard all empty commits" or "keep all empty
commits" that apply to all commits in the rebase-to-do list based on a
single cli option.
Maybe this is what you plan on doing. Maybe there is a better command
name than "k"eep for this.
v/r,
neal
--
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