* bug? git format-patch -M -D then git am fails
From: Joe Perches @ 2012-11-13 22:41 UTC (permalink / raw)
To: git; +Cc: David Miller
If a file is deleted with git rm and a patch
is then generated with git format-patch -M -
^ permalink raw reply
* bug? git format-patch -M -D then git am fails
From: Joe Perches @ 2012-11-13 22:45 UTC (permalink / raw)
To: git; +Cc: David Miller
(Sorry about the partial message.
evolution and ctrl-enter sends, grumble...)
If a file is deleted with git rm and a patch
is then generated with git format-patch -M -D
git am is unable to apply the resultant patch.
Is this working as designed?
^ permalink raw reply
* Re: bug? git format-patch -M -D then git am fails
From: Junio C Hamano @ 2012-11-13 22:55 UTC (permalink / raw)
To: Joe Perches; +Cc: git, David Miller
In-Reply-To: <1352846721.17444.24.camel@joe-AO722>
Joe Perches <joe@perches.com> writes:
> (Sorry about the partial message.
> evolution and ctrl-enter sends, grumble...)
>
> If a file is deleted with git rm and a patch
> is then generated with git format-patch -M -D
> git am is unable to apply the resultant patch.
>
> Is this working as designed?
I would say it is broken as designed and it is even documented.
Please run "git format-patch --help | less" and then type
"/--irreversible-delete" to find:
The resulting patch is not meant to be applied with patch nor
git apply; this is solely for people who want to just
concentrate on reviewing the text after the change.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
From: Junio C Hamano @ 2012-11-13 22:57 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20121113175205.GA26960@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> What's cooking in git.git (Nov 2012, #03; Tue, 13)
> --------------------------------------------------
>
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.
>
> This is my final "what's cooking" as interim maintainer. I didn't
> graduate anything to master, but I updated my plans for each topic to
> give Junio an idea of where I was.
>
> You can find the changes described here in the integration branches of
> my repository at:
>
> git://github.com/peff/git.git
>
> Until Junio returns, kernel.org and the other "usual" places will not be
> updated.
And now the "usual places" have been updated with the same tips of
integration branches (the broken-out https://github.com/gitster/git
repository, too).
^ permalink raw reply
* Re: bug? git format-patch -M -D then git am fails
From: Joe Perches @ 2012-11-13 23:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Miller
In-Reply-To: <7vsj8dcdv6.fsf@alter.siamese.dyndns.org>
On Tue, 2012-11-13 at 14:55 -0800, Junio C Hamano wrote:
> Joe Perches <joe@perches.com> writes:
>
> > (Sorry about the partial message.
> > evolution and ctrl-enter sends, grumble...)
> >
> > If a file is deleted with git rm and a patch
> > is then generated with git format-patch -M -D
> > git am is unable to apply the resultant patch.
> >
> > Is this working as designed?
>
> I would say it is broken as designed and it is even documented.
>
> Please run "git format-patch --help | less" and then type
> "/--irreversible-delete" to find:
>
> The resulting patch is not meant to be applied with patch nor
> git apply; this is solely for people who want to just
> concentrate on reviewing the text after the change.
yeah, it's just that not using -D can result in
some unfortunately large patches being sent to
mailing lists. I don't believe that reversibility
is a really useful aspect of deletion patches
when there are known git repositories involved.
cheers, Joe
^ permalink raw reply
* Re: [PATCH 2/2] pickaxe: use textconv for -S counting
From: Junio C Hamano @ 2012-11-13 23:13 UTC (permalink / raw)
To: Jeff King; +Cc: Peter Oberndorfer, git
In-Reply-To: <20121028124701.GB24548@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> We currently just look at raw blob data when using "-S" to
> pickaxe. This is mostly historical, as pickaxe predates the
> textconv feature. If the user has bothered to define a
> textconv filter, it is more likely that their search string will be
> on the textconv output, as that is what they will see in the
> diff (and we do not even provide a mechanism for them to
> search for binary needles that contain NUL characters).
Oookay, I suppose...
> static int has_changes(struct diff_filepair *p, struct diff_options *o,
> regex_t *regexp, kwset_t kws)
> {
> + struct userdiff_driver *textconv_one = get_textconv(p->one);
> + struct userdiff_driver *textconv_two = get_textconv(p->two);
> + mmfile_t mf1, mf2;
> + int ret;
> +
> if (!o->pickaxe[0])
> return 0;
>
> - if (!DIFF_FILE_VALID(p->one)) {
> - if (!DIFF_FILE_VALID(p->two))
> - return 0; /* ignore unmerged */
What happened to this part that avoids showing nonsense for unmerged
paths?
> + /*
> + * If we have an unmodified pair, we know that the count will be the
> + * same and don't even have to load the blobs. Unless textconv is in
> + * play, _and_ we are using two different textconv filters (e.g.,
> + * because a pair is an exact rename with different textconv attributes
> + * for each side, which might generate different content).
> + */
> + if (textconv_one == textconv_two && diff_unmodified_pair(p))
> + return 0;
I am not sure about this part that cares about the textconv.
Wouldn't the normal "git diff A B" skip the filepair that are
unmodified in the first place at the object name level without even
looking at the contents (see e.g. diff_flush_patch())?
Shouldn't this part of the code emulating that behaviour no matter
what textconv filter(s) are configured for these paths?
^ permalink raw reply
* Re: bug? git format-patch -M -D then git am fails
From: Junio C Hamano @ 2012-11-13 23:22 UTC (permalink / raw)
To: Joe Perches; +Cc: git, David Miller
In-Reply-To: <1352847962.17444.27.camel@joe-AO722>
Joe Perches <joe@perches.com> writes:
> I don't believe that reversibility
> is a really useful aspect of deletion patches
> when there are known git repositories involved.
You can read "reversibility" as "safety" if you want. We would want
to make sure we know what we are deleting before deleting a path.
The history that the receiver of such a patch has may have further
changes that are relevant that the sender of the deletion patch did
not know about, and removing the path in such a case would make the
result inconsistent. If the sender did his work on top of the newer
version with the change in the path, the sender's patch may still
have deleted the path but would have had changes to other paths to
compensate for the loss of that change.
^ permalink raw reply
* Re: checkout from neighbour branch undeletes a path?
From: Junio C Hamano @ 2012-11-13 23:41 UTC (permalink / raw)
To: Peter Vereshagin; +Cc: git
In-Reply-To: <20121113152341.GC6561@external.screwed.box>
Peter Vereshagin <peter@vereshagin.org> writes:
> $ rm -r pathdir
> $ git checkout branch00 pathdir
> $ find pathdir/
> pathdir/
> pathdir/file00.txt
> pathdir/file01.txt
> $
Hasn't this been fixed at 0a1283b (checkout $tree $path: do not
clobber local changes in $path not in $tree, 2011-09-30)?
Are you using 1.7.7.1 or newer? If not, please upgrade.
^ permalink raw reply
* Re: Fwd: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
From: SZEDER Gábor @ 2012-11-13 23:46 UTC (permalink / raw)
To: Marc Khouzam; +Cc: git, felipe.contreras
In-Reply-To: <CAFj1UpGxx_9GHSnJRpe8hDGB6OTio1mcN71LKcR0pxhSVx2xDw@mail.gmail.com>
Hi,
On Tue, Nov 13, 2012 at 03:12:44PM -0500, Marc Khouzam wrote:
> >> +if [ -n "$1" ] ; then
> >> + # If there is an argument, we know the script is being executed
> >> + # so go ahead and run the _git_complete_with_output function
> >> + _git_complete_with_output "$1" "$2"
> >
> > Where does the second argument come from? Below you run this script
> > as '${__git_tcsh_completion_script} "${COMMAND_LINE}"', i.e. $2 is
> > never set. Am I missing something?
>
> This second argument is optional and, if present, will be put in
> $COMP_CWORD. If not present, $COMP_CWORD must be computed
> from $1. Also see comment above _git_complete_with_output ().
> tcsh does not provide me with this information, so I cannot make use of it.
> However, I thought it would be more future-proof to allow it for other shells
> which may have that information.
>
> It is not necessary for tcsh, so I can remove if you prefer?
I see. I read those comments and understood what it is about. I was
just surprised that the code is there to make use of it, yet it's not
specified when invoking that function.
Since it's a trivial piece of code, I would say let's keep it. Could
you please add a sentence about it (that it's for possible future
users and it's not used at the moment) to the commit message for
future reference?
> >> +complete git 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
> >> | sort | uniq`/'
> >> +complete gitk 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
> >> | sort | uniq`/'
> >
> > Is the 'sort | uniq' really necessary? After the completion function
> > returns Bash automatically sorts the elements in COMPREPLY and removes
> > any duplicates. Doesn't tcsh do the same? I have no idea about tcsh
> > completion.
>
> On my machine, tcsh does not remove duplicates. It does sort the results
> but that is done after I've run 'uniq', which is too late. I'm not
> happy about this
> either, but the other option is to improve git-completion.bash to
> avoid duplicates,
> which seemed less justified.
Ok. Then keep it for the time being, and we'll see what we can do to
avoid those duplicates.
> > Does the git completion script returns any duplicates at all?
>
> It does. 'help' is returned twice for example.
Right. Now that you mentioned it, I remember I noticed it a while
ago, too. I even wrote a patch to fix it, but not sure what became of
it. Will try to dig it up.
> Also, when completing 'git checkout ' in the git repo, I can see multiple
> 'todo' branches, as well as 'master', 'pu', 'next', etc.
>
> You can actually try it without tcsh by running my proposed version of
> git-completion.bash like this:
>
> cd git/contrib/completion
> bash git-completion.bash "git checkout " | sort | uniq --repeated
Interesting, I can't reproduce. Are the duplicates also there, if you
start a bash, source git-completion.bash, and run __git_refs ?
^ permalink raw reply
* Re: [PATCHv3 3/4] git-status: show short sequencer state
From: Phil Hord @ 2012-11-13 23:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, phil.hord, Jeff King, konglu, Matthieu Moy, Kong Lucien,
Duperray Valentin, Jonas Franck, Nguy Thomas
In-Reply-To: <50A13C9A.8070108@cisco.com>
Phil Hord wrote:
> Junio C Hamano wrote:
>> Phil Hord <hordp@cisco.com> writes:
>>
>>> State token strings which may be emitted and their meanings:
>>> merge a merge is in progress
>>> am an am is in progress
>>> am-is-empty the am patch is empty
>>> rebase a rebase is in progress
>>> rebase-interactive an interactive rebase is in progress
>>> cherry-pick a cherry-pick is in progress
>>> bisect a bisect is in progress
>>> conflicted there are unresolved conflicts
>>> commit-pending a commit operation is waiting to be completed
>>> splitting interactive rebase, commit is being split
>>>
>>> I also considered adding these tokens, but I decided it was not
>>> appropriate since these changes are not sequencer-related. But
>>> it is possible I am being too short-sighted or have chosen the
>>> switch name poorly.
>>> changed-index Changes exist in the index
>>> changed-files Changes exist in the working directory
>>> untracked New files exist in the working directory
>> I tend to agree; unlike all the normal output from "status -s" that
>> are per-file, the above are the overall states of the working tree.
>>
>> It is just that most of the "overall states" look as if they are
>> dominated by "sequencer states", but that is only because you chose
>> to call states related to things like "am" and "bisect" that are not
>> sequencer states as such.
>>
>> It probably should be called the tree state, working tree state, or
>> somesuch.
> I think you are agreeing that I chose the switch name poorly, right?
>
> Do you think '--tree-state' is an acceptable switch or do you have other
> suggestions?
>
I've been calling these 'tokens' myself. A token is a word-or-phrase I
can parse easily with the default $IFS, for simpler script handling.
I'm happy to make that official and use --tokens and -T, but I suspect a
more appropriate name is available.
Phil
^ permalink raw reply
* Re: [PATCH v3 0/5] push: update remote tags only with force
From: Drew Northup @ 2012-11-13 23:58 UTC (permalink / raw)
To: Chris Rorvick
Cc: git, Angelo Borsotti, Michael Haggerty, Philip Oakley,
Johannes Sixt, Kacper Kornet, Jeff King, Felipe Contreras,
Junio C Hamano
In-Reply-To: <1352693288-7396-1-git-send-email-chris@rorvick.com>
On Sun, Nov 11, 2012 at 11:08 PM, Chris Rorvick <chris@rorvick.com> wrote:
> Minor changes since from v2 set.
.....
> An email thread initiated by Angelo Borsotti did not come to a
> consensus on how push should behave with regard to tag references.
Minor Nit: Without the link to gmane it is an exercise left to the
reviewer to find that you're talking about this thread:
http://thread.gmane.org/gmane.comp.version-control.git/208354
Cheers.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Fwd: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
From: SZEDER Gábor @ 2012-11-14 0:09 UTC (permalink / raw)
To: Marc Khouzam; +Cc: git
In-Reply-To: <CAFj1UpFd9X8Jq5o7B4m35i=merBDvOo4NOtwth=UnG2S5X_rGw@mail.gmail.com>
Hi,
I've got two more comments.
On Mon, Nov 12, 2012 at 03:07:46PM -0500, Marc Khouzam wrote:
> @@ -2481,3 +2483,52 @@ __git_complete gitk __gitk_main
> if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
> __git_complete git.exe __git_main
> fi
> +
> +# Method that will output the result of the completion done by
> +# the bash completion script, so that it can be re-used in another
> +# context than the bash complete command.
> +# It accepts 1 to 2 arguments:
> +# 1: The command-line to complete
> +# 2: The index of the word within argument #1 in which the cursor is
> +# located (optional). If parameter 2 is not provided, it will be
> +# determined as best possible using parameter 1.
> +_git_complete_with_output ()
We differentiate between _git_whatever() and __git_whatever()
functions. The former performs completion for the 'whatever' git
command/alias, the latter is a completion helper function. This
is a helper function, so it should begin with double underscores.
> +{
> + # Set COMP_WORDS to the command-line as bash would.
> + COMP_WORDS=($1)
> +
> + # Set COMP_CWORD to the cursor location as bash would.
> + if [ -n "$2" ]; then
A while ago the completion script was made 'set -u'-clean. (If 'set
-u' is enabled, then it's an error to access undefined variables).
I'm not sure how many people are out there who'd use this script for
tcsh while having 'set -u' in their profile... probably not that
many. Still, I think it would be great to keep it up.
Here $2 would be undefined, so accessingit it would cause an error
under those semantincs. Please use ${2-} instead (use empty string
when undefined).
> +if [ -n "$1" ] ; then
Same here.
> + # If there is an argument, we know the script is being executed
> + # so go ahead and run the _git_complete_with_output function
> + _git_complete_with_output "$1" "$2"
And here.
Thanks
Gábor
^ permalink raw reply
* Re: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
From: SZEDER Gábor @ 2012-11-14 0:11 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Marc Khouzam, git
In-Reply-To: <CAMP44s3imos4DksroRkZ3K6una5H916gvtqttJQna8yGG8XhsQ@mail.gmail.com>
On Tue, Nov 13, 2012 at 07:31:45PM +0100, Felipe Contreras wrote:
> On Mon, Nov 12, 2012 at 9:07 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
> > + # Call _git() or _gitk() of the bash script, based on the first
> > + # element of the command-line
> > + _${COMP_WORDS[0]}
>
> You might want to use __${COMP_WORDS[0]}_main instead.
That wouldn't work. __git_main() doesn't set up the
command-line-specific variables, but the wrapper around it does.
> > +# Make the script executable if it is not
> > +if ( ! -x ${__git_tcsh_completion_script} ) then
> > + chmod u+x ${__git_tcsh_completion_script}
> > +endif
>
> Why not just source it?
The goal is to re-use a Bash script to do completion in tcsh. They
are two different breeds, tcsh doesn't grok bash. So sourcing the
completion script is not an option, but we can still run it via Bash
and use it's results.
^ permalink raw reply
* [PATCH] completion: remove 'help' duplicate from porcelain commands
From: SZEDER Gábor @ 2012-11-14 0:49 UTC (permalink / raw)
To: Marc Khouzam, git, Junio C Hamano; +Cc: felipe.contreras
In-Reply-To: <20121113234636.GS12052@goldbirke>
The list of all git commands is computed from the output of 'git help
-a', which already includes 'help', so there is no need to explicitly
add it once more when computing the list of porcelain commands.
Note that 'help' wasn't actually offered twice because of this,
because Bash filters duplicates from possible completion words.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
> > > Does the git completion script returns any duplicates at all?
> >
> > It does. 'help' is returned twice for example.
>
> Right. Now that you mentioned it, I remember I noticed it a while
> ago, too. I even wrote a patch to fix it, but not sure what became of
> it. Will try to dig it up.
Here it is. It turns out I wrote it in May this year, but according to
gmane and my mailbox never sent it out.
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index bc0657a2..b7b1a834 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -585,7 +585,7 @@ __git_list_porcelain_commands ()
{
local i IFS=" "$'\n'
__git_compute_all_commands
- for i in "help" $__git_all_commands
+ for i in $__git_all_commands
do
case $i in
*--*) : helper pattern;;
--
1.8.0.128.g441b4b3
^ permalink raw reply related
* Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
From: Mark Levedahl @ 2012-11-14 1:18 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Jeff King, git
In-Reply-To: <50A2B14C.9040608@web.de>
On 11/13/2012 03:45 PM, Torsten Bögershausen wrote:
>> * ml/cygwin-mingw-headers (2012-11-12) 1 commit
>> - Update cygwin.c for new mingw-64 win32 api headers
>>
>> Make git work on newer cygwin.
>>
>> Will merge to 'next'.
> (Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu)
> (And thanks for maintaining git)
>
> Is everybody using cygwin happy with this?
>
> I managed to compile on a fresh installed cygwin,
> but failed to compile under 1.7.7, see below.
> Is there a way we can achieve to compile git both under "old" and "new" cygwin 1.7 ?
> Or is this not worth the effort?
> /Torsten
>
>
>
I found no version info defined that could be used to automatically
switch between the old and current headers. You can always
make V15_MINGW_HEADERS=1 ...
to force using the old set if you do not wish to update your installation.
Mark
^ permalink raw reply
* Re: Bug? Subtree merge seems to choke on trailing slashes.
From: Jack O'Connor @ 2012-11-14 2:17 UTC (permalink / raw)
To: git
In-Reply-To: <CA+6di1m7OCMjahP9sN3NcYdxLRRi4vmttFa5=pnHrgKp=E4+jQ@mail.gmail.com>
Do I have the right list for bug reports? Apologies if not.
On Tue, Nov 6, 2012 at 5:58 PM, Jack O'Connor <oconnor663@gmail.com> wrote:
>
> I'm summarizing from here:
> http://stackoverflow.com/questions/5904256/git-subtree-merge-into-a-deeply-nested-subdirectory
>
> Quick repro:
> 1) I do an initial subtree merge in what I think is the standard way
> (http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html).
> My prefix is simply "test/".
> 2) I try to merge more upstream changes on top of that with the
> following command:
> git merge --strategy-option=subtree='test/' $upstream_stuff
> 3) Git fails with an obscure error:
> fatal: entry not found in tree daf4d0f0a20b8b6ec007be9fcafeac84a6eba4f0
>
> If I remove the trailing slash from the command in step 2, it works just fine:
> git merge --strategy-option=subtree='test' $upstream_stuff
>
> Note in the error message above, there's a double space after "entry".
> Is it looking for a tree with an empty name? Did my trailing slash
> imply a directory named empty-string?
>
> Thanks for your help.
>
> -- Jack O'Connor
^ permalink raw reply
* Re: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
From: Marc Khouzam @ 2012-11-14 3:36 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, SZEDER Gábor
In-Reply-To: <CAMP44s3imos4DksroRkZ3K6una5H916gvtqttJQna8yGG8XhsQ@mail.gmail.com>
Thanks for the review. I wasn't aware that you were doing
a similar effort for zsh.
On Tue, Nov 13, 2012 at 1:31 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Nov 12, 2012 at 9:07 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
>
>> this patch allows tcsh-users to get the benefits of the awesome
>> git-completion.bash script. It could also help other shells do the same.
>
> Maybe you can try to take a look at the same for zsh:
> http://article.gmane.org/gmane.comp.version-control.git/208173
Cool. The major difference is that (as Gábor mentioned) zsh understands bash
syntax but tcsh does not. tcsh doesn't even allow to define
functions. So we have
to take a different approach to get the bash completion script to be
used by tcsh.
>> ---
>> contrib/completion/git-completion.bash | 53 +++++++++++++++++++++++++++++++-
>> contrib/completion/git-completion.tcsh | 34 ++++++++++++++++++++
>> 2 files changed, 86 insertions(+), 1 deletions(-)
>> create mode 100755 contrib/completion/git-completion.tcsh
>>
>> diff --git a/contrib/completion/git-completion.bash
>> b/contrib/completion/git-completion.bash
>> index be800e0..6d4b57a 100644
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -1,4 +1,6 @@
>> -#!bash
>> +#!/bin/bash
>> +# The above line is important as this script can be executed when used
>> +# with another shell such as tcsh
>> #
>> # bash/zsh completion support for core Git.
>> #
>> @@ -2481,3 +2483,52 @@ __git_complete gitk __gitk_main
>> if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
>> __git_complete git.exe __git_main
>> fi
>> +
>> +# Method that will output the result of the completion done by
>> +# the bash completion script, so that it can be re-used in another
>> +# context than the bash complete command.
>> +# It accepts 1 to 2 arguments:
>> +# 1: The command-line to complete
>> +# 2: The index of the word within argument #1 in which the cursor is
>> +# located (optional). If parameter 2 is not provided, it will be
>> +# determined as best possible using parameter 1.
>> +_git_complete_with_output ()
>> +{
>> + # Set COMP_WORDS to the command-line as bash would.
>> + COMP_WORDS=($1)
>> +
>> + # Set COMP_CWORD to the cursor location as bash would.
>> + if [ -n "$2" ]; then
>> + COMP_CWORD=$2
>> + else
>> + # Assume the cursor is at the end of parameter #1.
>> + # We must check for a space as the last character which will
>> + # tell us that the previous word is complete and the cursor
>> + # is on the next word.
>> + if [ "${1: -1}" == " " ]; then
>> + # The last character is a space, so our
>> location is at the end
>> + # of the command-line array
>> + COMP_CWORD=${#COMP_WORDS[@]}
>> + else
>> + # The last character is not a space, so our
>> location is on the
>> + # last word of the command-line array, so we
>> must decrement the
>> + # count by 1
>> + COMP_CWORD=$((${#COMP_WORDS[@]}-1))
>> + fi
>> + fi
>> +
>> + # Call _git() or _gitk() of the bash script, based on the first
>> + # element of the command-line
>> + _${COMP_WORDS[0]}
>
> You might want to use __${COMP_WORDS[0]}_main instead.
>
>> +
>> + # Print the result that is stored in the bash variable ${COMPREPLY}
>> + for i in ${COMPREPLY[@]}; do
>> + echo "$i"
>> + done
>> +}
>> +
>> +if [ -n "$1" ] ; then
>> + # If there is an argument, we know the script is being executed
>> + # so go ahead and run the _git_complete_with_output function
>> + _git_complete_with_output "$1" "$2"
>> +fi
>
> Why do you need this function in this file? You can very easily add
> this function to git-completion.tcsh.
tcsh does not allow to define functions, so it is not aware of any
of the git-completion.bash functions. So, git-completion.tcsh
cannot call anything from git-completion.bash.
>> diff --git a/contrib/completion/git-completion.tcsh
>> b/contrib/completion/git-completion.tcsh
>> new file mode 100755
>> index 0000000..7b7baea
>> --- /dev/null
>> +++ b/contrib/completion/git-completion.tcsh
>> @@ -0,0 +1,34 @@
>> +#!tcsh
>> +#
>> +# tcsh completion support for core Git.
>> +#
>> +# Copyright (C) 2012 Marc Khouzam <marc.khouzam@gmail.com>
>> +# Distributed under the GNU General Public License, version 2.0.
>> +#
>> +# This script makes use of the git-completion.bash script to
>> +# determine the proper completion for git commands under tcsh.
>> +#
>> +# To use this completion script:
>> +#
>> +# 1) Copy both this file and the bash completion script to your
>> ${HOME} directory
>> +# using the names ${HOME}/.git-completion.tcsh and
>> ${HOME}/.git-completion.bash.
>> +# 2) Add the following line to your .tcshrc/.cshrc:
>> +# source ${HOME}/.git-completion.tcsh
>> +
>> +# One can change the below line to use a different location
>> +set __git_tcsh_completion_script = ${HOME}/.git-completion.bash
>> +
>> +# Check that the user put the script in the right place
>> +if ( ! -e ${__git_tcsh_completion_script} ) then
>> + echo "ERROR in git-completion.tcsh script. Cannot find:
>> ${__git_tcsh_completion_script}. Git completion will not work."
>> + exit
>> +endif
>> +
>> +# Make the script executable if it is not
>> +if ( ! -x ${__git_tcsh_completion_script} ) then
>> + chmod u+x ${__git_tcsh_completion_script}
>> +endif
>
> Why not just source it?
>
>> +complete git 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
>> | sort | uniq`/'
>> +complete gitk 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
>> | sort | uniq`/'
>
> This seems to be very different from bash's 'complete'. I wonder if
> the 'complete' commands in the original script cause any problems.
> Maybe only if you source it, but then again, I would expect a warning
> or something when you run it.
If you source the script under tcsh it will fail miserably because the bash
syntax is very different. But when you run it, it runs under the bash shell
so everything will work fine. The 'complete' command in the bash script
will run, but will only affect the temporary bash shell that was started
to run the script. Useless but harmless.
> But you can use the trick I did with zsh so you can source it:
>
> complete ()
> {
> # do nothing
> return 0
> }
>
> . "$script"
This is pretty cool. Function overriding in shell scripts! tcsh doesn't
even have functions, so that trick is out of its league :)
Thanks
Marc
^ permalink raw reply
* Re: Fwd: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
From: Marc Khouzam @ 2012-11-14 4:26 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git, felipe.contreras
In-Reply-To: <20121113234636.GS12052@goldbirke>
On Tue, Nov 13, 2012 at 6:46 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
> Hi,
>
> On Tue, Nov 13, 2012 at 03:12:44PM -0500, Marc Khouzam wrote:
>> >> +if [ -n "$1" ] ; then
>> >> + # If there is an argument, we know the script is being executed
>> >> + # so go ahead and run the _git_complete_with_output function
>> >> + _git_complete_with_output "$1" "$2"
>> >
>> > Where does the second argument come from? Below you run this script
>> > as '${__git_tcsh_completion_script} "${COMMAND_LINE}"', i.e. $2 is
>> > never set. Am I missing something?
>>
>> This second argument is optional and, if present, will be put in
>> $COMP_CWORD. If not present, $COMP_CWORD must be computed
>> from $1. Also see comment above _git_complete_with_output ().
>> tcsh does not provide me with this information, so I cannot make use of it.
>> However, I thought it would be more future-proof to allow it for other shells
>> which may have that information.
>>
>> It is not necessary for tcsh, so I can remove if you prefer?
>
> I see. I read those comments and understood what it is about. I was
> just surprised that the code is there to make use of it, yet it's not
> specified when invoking that function.
>
> Since it's a trivial piece of code, I would say let's keep it. Could
> you please add a sentence about it (that it's for possible future
> users and it's not used at the moment) to the commit message for
> future reference?
Will do.
>> >> +complete git 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
>> >> | sort | uniq`/'
>> >> +complete gitk 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
>> >> | sort | uniq`/'
>> >
>> > Is the 'sort | uniq' really necessary? After the completion function
>> > returns Bash automatically sorts the elements in COMPREPLY and removes
>> > any duplicates. Doesn't tcsh do the same? I have no idea about tcsh
>> > completion.
>>
>> On my machine, tcsh does not remove duplicates. It does sort the results
>> but that is done after I've run 'uniq', which is too late. I'm not
>> happy about this
>> either, but the other option is to improve git-completion.bash to
>> avoid duplicates,
>> which seemed less justified.
>
> Ok. Then keep it for the time being, and we'll see what we can do to
> avoid those duplicates.
Thanks.
>> > Does the git completion script returns any duplicates at all?
>>
>> It does. 'help' is returned twice for example.
>
> Right. Now that you mentioned it, I remember I noticed it a while
> ago, too. I even wrote a patch to fix it, but not sure what became of
> it. Will try to dig it up.
Thanks for already posting the patch.
>> Also, when completing 'git checkout ' in the git repo, I can see multiple
>> 'todo' branches, as well as 'master', 'pu', 'next', etc.
>>
>> You can actually try it without tcsh by running my proposed version of
>> git-completion.bash like this:
>>
>> cd git/contrib/completion
>> bash git-completion.bash "git checkout " | sort | uniq --repeated
>
> Interesting, I can't reproduce. Are the duplicates also there, if you
> start a bash, source git-completion.bash, and run __git_refs ?
Running __git_refs does not show the duplicates, but running
__git refs '' 1
does show them.
That second parameter causes __git_refs to
"use the guess heuristic employed by checkout for tracking branches"
I don't quite understand this, but what I can see is that my remote
branches GitHub/master and origin/master each cause another
'master' to be listed:
$ __git_refs '' 1|grep master
master
GitHub/master
origin/master
master
master
All fixes are done and I'll post a second version of the patch
as soon as I can figure out the formatting properly.
Thanks again
Marc
^ permalink raw reply
* [PATCH] config: don't segfault when given --path with a missing value
From: Carlos Martín Nieto @ 2012-11-14 4:50 UTC (permalink / raw)
To: git
When given a variable without a value, such as '[section] var' and
asking git-config to treat it as a path, git_config_pathname returns
an error and doesn't modify its output parameter. show_config assumes
that the call is always successful and sets a variable to indicate
that vptr should be freed. In case of an error however, trying to do
this will cause the program to be killed, as it's pointing to memory
in the stack.
Set the must_free_vptr flag depending on the return value of
git_config_pathname so it's accurate.
---
builtin/config.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index 442ccc2..60220d5 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -129,8 +129,7 @@ static int show_config(const char *key_, const char *value_, void *cb)
else
sprintf(value, "%d", v);
} else if (types == TYPE_PATH) {
- git_config_pathname(&vptr, key_, value_);
- must_free_vptr = 1;
+ must_free_vptr = !git_config_pathname(&vptr, key_, value_);
} else if (value_) {
vptr = value_;
} else {
--
1.8.0.316.g291341c
^ permalink raw reply related
* Re: [PATCH v3 0/5] push: update remote tags only with force
From: Chris Rorvick @ 2012-11-14 6:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <CAEUsAPYvrR6WsVWCvwoEWA21gzL6Sib0sTyx-c_2tH=8ni69yQ@mail.gmail.com>
resending to list ...
On Tue, Nov 13, 2012 at 3:20 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Chris Rorvick <chris@rorvick.com> writes:
>
>> Minor changes since from v2 set. Reposting primarily because I mucked
>> up the Cc: list (again) and hoping to route feedback to the appropriate
>> audience.
>>
>> This patch set can be divided into two sets:
>>
>> 1. Provide useful advice for rejected tag references.
>>
>> push: return reject reasons via a mask
>> push: add advice for rejected tag reference
>>
>> Recommending a merge to resolve a rejected tag update seems
>> nonsensical since the tag does not come along for the ride. These
>> patches change the advice for rejected tags to suggest using
>> "push -f".
>
> Below, I take that you mean by "tag reference" everything under
> refs/tags/ (not limited to "annotated tag objects", but also
> lightweight tags).
Yes.
> Given that the second point below is to strongly discourage updating
> of existing any tag, it might be even better to advise *not* to push
> tags in the first place, instead of destructive "push -f", no?
That does seem like a better idea. Read the full manual page to
figure out how to force the update if that's what you want to do--the
advice should not suggest something exceptional.
>> 2. Require force when updating tag references, even on a fast-forward.
>>
>> push: flag updates
>> push: flag updates that require force
>> push: update remote tags only with force
>>
>> An email thread initiated by Angelo Borsotti did not come to a
>> consensus on how push should behave with regard to tag references.
>
> I think the original motivation of allowing fast-forward updates to
> tags was for people who wanted to have "today's recommended version"
> tag that can float from day to day. I tend to think that was a
> misguided notion and it is better implemented with a tip of a
> branch (iow, I personally am OK with the change to forbid tag
> updates altogether, without --force).
>
>> I think a key point is that you currently cannot be sure your push
>> will not clobber a tag (lightweight or not) in the remote.
>
> "Do not update, only add new" may be a good feature, but at the same
> time I have this suspicion that its usefulness may not necessarily
> be limited to refs/tags/* hierarchy.
>
> I dunno.
Are you suggesting allowing forwards for just refs/heads/*? I
initially went this route based on some feedback in the original
thread, but being that specific broke a couple tests in t5516 (i.e.,
pushing to refs/remotes/origin/master and another into refs/tmp/*.)
My initial thought was that I'd broken something and I need to modify
the patch, but now I think I should just modify those tests. Branches
are restricted to refs/heads/* (if I understand correctly), so
allowing fast-forwards when pushing should be limited to this
hierarchy, too.
Thanks,
Chris
^ permalink raw reply
* push branch descriptions
From: Angelo Borsotti @ 2012-11-14 7:20 UTC (permalink / raw)
To: git
Hi
currently, there is no means to push a branch description to a remote
repository. It is possible to create a branch, but not to set its
description.
Would not be more correct to push also branch descriptions when
branches are pushed?
-Angelo Borsotti
^ permalink raw reply
* merge --squash detects a nonexistent error
From: Angelo Borsotti @ 2012-11-14 7:26 UTC (permalink / raw)
To: git
Hello,
I have got a case in which merge --squash issues an error that does
not exist. I hope I am wrong, though.
Consider the following example:
rm -rf public.git
rm -rf private
git init --bare public.git
git clone public.git private
cd private
touch f1; git add f1; git commit -m A
git checkout -b b1
touch f2; git add f2; git commit -m B
git checkout master
git checkout -b b2
touch f3; git add f3; git commit -m C
git checkout master
git checkout -b b3
touch f4; git add f4; git commit -m D
--- at this point we have
A (f1) master
|--B (f1,f2) b1
|--C (f1,f3) b2
`--D (f1,f4) *b3
git merge --squash b1
git merge --squash b2
The first merge adds f2 to the workspace, which then contains f1, f2 and f4.
The second merge should add f3, and instead it complains:
error: Your local changes to the following files would be overwritten by merge:
f2
Please, commit your changes or stash them before you can merge.
Aborting
Why should it overwrite f2, and with what?
-Angelo Borsotti
^ permalink raw reply
* How to setup gitweb with categories
From: frank.jakop @ 2012-11-14 7:50 UTC (permalink / raw)
To: git
Hello,
I'm trying to setup a gitweb frontend with categorized projects. I already
have a plain project list running an changed my gitweb.conf so that it
contains
our $projects_list_group_categories = "1";
our $project_list_default_category = "foo";
I'd now expect all projects to be shown under the category "foo", but upon
reload nothing happens on the web page.
Can anyone tell me what's wrong?
Best regards
Frank
^ permalink raw reply
* Re: [PATCH v3 0/5] push: update remote tags only with force
From: Kacper Kornet @ 2012-11-14 8:19 UTC (permalink / raw)
To: Chris Rorvick
Cc: Junio C Hamano, git, Angelo Borsotti, Drew Northup,
Michael Haggerty, Philip Oakley, Johannes Sixt, Jeff King,
Felipe Contreras
In-Reply-To: <CAEUsAPZtF-L5J_g1L5d44BKveoAnJ81PatX94fFS4FM=iW33KA@mail.gmail.com>
On Wed, Nov 14, 2012 at 12:29:14AM -0600, Chris Rorvick wrote:
> >> 2. Require force when updating tag references, even on a fast-forward.
> >> push: flag updates
> >> push: flag updates that require force
> >> push: update remote tags only with force
> >> An email thread initiated by Angelo Borsotti did not come to a
> >> consensus on how push should behave with regard to tag references.
> > I think the original motivation of allowing fast-forward updates to
> > tags was for people who wanted to have "today's recommended version"
> > tag that can float from day to day. I tend to think that was a
> > misguided notion and it is better implemented with a tip of a
> > branch (iow, I personally am OK with the change to forbid tag
> > updates altogether, without --force).
> >> I think a key point is that you currently cannot be sure your push
> >> will not clobber a tag (lightweight or not) in the remote.
> > "Do not update, only add new" may be a good feature, but at the same
> > time I have this suspicion that its usefulness may not necessarily
> > be limited to refs/tags/* hierarchy.
> > I dunno.
> Are you suggesting allowing forwards for just refs/heads/*? I
> initially went this route based on some feedback in the original
> thread, but being that specific broke a couple tests in t5516 (i.e.,
> pushing to refs/remotes/origin/master and another into refs/tmp/*.)
> My initial thought was that I'd broken something and I need to modify
> the patch, but now I think I should just modify those tests. Branches
> are restricted to refs/heads/* (if I understand correctly), so
> allowing fast-forwards when pushing should be limited to this
> hierarchy, too.
What about notes? I think they should be treated in the same way as
branches. My impression is that tags are exceptional in this respect.
--
Kacper
^ permalink raw reply
* Git does not understand absolute Win'dos' path
From: Martin Lichtin @ 2012-11-14 9:12 UTC (permalink / raw)
To: git@vger.kernel.org
Hi
Maven's release plugin prepares a call Git like in this example:
cmd.exe /X /C "git commit --verbose -F C:\cygwin\tmp\maven-scm-915771020.commit pom.xml"
Git doesn't seem to understand the -F argument and treats it like a relative path (relative to the repository root):
$ cmd.exe /X /C "git commit --verbose -F C:\cygwin\tmp\commit pom.xml"
fatal: could not read log file 'mytestdir/C:\cygwin\tmp\commit': No such file or directory
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox