* Re: [PATCH] Allow hand-editing of patches before sending
From: Jakub Narebski @ 2006-11-05 19:29 UTC (permalink / raw)
To: git
In-Reply-To: <20061105190400.GC25259@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> These are the headers that StGIT uses without my patch -- that is, the
> headers used to get that error message:
>
> Content-Type: text/plain; charset=utf-8; format=fixed
> Content-Transfer-Encoding: 8bit
>
> Which is obviously not good enough for some picky part of the SMTP
> chain.
I think you are missing MIME-Version: header.
[...]
> Well, it added these headers:
>
> MIME-Version: 1.0
> Content-Transfer-Encoding: QUOTED-PRINTABLE
> Content-Type: TEXT/PLAIN; charset=ISO-8859-1
>
> Maybe MIME-Version was the only thing missing? I'll have to try.
MIME-Version _is_ important. I remember that Outlook Express sent news
messages without this header, and those posts were either mangled by news
server, or news readers didn't parse MIME headers without MIME-Version:
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Karl Hasselström @ 2006-11-05 19:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andy Whitcroft, Catalin Marinas, git
In-Reply-To: <Pine.LNX.4.64.0611050831250.25218@g5.osdl.org>
On 2006-11-05 08:44:13 -0800, Linus Torvalds wrote:
> On Sun, 5 Nov 2006, Karl Hasselström wrote:
>
> > So the right thing to do would be to teach StGIT to generate
> > 8bit-encoded output, and trust the SMTP transfer path do mangle it
> > correctly? (Hmm. No, since StGIT talks directly with the first
> > SMTP server in the chain, it needs to be able to QP-encode the
> > mail itself if necessary -- but it should seldom be necessary,
> > then.)
>
> Right. You could even just consider it an error if the mailserver
> doesn't reply to EHLO with 8BITMIME, I really think it's that rare.
Makes sense (unless the Python SMTP library can do this for us -- it
would be impolite to refuse then).
> > In that case, the problem with the current implementation (without
> > my patch applied) is likely to be that it fails to provide the
> > headers needed for the SMTP path to be able to transform it
> > losslessly.
>
> I _think_ it should be sufficient to just set the Content-Type and
> Content-Transfer-Encoding to say something like "text/plain;
> charset=UTF8" and "8bit" respectively. But somebody who know the
> SMTP rules better should check.
These are the headers that StGIT uses without my patch -- that is, the
headers used to get that error message:
Content-Type: text/plain; charset=utf-8; format=fixed
Content-Transfer-Encoding: 8bit
Which is obviously not good enough for some picky part of the SMTP
chain.
> HOWEVER:
>
> > Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
> > id S1750700AbWJVMCV (ORCPT <rfc822;kha-list-git@hemma.treskal.com>);
> > Sun, 22 Oct 2006 08:02:21 -0400
> > X-Warning: Original message contained 8-bit characters, however during
> > the SMTP transport session the receiving system did not announce
> > capability of receiving 8-bit SMTP (RFC 1651-1653), and as this
> > message does not have MIME headers (RFC 2045-2049) to enable
> > encoding change, we had very little choice.
>
> This does seem to say that somebody didn't even announce 8-bit
> capability in the first place. That's a zmailer error message, and
> it does imply that somebody was running a bad server.
>
> That said, _if_ your message had had the proper mime-type
> specifiers, then zmailer would happily have QP-converted the message
> for you, so everything would have been fine.
E-mail seems to be like driving. You can't just follow the rules, you
also have to be careful to make allowances for those who don't. :-(
Well, it added these headers:
MIME-Version: 1.0
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Maybe MIME-Version was the only thing missing? I'll have to try.
> > The mail server (vger talking to itself, if the Received: headers
> > were added in order) complained that there were no MIME headers,
> > so it had to guess the charset.
>
> vger itself? Strange.
It looks that way, but I don't know enough about mail servers to be
very certain. The complete header of the message (in my git list
mailbox) is this:
From git-owner@vger.kernel.org Sun Oct 22 14:02:35 2006
Received: from vger.kernel.org ([209.132.176.167])
by diana.vm.bytemark.co.uk with esmtp (Exim 3.36 #1 (Debian))
id 1Gbc2E-0005lw-00
for <kha-list-git@hemma.treskal.com>; Sun, 22 Oct 2006 13:02:35 +0100
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1750700AbWJVMCV (ORCPT <rfc822;kha-list-git@hemma.treskal.com>);
Sun, 22 Oct 2006 08:02:21 -0400
X-Warning: Original message contained 8-bit characters, however during
the SMTP transport session the receiving system did not announce
capability of receiving 8-bit SMTP (RFC 1651-1653), and as this
message does not have MIME headers (RFC 2045-2049) to enable
encoding change, we had very little choice.
X-Warning: We ASSUME it is less harmful to add the MIME headers, and
convert the text to Quoted-Printable, than not to do so,
and to strip the message to 7-bits.. (RFC 1428 Appendix A)
X-Warning: We don't know what character set the user used, thus we had to
write these MIME-headers with our local system default value.
MIME-Version: 1.0
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751780AbWJVMCV
(ORCPT <rfc822;git-outgoing>); Sun, 22 Oct 2006 08:02:21 -0400
Received: from mxfep01.bredband.com ([195.54.107.70]:50054 "EHLO
mxfep01.bredband.com") by vger.kernel.org with ESMTP
id S1750700AbWJVMCU (ORCPT <rfc822;git@vger.kernel.org>);
Sun, 22 Oct 2006 08:02:20 -0400
Received: from ironport2.bredband.com ([195.54.107.84] [195.54.107.84])
by mxfep01.bredband.com with ESMTP
id <20061022120218.PHVT953.mxfep01.bredband.com@ironport2.bredband.com>
for <git@vger.kernel.org>; Sun, 22 Oct 2006 14:02:18 +0200
Received: from ua-83-227-180-148.cust.bredbandsbolaget.se (HELO yoghurt.hemma.treskal.com) ([83.227.180.148])
by ironport2.bredband.com with ESMTP; 22 Oct 2006 14:02:18 +0200
Received: from [127.0.0.1] (localhost [127.0.0.1])
by yoghurt.hemma.treskal.com (Postfix) with ESMTP id 1DFDF4C010;
Sun, 22 Oct 2006 14:02:18 +0200 (CEST)
From: Karl =?utf-8?q?Hasselstr=C3=B6m?= <kha@treskal.com>
Subject: [PATCH] RFC2047-encode email headers
Date: Sun, 22 Oct 2006 14:02:17 +0200
To: Catalin Marinas <catalin.marinas@gmail.com>
Cc: git@vger.kernel.org
Message-Id: <20061022120217.7650.23715.stgit@localhost>
User-Agent: StGIT/0.11
Sender: git-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: git@vger.kernel.org
X-Envelope-Username: kha-list-git
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=0.94.4
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on
diana.vm.bytemark.co.uk
X-Spam-Level:
X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,FORGED_RCVD_HELO
autolearn=disabled version=3.0.3
X-Already-Filtered-By: kha@treskal.com, 2006-10-22 13:02:44 +0100
Status: RO
X-Status: A
Content-Length: 4148
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Push and remote refs
From: Daniel Barkalow @ 2006-11-05 18:50 UTC (permalink / raw)
To: git
My current workflow as maintainer of a couple of projects is:
I have a publicly-accessible repository, whose master is the important
branch. When there are changes that I want to add, I fetch this branch on
a workstation to the workstation's "mainline" branch, pull into
"for-mainline" (which is a fast-forward), apply patches, test, commit, and
push back to master.
Usually, I use the same computer to do this multiple times in a row, and
it's a bit inconvenient that, after pushing local "for-mainline" to remote
"master", I have to fetch remote "master" to local "mainline". It would be
nice if git would update local tracking of remote refs when it pushes to
those remote refs.
(Furthermore, I'm also using another branch to do development, by being a
lot less careful about the quality of commits in it, and generating
patches out of the diff between the development branch and mainline. But I
do development on multiple workstations, so I have a remote branch on my
server that I push the development work to, so that I can get it from
other computers even before I clean it up and put it in the mainline. When
I'm generating patches, I'm doing it between "for-mainline" and the
tracking branch for the remote development, which means that I remember to
push my development to the server. But then I have to fetch it back
immediately so that I can use it to generate patches.)
I can't think of a situation in which you would want to not get the effect
of an immediate fetch after a successful push, and it saves a couple of
ssh connections to use the local knowledge that, at least for an instant,
the remote ref matches the local one. Is there some reason not to do this?
-Daniel
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-11-05 18:47 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <454E1E69.2040209@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Junio C Hamano schrieb:
>> git-branch and git-cherry are now built-in.
>
> Yes, but git-cherry.sh still exists in master (but not in next).
> Intentionally?
Thanks for catching this; it was a mismerge in commit 56532fa1.
^ permalink raw reply
* Re: What's in git.git
From: Rene Scharfe @ 2006-11-05 17:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk62ewtxd.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> git-branch and git-cherry are now built-in.
Yes, but git-cherry.sh still exists in master (but not in next).
Intentionally?
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Linus Torvalds @ 2006-11-05 16:44 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Andy Whitcroft, Catalin Marinas, git
In-Reply-To: <20061105114353.GB19707@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2102 bytes --]
On Sun, 5 Nov 2006, Karl Hasselström wrote:
>
> So the right thing to do would be to teach StGIT to generate
> 8bit-encoded output, and trust the SMTP transfer path do mangle it
> correctly? (Hmm. No, since StGIT talks directly with the first SMTP
> server in the chain, it needs to be able to QP-encode the mail itself
> if necessary -- but it should seldom be necessary, then.)
Right. You could even just consider it an error if the mailserver doesn't
reply to EHLO with 8BITMIME, I really think it's that rare.
> In that case, the problem with the current implementation (without my
> patch applied) is likely to be that it fails to provide the headers
> needed for the SMTP path to be able to transform it losslessly.
I _think_ it should be sufficient to just set the Content-Type and
Content-Transfer-Encoding to say something like "text/plain; charset=UTF8"
and "8bit" respectively. But somebody who know the SMTP rules better
should check.
HOWEVER:
> Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
> id S1750700AbWJVMCV (ORCPT <rfc822;kha-list-git@hemma.treskal.com>);
> Sun, 22 Oct 2006 08:02:21 -0400
> X-Warning: Original message contained 8-bit characters, however during
> the SMTP transport session the receiving system did not announce
> capability of receiving 8-bit SMTP (RFC 1651-1653), and as this
> message does not have MIME headers (RFC 2045-2049) to enable
> encoding change, we had very little choice.
This does seem to say that somebody didn't even announce 8-bit capability
in the first place. That's a zmailer error message, and it does imply that
somebody was running a bad server.
That said, _if_ your message had had the proper mime-type specifiers, then
zmailer would happily have QP-converted the message for you, so everything
would have been fine.
> The mail server (vger talking to itself, if the Received: headers were
> added in order) complained that there were no MIME headers, so it had
> to guess the charset.
vger itself? Strange.
Linus
^ permalink raw reply
* git-am vs. git-applymbox
From: Jakub Narebski @ 2006-11-05 12:10 UTC (permalink / raw)
To: git
git-applymbox - Apply a series of patches in a mailbox
git-am - Apply a series of patches in a mailbox
What are the differences between thos two commands, UI-wise and capability
(feature) wise? Which one should I use? Which one do _you_ use?
And why git has yet another set of commands which do the same (well,
git-annotate vs. git-blame "war" was won by git-blame, and git-pickaxe was
born).
By the way, could we standarize somewhat short options for git commands,
like -q for quiet, -v for verbose, -i for interactive, -S for pickaxe
(search in diff), -n for some kind of no-op/do nothing (e.g. --no-commit),
-f for force, -l for list, -k for skip errors/keep working even in the case
of errors? It would be nice to have this in Documentation/API somewhere...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Bash completion Issue?
From: Jakub Narebski @ 2006-11-05 11:45 UTC (permalink / raw)
To: git
In-Reply-To: <20061105113115.GC4843@spearce.org>
Shawn Pearce wrote:
> Alan Chandler <alan@chandlerfamily.org.uk> wrote:
>> removing the git-completion package and copying the bash completion script
>> from /usr/share/doc/git-core/contrib/completion to /etc/bash_completion.d
>> solves the problem. I am getting completion working fine now.
>
> Good. :-)
>
> Let us know if there's anything you'd like to see in the bash
> completion... I just sent out two rounds of patches for it, but
> certainly still have more work to do on it.
I'd like to see completion for git-format-patch, git-cherry-pick
and git-rebase. I tried to start doing completion for git-format-patch,
but realized that I don't know bash, and bash completion enough for that.
While at it, do git-completion.bash takes into consideration that
some commands doesn't accept branch which is current branch.
Otherwise, I find git-completion for bash very useful.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Karl Hasselström @ 2006-11-05 11:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andy Whitcroft, Catalin Marinas, git
In-Reply-To: <Pine.LNX.4.64.0611031034520.25218@g5.osdl.org>
On 2006-11-03 10:48:49 -0800, Linus Torvalds wrote:
> If your ISP mailer doesn't answer with "8BITMIME" to your EHLO, your
> mail client is supposed to downgrade to a 7-bit format (or the same
> thing can happen anywhere in between on one of the other hops). Of
> course, that would be a really old and broken mailer, and if you
> find one of those at the ISP you use, you should probably switch
> ISPs.
>
> Some other mailers have other issues, and qmail for example is
> apparently totally broken (it accepts 8-bit input, but cannot
> forward it properly to somebody who wants it converted to 7-bit).
>
> And some of us use "fetchmail" and ask it do do mimedecode for us,
> so that even if it arrived as 7-bit crud, we don't have to see it.
> So the fact that some people see it as 8-bit can be because the hops
> to them didn't involve a broken remailer, but it could also be
> because something in between (like fetchmail) tries to fix it up
> after the fact.
>
> That said: it tends to be unusual to see true 7-bit mailer setups
> these days.
>
> So the most _likely_ cause of unnecessary 7-bit QP crud is not in
> fact a 7-bit mailserver, but usually just the mail client that is
> just lazy and just sends out everything as 7-bit because it's too
> bothersome to even look at whether the mail server supports 8-bit
> data. Check your Thunderbird settings - it's quite possible that
> there's a flag there somewhere to turn on 8-bit mail transfers.
So the right thing to do would be to teach StGIT to generate
8bit-encoded output, and trust the SMTP transfer path do mangle it
correctly? (Hmm. No, since StGIT talks directly with the first SMTP
server in the chain, it needs to be able to QP-encode the mail itself
if necessary -- but it should seldom be necessary, then.)
In that case, the problem with the current implementation (without my
patch applied) is likely to be that it fails to provide the headers
needed for the SMTP path to be able to transform it losslessly.
[ ... digs through old mail ... ]
This is the interesting part of such a mail that was sent from my
computer, passed through the list, and ended up back at my computer
again:
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1750700AbWJVMCV (ORCPT <rfc822;kha-list-git@hemma.treskal.com>);
Sun, 22 Oct 2006 08:02:21 -0400
X-Warning: Original message contained 8-bit characters, however during
the SMTP transport session the receiving system did not announce
capability of receiving 8-bit SMTP (RFC 1651-1653), and as this
message does not have MIME headers (RFC 2045-2049) to enable
encoding change, we had very little choice.
X-Warning: We ASSUME it is less harmful to add the MIME headers, and
convert the text to Quoted-Printable, than not to do so,
and to strip the message to 7-bits.. (RFC 1428 Appendix A)
X-Warning: We don't know what character set the user used, thus we had to
write these MIME-headers with our local system default value.
MIME-Version: 1.0
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751780AbWJVMCV
(ORCPT <rfc822;git-outgoing>); Sun, 22 Oct 2006 08:02:21 -0400
The mail server (vger talking to itself, if the Received: headers were
added in order) complained that there were no MIME headers, so it had
to guess the charset. As it happened, it guessed wrong, so the
non-ascii characters of the mail body was garbled.
My stab at fixing this was to make StGIT QP-encode the mail from the
outset, but if I've not misunderstood things yet again, the actual
problem was that StGIT did not produce the right MIME headers.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Bash completion Issue?
From: Shawn Pearce @ 2006-11-05 11:31 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200611051122.46971.alan@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> wrote:
> removing the git-completion package and copying the bash completion script
> from /usr/share/doc/git-core/contrib/completion to /etc/bash_completion.d
> solves the problem. I am getting completion working fine now.
Good. :-)
Let us know if there's anything you'd like to see in the bash
completion... I just sent out two rounds of patches for it, but
certainly still have more work to do on it.
Completion of arguments to git aliases or commands like fetch and
push when --git-dir/--bare has been used is still a little buggy.
--
^ permalink raw reply
* [PATCH 6/6] Remove more sed invocations from within bash completion.
From: Shawn O. Pearce @ 2006-11-05 11:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This change removes between 1 and 4 sed invocations per completion
entered by the user. In the case of cat-file the 4 invocations per
completion can take a while on Cygwin; running these replacements
directly within bash saves some time for the end user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 74be651..f3be132 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -83,15 +83,15 @@ __git_remotes ()
__git_complete_file ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local pfx ls ref cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
?*:*)
- local pfx ls ref="$(echo "$cur" | sed 's,:.*$,,')"
- cur="$(echo "$cur" | sed 's,^.*:,,')"
+ ref="${cur%%:*}"
+ cur="${cur#*:}"
case "$cur" in
?*/*)
- pfx="$(echo "$cur" | sed 's,/[^/]*$,,')"
- cur="$(echo "$cur" | sed 's,^.*/,,')"
+ pfx="${cur%/*}"
+ cur="${cur##*/}"
ls="$ref:$pfx"
pfx="$pfx/"
;;
@@ -193,7 +193,7 @@ _git_fetch ()
*)
case "$cur" in
*:*)
- cur=$(echo "$cur" | sed 's/^.*://')
+ cur="${cur#*:}"
COMPREPLY=($(compgen -W "$(__git_refs)" -- "$cur"))
;;
*)
@@ -287,7 +287,7 @@ _git_push ()
git-push) remote="${COMP_WORDS[1]}" ;;
git) remote="${COMP_WORDS[2]}" ;;
esac
- cur=$(echo "$cur" | sed 's/^.*://')
+ cur="${cur#*:}"
COMPREPLY=($(compgen -W "$(__git_refs "$remote")" -- "$cur"))
;;
*)
--
^ permalink raw reply related
* [PATCH 5/6] Support bash completion on symmetric difference operator.
From: Shawn O. Pearce @ 2006-11-05 11:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Now that log, whatchanged, rev-list, etc. support the symmetric
difference operator '...' we should provide bash completion for it
just like we do for '..'.
While we are at it we can remove two sed invocations during the
interactive prompt and replace them with internal bash operations.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index f258f2f..74be651 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -222,11 +222,16 @@ _git_ls_tree ()
_git_log ()
{
- local cur="${COMP_WORDS[COMP_CWORD]}"
+ local pfx cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
+ *...*)
+ pfx="${cur%...*}..."
+ cur="${cur#*...}"
+ COMPREPLY=($(compgen -P "$pfx" -W "$(__git_refs)" -- "$cur"))
+ ;;
*..*)
- local pfx=$(echo "$cur" | sed 's/\.\..*$/../')
- cur=$(echo "$cur" | sed 's/^.*\.\.//')
+ pfx="${cur%..*}.."
+ cur="${cur#*..}"
COMPREPLY=($(compgen -P "$pfx" -W "$(__git_refs)" -- "$cur"))
;;
*)
--
1.4.3.3.g9621
^ permalink raw reply related
* Re: Bash completion Issue?
From: Alan Chandler @ 2006-11-05 11:22 UTC (permalink / raw)
To: git
In-Reply-To: <200611050930.23455.alan@chandlerfamily.org.uk>
On Sunday 05 November 2006 09:30, Alan Chandler wrote:
> On Sunday 05 November 2006 04:28, Shawn Pearce wrote:
> > Maybe you can nicely ask the Debian maintainer to switch to using
> > use the completion script that is actually shipped with git 1.4.3.3?
>
> It seems to be a little bit more subtle than I first thought.
>
> There is a separate 'git-completion' package which is not maintained by the
> git maintainer (Gerrit Pape) and which has not been updated since August.
> Its this package that contains the scripts.
>
> I'll file a bug report against it.
removing the git-completion package and copying the bash completion script
from /usr/share/doc/git-core/contrib/completion to /etc/bash_completion.d
solves the problem. I am getting completion working fine now.
--
Alan Chandler
^ permalink raw reply
* [PATCH 4/6] Take --git-dir into consideration during bash completion.
From: Shawn O. Pearce @ 2006-11-05 11:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If the user has setup a command line of "git --git-dir=baz" then
anything we complete must be performed within the scope of "baz"
and not the current working directory.
This is useful with commands such as "git --git-dir=git.git log m"
to complete out "master" and view the log for the master branch of
the git.git repository. As a nice side effect this also works for
aliases within the target repository, just as git would honor them.
Unfortunately because we still examine arguments by absolute position
in most of the more complex commands (e.g. git push) using --git-dir
with those commands will probably still cause completion to fail.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 123 ++++++++++++++++++--------------
1 files changed, 70 insertions(+), 53 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 5f1be46..f258f2f 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -19,15 +19,20 @@
# source ~/.git-completion.sh
#
+__gitdir ()
+{
+ echo "${__git_dir:-$(git rev-parse --git-dir 2>/dev/null)}"
+}
+
__git_refs ()
{
- local cmd i is_hash=y
- if [ -d "$1" ]; then
+ local cmd i is_hash=y dir="${1:-$(__gitdir)}"
+ if [ -d "$dir" ]; then
cmd=git-peek-remote
else
cmd=git-ls-remote
fi
- for i in $($cmd "$1" 2>/dev/null); do
+ for i in $($cmd "$dir" 2>/dev/null); do
case "$is_hash,$i" in
y,*) is_hash=n ;;
n,*^{}) is_hash=y ;;
@@ -40,13 +45,13 @@ __git_refs ()
__git_refs2 ()
{
- local cmd i is_hash=y
- if [ -d "$1" ]; then
+ local cmd i is_hash=y dir="${1:-$(__gitdir)}"
+ if [ -d "$dir" ]; then
cmd=git-peek-remote
else
cmd=git-ls-remote
fi
- for i in $($cmd "$1" 2>/dev/null); do
+ for i in $($cmd "$dir" 2>/dev/null); do
case "$is_hash,$i" in
y,*) is_hash=n ;;
n,*^{}) is_hash=y ;;
@@ -59,14 +64,14 @@ __git_refs2 ()
__git_remotes ()
{
- local i ngoff IFS=$'\n'
+ local i ngoff IFS=$'\n' d="$(__gitdir)"
shopt -q nullglob || ngoff=1
shopt -s nullglob
- for i in .git/remotes/*; do
- echo ${i#.git/remotes/}
+ for i in "$d/remotes"/*; do
+ echo ${i#$d/remotes/}
done
[ "$ngoff" ] && shopt -u nullglob
- for i in $(git repo-config --list); do
+ for i in $(git --git-dir="$d" repo-config --list); do
case "$i" in
remote.*.url=*)
i="${i#remote.}"
@@ -95,7 +100,7 @@ __git_complete_file ()
;;
esac
COMPREPLY=($(compgen -P "$pfx" \
- -W "$(git-ls-tree "$ls" \
+ -W "$(git --git-dir="$(__gitdir)" ls-tree "$ls" \
| sed '/^100... blob /s,^.* ,,
/^040000 tree /{
s,^.* ,,
@@ -105,7 +110,7 @@ __git_complete_file ()
-- "$cur"))
;;
*)
- COMPREPLY=($(compgen -W "$(__git_refs .)" -- "$cur"))
+ COMPREPLY=($(compgen -W "$(__git_refs)" -- "$cur"))
;;
esac
}
@@ -113,7 +118,7 @@ __git_complete_file ()
__git_aliases ()
{
local i IFS=$'\n'
- for i in $(git repo-config --list); do
+ for i in $(git --git-dir="$(__gitdir)" repo-config --list); do
case "$i" in
alias.*)
i="${i#alias.}"
@@ -125,7 +130,8 @@ __git_aliases ()
__git_aliased_command ()
{
- local word cmdline=$(git repo-config --get "alias.$1")
+ local word cmdline=$(git --git-dir="$(__gitdir)" \
+ repo-config --get "alias.$1")
for word in $cmdline; do
if [ "${word##-*}" ]; then
echo $word
@@ -137,7 +143,7 @@ __git_aliased_command ()
_git_branch ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
- COMPREPLY=($(compgen -W "-l -f -d -D $(__git_refs .)" -- "$cur"))
+ COMPREPLY=($(compgen -W "-l -f -d -D $(__git_refs)" -- "$cur"))
}
_git_cat_file ()
@@ -159,7 +165,7 @@ _git_cat_file ()
_git_checkout ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
- COMPREPLY=($(compgen -W "-l -b $(__git_refs .)" -- "$cur"))
+ COMPREPLY=($(compgen -W "-l -b $(__git_refs)" -- "$cur"))
}
_git_diff ()
@@ -170,7 +176,7 @@ _git_diff ()
_git_diff_tree ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
- COMPREPLY=($(compgen -W "-r -p -M $(__git_refs .)" -- "$cur"))
+ COMPREPLY=($(compgen -W "-r -p -M $(__git_refs)" -- "$cur"))
}
_git_fetch ()
@@ -188,7 +194,7 @@ _git_fetch ()
case "$cur" in
*:*)
cur=$(echo "$cur" | sed 's/^.*://')
- COMPREPLY=($(compgen -W "$(__git_refs .)" -- "$cur"))
+ COMPREPLY=($(compgen -W "$(__git_refs)" -- "$cur"))
;;
*)
local remote
@@ -221,10 +227,10 @@ _git_log ()
*..*)
local pfx=$(echo "$cur" | sed 's/\.\..*$/../')
cur=$(echo "$cur" | sed 's/^.*\.\.//')
- COMPREPLY=($(compgen -P "$pfx" -W "$(__git_refs .)" -- "$cur"))
+ COMPREPLY=($(compgen -P "$pfx" -W "$(__git_refs)" -- "$cur"))
;;
*)
- COMPREPLY=($(compgen -W "$(__git_refs .)" -- "$cur"))
+ COMPREPLY=($(compgen -W "$(__git_refs)" -- "$cur"))
;;
esac
}
@@ -232,7 +238,7 @@ _git_log ()
_git_merge_base ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
- COMPREPLY=($(compgen -W "$(__git_refs .)" -- "$cur"))
+ COMPREPLY=($(compgen -W "$(__git_refs)" -- "$cur"))
}
_git_pull ()
@@ -280,7 +286,7 @@ _git_push ()
COMPREPLY=($(compgen -W "$(__git_refs "$remote")" -- "$cur"))
;;
*)
- COMPREPLY=($(compgen -W "$(__git_refs2 .)" -- "$cur"))
+ COMPREPLY=($(compgen -W "$(__git_refs2)" -- "$cur"))
;;
esac
;;
@@ -291,56 +297,67 @@ _git_reset ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
local opt="--mixed --hard --soft"
- COMPREPLY=($(compgen -W "$opt $(__git_refs .)" -- "$cur"))
+ COMPREPLY=($(compgen -W "$opt $(__git_refs)" -- "$cur"))
}
_git_show ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
- COMPREPLY=($(compgen -W "$(__git_refs .)" -- "$cur"))
+ COMPREPLY=($(compgen -W "$(__git_refs)" -- "$cur"))
}
_git ()
{
- if [ $COMP_CWORD = 1 ]; then
+ local i c=1 command __git_dir
+
+ while [ $c -lt $COMP_CWORD ]; do
+ i="${COMP_WORDS[c]}"
+ case "$i" in
+ --git-dir=*) __git_dir="${i#--git-dir=}" ;;
+ --bare) __git_dir="." ;;
+ --version|--help|-p|--paginate) ;;
+ *) command="$i"; break ;;
+ esac
+ c=$((++c))
+ done
+
+ if [ $c -eq $COMP_CWORD -a -z "$command" ]; then
COMPREPLY=($(compgen \
- -W "--version $(git help -a|egrep '^ ') \
+ -W "--git-dir= --version \
+ $(git help -a|egrep '^ ') \
$(__git_aliases)" \
-- "${COMP_WORDS[COMP_CWORD]}"))
- else
- local command="${COMP_WORDS[1]}"
- local expansion=$(__git_aliased_command "$command")
+ return;
+ fi
- if [ "$expansion" ]; then
- command="$expansion"
- fi
+ local expansion=$(__git_aliased_command "$command")
+ [ "$expansion" ] && command="$expansion"
- case "$command" in
- branch) _git_branch ;;
- cat-file) _git_cat_file ;;
- checkout) _git_checkout ;;
- diff) _git_diff ;;
- diff-tree) _git_diff_tree ;;
- fetch) _git_fetch ;;
- log) _git_log ;;
- ls-remote) _git_ls_remote ;;
- ls-tree) _git_ls_tree ;;
- merge-base) _git_merge_base ;;
- pull) _git_pull ;;
- push) _git_push ;;
- reset) _git_reset ;;
- show) _git_show ;;
- show-branch) _git_log ;;
- whatchanged) _git_log ;;
- *) COMPREPLY=() ;;
- esac
- fi
+ case "$command" in
+ branch) _git_branch ;;
+ cat-file) _git_cat_file ;;
+ checkout) _git_checkout ;;
+ diff) _git_diff ;;
+ diff-tree) _git_diff_tree ;;
+ fetch) _git_fetch ;;
+ log) _git_log ;;
+ ls-remote) _git_ls_remote ;;
+ ls-tree) _git_ls_tree ;;
+ merge-base) _git_merge_base ;;
+ pull) _git_pull ;;
+ push) _git_push ;;
+ reset) _git_reset ;;
+ show) _git_show ;;
+ show-branch) _git_log ;;
+ whatchanged) _git_log ;;
+ *) COMPREPLY=() ;;
+ esac
}
_gitk ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
- COMPREPLY=($(compgen -W "--all $(__git_refs .)" -- "$cur"))
+ COMPREPLY=($(compgen -W "--all $(__git_refs)" -- "$cur"))
}
complete -o default -o nospace -F _git git
--
1.4.3.3.g9621
^ permalink raw reply related
* [PATCH 3/6] Bash completion support for remotes in .git/config.
From: Shawn O. Pearce @ 2006-11-05 11:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Now that Git natively supports remote specifications within the
config file such as:
[remote "origin"]
url = ...
we should provide bash completion support "out of the box" for
these remotes, just like we do for the .git/remotes directory.
Also cleaned up the __git_aliases expansion to use the same form
of querying and filtering repo-config as this saves two fork/execs
in the middle of a user prompted completion. Finally also forced
the variable 'word' to be local within __git_aliased_command.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 26 +++++++++++++++++++++-----
1 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 926638d..5f1be46 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -59,12 +59,21 @@ __git_refs2 ()
__git_remotes ()
{
- local i REVERTGLOB=$(shopt -p nullglob)
+ local i ngoff IFS=$'\n'
+ shopt -q nullglob || ngoff=1
shopt -s nullglob
for i in .git/remotes/*; do
echo ${i#.git/remotes/}
done
- $REVERTGLOB
+ [ "$ngoff" ] && shopt -u nullglob
+ for i in $(git repo-config --list); do
+ case "$i" in
+ remote.*.url=*)
+ i="${i#remote.}"
+ echo "${i/.url=*/}"
+ ;;
+ esac
+ done
}
__git_complete_file ()
@@ -103,13 +112,20 @@ __git_complete_file ()
__git_aliases ()
{
- git repo-config --list | grep '^alias\.' \
- | sed -e 's/^alias\.//' -e 's/=.*$//'
+ local i IFS=$'\n'
+ for i in $(git repo-config --list); do
+ case "$i" in
+ alias.*)
+ i="${i#alias.}"
+ echo "${i/=*/}"
+ ;;
+ esac
+ done
}
__git_aliased_command ()
{
- local cmdline=$(git repo-config alias.$1)
+ local word cmdline=$(git repo-config --get "alias.$1")
for word in $cmdline; do
if [ "${word##-*}" ]; then
echo $word
--
1.4.3.3.g9621
^ permalink raw reply related
* [PATCH 2/6] Only load .exe suffix'd completions on Cygwin.
From: Shawn O. Pearce @ 2006-11-05 11:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The only platform which actually needs to define .exe suffixes as
part of its completion set is Cygwin. So don't define them on any
other platform.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index fdfbf95..926638d 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -350,6 +350,7 @@ complete -o default -o nospace -F _git_l
# when the user has tab-completed the executable name and consequently
# included the '.exe' suffix.
#
+if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
complete -o default -o nospace -F _git git.exe
complete -o default -F _git_branch git-branch.exe
complete -o default -o nospace -F _git_cat_file git-cat-file.exe
@@ -361,3 +362,4 @@ complete -o default -F _git_m
complete -o default -o nospace -F _git_push git-push.exe
complete -o default -o nospace -F _git_log git-show-branch.exe
complete -o default -o nospace -F _git_log git-whatchanged.exe
+fi
--
1.4.3.3.g9621
^ permalink raw reply related
* [PATCH 1/6] Added missing completions for show-branch and merge-base.
From: Shawn O. Pearce @ 2006-11-05 11:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The show-branch and merge-base commands were partially supported
when it came to bash completions as they were only specified in
one form another. Now we specify them in both forms.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index a3fbb90..fdfbf95 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -309,6 +309,7 @@ _git ()
log) _git_log ;;
ls-remote) _git_ls_remote ;;
ls-tree) _git_ls_tree ;;
+ merge-base) _git_merge_base ;;
pull) _git_pull ;;
push) _git_push ;;
reset) _git_reset ;;
@@ -342,12 +343,14 @@ complete -o default -o nospace -F _git_p
complete -o default -o nospace -F _git_push git-push
complete -o default -F _git_reset git-reset
complete -o default -F _git_show git-show
+complete -o default -o nospace -F _git_log git-show-branch
complete -o default -o nospace -F _git_log git-whatchanged
# The following are necessary only for Cygwin, and only are needed
# when the user has tab-completed the executable name and consequently
# included the '.exe' suffix.
#
+complete -o default -o nospace -F _git git.exe
complete -o default -F _git_branch git-branch.exe
complete -o default -o nospace -F _git_cat_file git-cat-file.exe
complete -o default -o nospace -F _git_diff git-diff.exe
@@ -356,4 +359,5 @@ complete -o default -o nospace -F _git_l
complete -o default -o nospace -F _git_ls_tree git-ls-tree.exe
complete -o default -F _git_merge_base git-merge-base.exe
complete -o default -o nospace -F _git_push git-push.exe
+complete -o default -o nospace -F _git_log git-show-branch.exe
complete -o default -o nospace -F _git_log git-whatchanged.exe
--
1.4.3.3.g9621
^ permalink raw reply related
* Re: bash completion in backticks partially broken
From: Shawn Pearce @ 2006-11-05 10:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsc2teb0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > This is really annoying when it comes to less contrived examples.
> > I find myself forming odd pipelines with commit-tree, update-ref,
> > mktree, lstree, sed, rev-list, etc. and always keep bumping up on
> > the limitations of git-completion.bash.
> >
> > Any suggestions?
>
> I am more interested in why you would even need to use
> combinations of such low-level commands in day-to-day workflow.
>
> If they are often-needed patterns, you would have scripted them
> already, so completion would not be an issue for you. So I am
> assuming these are ad-hoc one-shot needs.
Yes, that's correct.
> While it is satisfying to know that things you would want to do
> can be scripted even for one-shot use (which is how git is
> designed to, and it shows that the design goal has been
> achieved), maybe it's a sign that we are giving you too much
> flexibility? Under less capable/flexible system that puts you
> in a straightjacket, you would not even be tempted to do oddball
> things to begin with...
A few recent examples come to mind:
*) We're mostly on Windows (*sigh*) which as you know is a case
insensitive file system. Someone managed to delete a file
called 'Myfoo' and recreate it as 'MyFoo' on two different
branches.
We have a specialized merge driver which we are running on
certain merges. This merge driver made the bad assumption
that both 'Myfoo' and 'MyFoo' should stick around after
merging those two branches together. No, merge-recursive
doesn't implement the type of bastard merge we need,
so don't ask. This merge strategy is also probably not
useful to anyone else, which is why I haven't posted a
patch to include it.
A quick hack with mktree/commit-tree/update-ref removed
the wrong 'Myfoo' leaving 'MyFoo' in place. And before
you ask, yes I did check that was sane, 'Myfoo' and 'MyFoo'
had the exact same SHA1. ;-)
*) A new user branched off a highly experimental branch then
proceeded to merge that straight into the mainline. We found
his mistake 100 commits later on the mainline and couldn't
rewind it.
Because of the way that mainline is flushed into the
testing environment, and because it had a lot of history on
it that we wanted to keep valid in git-blame, I reverted
~36 commits in one large squash commit onto the mainline,
flushed that into testing, then squash cherry-picked all
~36 commits back ontop of that, then merged that into the
prior experimental branch. Yuck.
The upside is that both git-blame and git-pickaxe report
back to the original commits. :)
I'm sure I abused git-write-tree and git-commit-tree during
that as both are faster than waiting for git-commit. Yes,
it takes me less time to type out and execute commit-tree
pipeline than to wait for git-commit on my system. :-(
I also know I spent a lot of time with gitk and
git-merge-base trying to find the correct set of 36 commits
which had to be worked on. It wasn't a trivial rev-list/log
type operation due to the sheer number of commits and merges
involved. Our commit graph is much uglier than git.git.
*) Being the moron that I am I pulled another (but slightly
less) experimental branch into the highly experimental branch
mentioned above. 3 weeks later we concluded that was a bad idea
as not all of the stuff in the slightly less experimental
branch was good. But I had also done a number of bug fixes
onto that highly experimental branch and those needed to
get saved.
This turned out to be mostly a format-patch | am pipeline,
so it wasn't really that awkward.
*) At least twice I've had an aweful merge of over 1000 files
conflicting heavily between two branches. Yet in both cases
I *know without a doubt* that one of those two branches is
completely correct for 15 of say 20 top level directories,
such that those 15 directories cover about 995 files.
To resolve these I've often just reverted those directories
en-mass to the version in the merge-base of the two branches
by way of ls-tree/vi/mktree, then let merge-recursive do
its thing. As the correct side differs but the wrong side
was reverted, the correct side pops out of the merge. :-)
Its somewhat lying in the history because Git now thinks
that one branch modified 995 files, then suddenly threw them
all back to the version at the merge-base. But honestly
reverting them back to the merge-base and then immediately
doing a merge which replaces them with the correct versions
is about the same as resolving the 995 conflicts during
the merge with the ones from the other branch.
Its also *much* faster on Cygwin. That 1000 file merge
would probably have taken my system 15 minutes just to
invoke 'merge' on each file and still leave me with a mess
to cleanup. Yet the bastard approach above with mktree
took me like 5 minutes (total).
Now on UNIX systems I never do stupid things like the above; nor
do I work with such new users... Hmm... I wonder what that says...
--
^ permalink raw reply
* Re: [PATCH/RFC] Documentation: Two more git-rebase --onto examples
From: Jakub Narebski @ 2006-11-05 10:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqnmwvib.fsf@assigned-by-dhcp.cox.net>
Thanks for comments.
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> +More useful example of --onto option usage include transplanting feature
>> +branch from one development branch to other, for example change to branch
>> +based off "next" branch:
>
> By "more" do you mean the following examples are more useful
> than the one before, or having larger number of examples adds to
> the usefulness of the document overall?
I found original example somewhat artifical, but after thinking on that
I guess that the need for rebase onto master~1 might happen when the last
commit in master is for example to be amended or rebased.
The "transplanting branch" example feels like more natural to me.
> How about:
>
> Here is how you would transplant a topic branch based on one
> branch to another, to pretend that you forked the topic branch
> from the latter branch, using `rebase --onto`.
Perhaps adding why one might want to transplant topic branch from one
development branch to other: for example when feature being developed
on topic branch relied on functionality which was at the time topic branch
was started available only in 'next' branch, but meanwhile it matured and
was merged into 'master' (more stable) branch. One would want to base
topic branches on 'master' branch if possible.
[...]
> This looks the same as the original example for --onto; I would
> either drop it or replace it something of different flavor.
This example is from latest post by Andy Parkins, which asked how to
do that. But I find your example as being better, because it shows
even more power of core git history manipulation.
> What I find myself doing more is to reorder without using StGIT.
> When I have this:
>
> 1---2---3---4 topic
>
> and 2 is a bit half-baked, and I would want to have:
>
> 1---3'--4'--2' topic
[...]
Here I find lack of --interactive option to at least git-am based
rebase; git-rebase could simply pass --interactive option to git-am.
--
Jakub Narebski
^ permalink raw reply
* Re: bash completion in backticks partially broken
From: Junio C Hamano @ 2006-11-05 9:48 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061105090540.GA4843@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> This is really annoying when it comes to less contrived examples.
> I find myself forming odd pipelines with commit-tree, update-ref,
> mktree, lstree, sed, rev-list, etc. and always keep bumping up on
> the limitations of git-completion.bash.
>
> Any suggestions?
I am more interested in why you would even need to use
combinations of such low-level commands in day-to-day workflow.
If they are often-needed patterns, you would have scripted them
already, so completion would not be an issue for you. So I am
assuming these are ad-hoc one-shot needs.
While it is satisfying to know that things you would want to do
can be scripted even for one-shot use (which is how git is
designed to, and it shows that the design goal has been
achieved), maybe it's a sign that we are giving you too much
flexibility? Under less capable/flexible system that puts you
in a straightjacket, you would not even be tempted to do oddball
things to begin with...
^ permalink raw reply
* Re: Bash completion Issue?
From: Alan Chandler @ 2006-11-05 9:30 UTC (permalink / raw)
To: git
In-Reply-To: <20061105042849.GA3840@spearce.org>
On Sunday 05 November 2006 04:28, Shawn Pearce wrote:
> Maybe you can nicely ask the Debian maintainer to switch to using
> use the completion script that is actually shipped with git 1.4.3.3?
It seems to be a little bit more subtle than I first thought.
There is a separate 'git-completion' package which is not maintained by the
git maintainer (Gerrit Pape) and which has not been updated since August. Its
this package that contains the scripts.
I'll file a bug report against it.
--
Alan Chandler
^ permalink raw reply
* bash completion in backticks partially broken
From: Shawn Pearce @ 2006-11-05 9:05 UTC (permalink / raw)
To: git
So an annoying feature of bash appears to be that it won't really
provide completion on backtick'd commands.
For example I can complete "git merge-base ma" just fine as is, but
if I toss it into backticks say "git update-ref M `git merge-base ma"
then I can't complete "ma" out to "master" anymore.
A little bit of debugging appears to show that bash is invoking the
completion hook for the outermost command; that is we are looking
for parameters for update-ref and not merge-base.
I think I could rewrite a good part of git-completion.bash to
support this use. But it won't work for "echo `git merge-base ma"
as the outermost command is echo and we don't have a Git completion
hook registered for that command.
This is really annoying when it comes to less contrived examples.
I find myself forming odd pipelines with commit-tree, update-ref,
mktree, lstree, sed, rev-list, etc. and always keep bumping up on
the limitations of git-completion.bash.
Any suggestions? How often do bash users try to use backticks to
call Git commands, only to find bash isn't being as helpful as it
should be?
--
^ permalink raw reply
* [ANNOUNCE] GIT 1.4.3.4
From: Junio C Hamano @ 2006-11-05 9:01 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.4.3.4 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.3.4.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.3.4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.3.4.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.3.4-1.$arch.rpm (RPM)
Among many minor fixes and documentation updates, this contains these
fixes:
- revision traversal now treats --unpacked as commit filter,
not traversal limiter. If you have unpacked commits that are
parents of packed ones which are in turn parents of commits
that are unpacked, running rev-list starting at the latest
unpacked commits used to _stop_ at the first packed commit
and older unpacked commits were not shown. With this update,
the traversal does not stop at packed commits, and shows the
older unpacked commits. The updated semantics is easier to
use with git-repack --unpacked.
- In a repository configured for shared access, if the
permission bits of existing directories are misconfigured
(e.g. running repository commands as root by mistake), a
codepath to create a new object failed with incorrect error
message. Fixed.
- An earlier fix to cope with traditional-style patches that
were generated with --unified=0 broke handling of creation
and deletion diffs in git-apply. Fixed.
----------------------------------------------------------------
Andy Parkins (2):
Minor grammar fixes for git-diff-index.txt
git-clone documentation didn't mention --origin as equivalent of -o
Christian Couder (3):
Remove --syslog in git-daemon inetd documentation examples.
Documentation: add upload-archive service to git-daemon.
Documentation: add git in /etc/services.
Edgar Toernig (1):
Use memmove instead of memcpy for overlapping areas
J. Bruce Fields (1):
Documentation: updates to "Everyday GIT"
Jakub Narebski (3):
diff-format.txt: Combined diff format documentation supplement
diff-format.txt: Correct information about pathnames quoting in patch format
gitweb: Check git base URLs before generating URL from it
Jan Harkes (1):
Continue traversal when rev-list --unpacked finds a packed commit.
Johannes Schindelin (1):
link_temp_to_file: call adjust_shared_perm() only when we created the directory
Junio C Hamano (9):
Documentation: clarify refname disambiguation rules.
combine-diff: a few more finishing touches.
combine-diff: fix hunk_comment_line logic.
combine-diff: honour --no-commit-id
Surround "#define DEBUG 0" with "#ifndef DEBUG..#endif"
quote.c: ensure the same quoting across platforms.
revision traversal: --unpacked does not limit commit list anymore.
link_temp_to_file: don't leave the path truncated on adjust_shared_perm failure
apply: handle "traditional" creation/deletion diff correctly.
Nicolas Pitre (1):
pack-objects doesn't create random pack names
Rene Scharfe (1):
git-cherry: document limit and add diagram
Shawn O. Pearce (3):
Use ULONG_MAX rather than implicit cast of -1.
Remove SIMPLE_PROGRAMS and make git-daemon a normal program.
Remove unsupported C99 style struct initializers in git-archive.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQBFTaP6wMbZpPMRm5oRAvmYAJ9a58U9N7PaM7l7jyzw4MS4YiwjZACghgAO
LnuuiDIqaGGKJbkPJlS0Fto=
=9LbZ
-----END PGP SIGNATURE-----
^ permalink raw reply
* cogito-0.18 is missing a Changes or NEWS file
From: Roland Illig @ 2006-11-05 8:00 UTC (permalink / raw)
To: git
Dear cogito developers,
there is no NEWS file in the cogito-0.18.tar.gz archive, so I cannot
know what changed between 0.16 and 0.18 without running "diff" on the
two archives. Since it is rather common to include a file called NEWS in
distributed packages, could you please do that, too? :)
Greetings,
Roland Illig
^ permalink raw reply
* Re: [PATCH 3/3] Remove unsupported C99 style struct initializers in git-archive.
From: Shawn Pearce @ 2006-11-05 7:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd582uz5b.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > +static struct archiver_desc
> > +{
> > + const char *name;
> > + write_archive_fn_t write_archive;
> > + parse_extra_args_fn_t parse_extra;
> > +} archivers[] = {
> > + { "tar", write_tar_archive, NULL },
> > + { "zip", write_zip_archive, parse_extra_zip_args },
> > };
>
> If this were a struct with bazillions of fields I might have had
> trouble swallowing the change, but this is so small that it is
> no brainer.
Right; if it was larger I would have been in trouble. :-)
> I think this actually is an improvement.
>
> > static int run_remote_archiver(const char *remote, int argc,
> > @@ -88,7 +86,10 @@ static int init_archiver(const char *nam
> >
> > for (i = 0; i < ARRAY_SIZE(archivers); i++) {
> > if (!strcmp(name, archivers[i].name)) {
> > - memcpy(ar, &archivers[i], sizeof(struct archiver));
> > + memset(ar, 0, sizeof(*ar));
> > + ar->name = archivers[i].name;
> > + ar->write_archive = archivers[i].write_archive;
> > + ar->parse_extra = archivers[i].parse_extra;
>
> But is this change really needed? Shouldn't a structure
> assignment just work?
No, they are different structs...
Which I did to reduce the size of the initializer (see above)
so that it was a no brainer for you to swallow. :-)
--
^ 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