[PATCH] git-completion.zsh: do not clobber complete()

bash-completion.bash is sourced, we must pass in a flag to git-completion.bash to change its behavior. Signed-off-by: Mark Lodato --- contrib/completion/git-completion.bash | 1 + contrib/completion/git-completion.zsh | 8 +--- 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/co

Re: [PATCH] http.c: fix parsing of http.sslCertPasswordProtected variable

On Fri, Jul 12, 2013 at 3:52 PM, Junio C Hamano wrote: > > Jonathan Nieder writes: > > > FWIW the GIT_SSL_CERT_PASSWORD_PROTECTED envvar has a similar "can > > only enable" behavior, but since it's documented, that's not as big > > of a problem. Do you remember why it was written that way? > > N

Announcing git-reparent

ieve the same effect git-rebase(1) can be used to re-apply the *diffs* of the current branch to another AUTHOR == Mark Lodato --- 8< --- #!/bin/sh # Copyright (c) Mark Lodato, 2013 OPTIONS_SPEC="\ git reparent [OPTIONS] ((-p )... | --no-parent) Recommit HEAD with a new set of pa

Re: Announcing git-reparent

On Mon, Jan 14, 2013 at 3:03 AM, Piotr Krukowiecki wrote: > Just wondering, is the result different than something like > > git checkout commit_to_reparent > cp -r * ../snapshot/ > git reset --hard new_parent > rm -r * > cp -r ../snapshot/* . > git add -A > > (assumes 1 parent, does not cope with

git apply --interactive

I'd love for "git apply" to have an equivalent to "git add -p". (I'm guessing it would be called --interactive since "git apply -p" is taken and --patch would be confusing.) Has anyone thought about this? After taking a quick look at git-add--interactive.perl, it seems like the main steps would