[PATCH] git-completion.zsh: do not clobber complete()
Previously, git-completion.zsh redefined complete() to make __git_complete()
a no-op. This broke zsh's built-in bash completion compatibility layer
(bashcompinit), which defines its own complete().
Sadly, since there is no way in zsh to restore the original defintion of
complete() after bash-completion.bash is sourced, we must pass in a flag to
git-completion.bash to change its behavior.
Signed-off-by: Mark Lodato lod...@google.com
---
contrib/completion/git-completion.bash | 1 +
contrib/completion/git-completion.zsh | 8 +---
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 9525343..36aa8bb 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2650,6 +2650,7 @@ __git_func_wrap ()
# This is NOT a public function; use at your own risk.
__git_complete ()
{
+ [[ -n $GIT_DO_NOT_CALL_COMPLETE ]] return
local wrapper=__git_wrap${2}
eval $wrapper () { __git_func_wrap $2 ; }
complete -o bashdefault -o default -o nospace -F $wrapper $1
2/dev/null \
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index 6b77968..9f68d63 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -16,12 +16,6 @@
#
# fpath=(~/.zsh $fpath)
-complete ()
-{
- # do nothing
- return 0
-}
-
zstyle -T ':completion:*:*:git:*' tag-order \
zstyle ':completion:*:*:git:*' tag-order 'common-commands'
@@ -39,7 +33,7 @@ if [ -z $script ]; then
test -f $e script=$e break
done
fi
-ZSH_VERSION='' . $script
+GIT_DO_NOT_CALL_COMPLETE=1 ZSH_VERSION='' . $script
__gitcomp ()
{
--
1.9.0.rc1.175.g0b1dcb5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] http.c: fix parsing of http.sslCertPasswordProtected variable
On Fri, Jul 12, 2013 at 3:52 PM, Junio C Hamano gits...@pobox.com wrote: Jonathan Nieder jrnie...@gmail.com 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? Not me ;-). Because that's how GIT_NO_VERIFY, GIT_CURL_FTP_NO_EPSV, and GIT_CURL_VERBOSE (and perhaps others) work. That said, I agree that parsing the variable's value as a boolean would make much more sense. Perhaps this is how all of those variables should work? When that setting was first added[1], there was some mention of autodetection if libcurl could learn to do that. Did it happen? I do not think so, but let's see if our resident cURL guru has something to say about it. I tried back in 2009 but eventually gave up, so unfortunately no. Maybe the situation in libcurl has changed since then? (If you are interested in pursing this, please let me know and I can give you the details of what I tried.) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 be: 1) making sure the patch comes from a file and not stdin, since stdin is required for the interactive input 2) collecting the input patch(es) and separating by output file 3) modifying parse_diff to accept these pre-split patches 4) coloring the patch Mark -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announcing git-reparent
On Mon, Jan 14, 2013 at 3:03 AM, Piotr Krukowiecki piotr.krukowie...@gmail.com 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 .dot files, and has probably other small problems) The result is similar, but your script would also lose the commit message and author. I think the following would do exactly as my script does (untested): git checkout commit_to_reparent git branch tmp git reset --soft new_parent git commit -C tmp git branch -D tmp I actually contemplated using the above method in my script, rather than git-commit-tree and git-reset. In the end, I decided to stick with my original approach because it does not create any intermediate state; either an early command fails and nothing changes, or the git reset works and everything is done. Using the above might be cleaner for the --edit flag since it allows the git-commit cleanup of the commit message, but this would require much more careful error handling, and might make the reflog uglier. I'd be interested to hear a git expert's opinion on the choice. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Announcing git-reparent
I threw together a small utility called git-reparent, available on GitHub at:
https://github.com/MarkLodato/git-reparent
I welcome any comments or suggestions. To make discussion easier,
I've copied the README and code below.
--- 8 ---
NAME
git-reparent - Recommit HEAD with a new set of parents.
SYNOPSIS
``git reparent [OPTIONS] ((-p parent)... | --no-parent)``
DESCRIPTION
===
Create a new commit object that has the same tree and commit message as HEAD
but with a different set of parents. If ``--no-reset`` is given, the full
object id of this commit is printed and the program exits; otherwise, ``git
reset`` is used to update HEAD and the current branch to this new commit.
This command can be used to manually shape the history of a repository.
Whereas ``git rebase`` moves around *diffs*, ``git reparent`` moves around
*snapshots*. See EXAMPLES for a reason why you might want to use this
command.
OPTIONS
===
-h, --helpshow the help
-e, --editedit the commit message in an editor first
-m, --message message use the given message instead of that of HEAD
-p, --parent commit new parent to use; may be given multiple times
--no-parent create a parentless commit
-q, --quiet be quiet; only report errors
--no-resetprint the new object id instead of updating HEAD
INSTALLATION
Make executable and place somewhere in your $PATH.
EXAMPLES
Reparenting the tip of a branch
---
Suppose we create some commit *B* and then accidentally pass the ``--amend``
flag when creating new commit *C*, resulting in the following history::
B
/
...---A---C (HEAD)
What we really wanted was one linear history, ``...---A--B--C``. If we
were to use ``git rebase`` or ``git cherry-pick`` to reconstruct the history,
this would try to apply the *diff* of *A..C* onto *B*, which might fail.
Instead, what we really want to do is use the exact message and tree from *C*
but with parent *B* instead of *A*. To do this, we run ::
$ git reparent -p B
where the name *B* can be found by running ``git reflog`` and looking for the
first commit (amend). The resulting history is now just what we wanted::
C
/
...---A---B---C' (HEAD)
Reparenting an inner commit
---
We can also update the parents of a commit other than the most recent.
Suppose that we want to perform a rebase-like operation, moving *master* onto
*origin/master*, but we want to completely ignore any changes made in the
remote branch. That is, our history currently looks like this::
B---C (master, HEAD)
/
...---A---D---E (origin/master)
and we want to make it look like this::
B---C (origin/master)
/ /
...---A---D---E---B'---C' (master, HEAD)
We can accomplish this by using ``git rebase --interactive`` along with ``git
reparent``::
$ git rebase -i A
# select the edit command for commit B
# git rebase will dump us out at commit B
$ git reparent -p origin/master
$ git rebase --continue
Now the history will look as desired, and the trees, commit messages, and
authors of *B'* and *C'* will be identical to those of *B* and *C*,
respectively.
SEE ALSO
git-filter-branch(1) combined with either git grafts or git-replace(1) can be
used to achieve the same effect
git-rebase(1) can be used to re-apply the *diffs* of the current branch to
another
AUTHOR
==
Mark Lodato loda...@gmail.com
--- 8 ---
#!/bin/sh
# Copyright (c) Mark Lodato, 2013
OPTIONS_SPEC=\
git reparent [OPTIONS] ((-p parent)... | --no-parent)
Recommit HEAD with a new set of parents.
--
h,help show the help
e,edit edit the commit message in an editor first
m,message= use the given message instead of that of HEAD
p,parent=! new parent to use; may be given multiple times
no-parent! create a parentless commit
q,quiet be quiet; only report errors
reset* default behavior
no-reset! print the new object id instead of updating HEAD
SUBDIRECTORY_OK=Yes
. $(git --exec-path)/git-sh-setup || exit $?
require_clean_work_tree reparent Please commit or stash them first.
# Location of the temporary message.
msg_file=$GIT_DIR/reparent-msg
die_with_usage() {
echo error: $1 2
usage
}
edit=
message=
no_parent=
no_reset=
parent_flags=
quiet=
while [ $# -gt 0 ]; do
case $1 in
-p)
[ $# -eq 0 ] die_with_usage -p requires an argument
shift
parent_flags=$parent_flags$(git rev-parse --sq-quote -p $1)
;;
--no-parent) no_parent=1 ;;
-e) edit=1 ;;
--no-edit) edit= ;;
-m) message=$2; shift ;;
--no-message)message
