* How to pull remote branch with specified commit id?
From: Emily Ren @ 2009-01-13 9:08 UTC (permalink / raw)
To: Git Mailinglist
Git experts,
I want to pull remote branch with specified commit id, how to do it?
Below command can get remote branch
$git pull remote refs/heads/$branch_name
Below command doesn't work
$git pull remote objects/$commit_id
Thanks,
Emily
^ permalink raw reply
* Re: [PATCH/RFC] Documentation/SubmittingPatches: emacs whitespace tip
From: Junio C Hamano @ 2009-01-13 8:28 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87k58zopg5.fsf@jidanni.org>
jidanni@jidanni.org writes:
> Signed-off-by: jidanni <jidanni@jidanni.org>
> ---
> Documentation/SubmittingPatches | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index ba07c8c..7b64343 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -442,6 +442,8 @@ whitespaces (fatal in patches). Running 'C-u g' to display the
> message in raw form before using '|' to run the pipe can work
> this problem around.
>
> +Inside gnus or not, a (setq-default show-trailing-whitespace t) in
> +one's ~/.emacs file will reduce whitespace embarrassment incidents.
What bothered me a lot more is that this part (and only this part) talks
about patch acceptance tip, not patch submission tip. The Gnus/Emacs
section needs a total rewrite, I think.
Having a separate patch acceptance tip is fine, but I do not think it
belongs to SubmittingPatches document, and the current text certainly does
not mesh well with its neighbours.
^ permalink raw reply
* Re: [PATCH] gitweb: recognize six digit abbreviated SHA1
From: Junio C Hamano @ 2009-01-13 8:26 UTC (permalink / raw)
To: Sam Vilain; +Cc: Anders Melchiorsen, git, jnareb
In-Reply-To: <496BF5D7.2090003@vilain.net>
Sam Vilain <sam@vilain.net> writes:
> I think if you're going to go so short as 6 digits, it's probably worth
> making sure that the really short SHA1s check commits only. eg, if
> you've got a commit 'fa023473' and a tree 'fa023421', then 'fa0234'
> should match the commit and not the tree. But I don't think there's a
> plumbing way to do a query like that at the moment.
When people give an abbreviated object name, 99% of the time they mean
commits (and "index deadbeef..acebead" in a patch is a good place to pick
blob object names from, which would be what the 99% of the remaining 1%
would name), so making sure it is a commit or a blob would be a very
sensible thing to do.
Unfortunately, you fundamentally cannot do this without taking a
performance hit of actually opening the object.
^ permalink raw reply
* Re: git-patches list?
From: Andreas Ericsson @ 2009-01-13 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Akira Kitada, git
In-Reply-To: <7vr638f5ch.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Akira Kitada <akitada@gmail.com> writes:
>
>> Can I propose having another mailing list for posting patches to avoid
>> daily mail flood to this list?
>>
>> Yes, I can filter out the emails but still...
>
> This list has always been the only place where git development happens.
> It would make the development very awkward to set up another list only for
> patches, forbid patches to be sent to anywhere but that new list, but
> still discuss the patches on this list.
>
> It does not make much sense to me.
>
I agree.
If any new list is to be introduced, it would only make sense to make it
a read-only "what's new" list, for the various people that want to know
what might break/be fixed in new versions but really don't care about the
discussion that lead to that decision.
Is that what you were after, Akira?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Avoid spurious error messages on error mistakes.
From: Junio C Hamano @ 2009-01-13 8:20 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1231801776-20724-1-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> Prior to that, if the user chose "squash" as a first action, the stderr
> looked like:
>
> grep: /home/madcoder/dev/scm/git/.git/rebase-merge/done: No such file or directory
> Cannot 'squash' without a previous commit
>
> Now the first line is gone.
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> git-rebase--interactive.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index c8b0861..8ed2244 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -349,7 +349,7 @@ do_next () {
> squash|s)
> comment_for_reflog squash
>
> - has_action "$DONE" ||
> + test -f "$DONE" && has_action "$DONE" ||
> die "Cannot 'squash' without a previous commit"
>
> mark_action_done
> --
> 1.6.1.161.g5e07b.dirty
Make sense. Will apply to maint.
^ permalink raw reply
* Re: [PATCH 2/2] grep: don't call regexec() for fixed strings
From: Junio C Hamano @ 2009-01-13 8:13 UTC (permalink / raw)
To: René Scharfe; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <496B9780.3030000@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> +#define RR GIT_REGEX_SPECIAL /* $, (, ), +, ., ^, {, | */
> +#define US GIT_UNDERSCORE
> +#define Ah (GIT_ALPHA | GIT_LOWER_XDIGIT)
>
> unsigned char sane_ctype[256] = {
> GS, 0, 0, 0, 0, 0, 0, 0, 0, SS, SS, 0, 0, SS, 0, 0, /* 0-15 */
Mental note. NUL is marked as GIT_SPECIAL.
> #define isspecial(x) sane_istest(x,GIT_SPECIAL)
> +#define isregexspecial(x) sane_istest(x,GIT_SPECIAL | GIT_REGEX_SPECIAL)
Perhaps isspecial() is misnamed if we were to enhance git-ctype in this
way. It is about a byte being shell glob pattern or a NUL (!!!), and it
should be renamed to isglobspecial() or something.
dir.c uses isspecial() in two places, and both callers rely on NUL being a
part of special to terminate the loops they are in, like this:
for (;;) {
unsigned char c = *match++;
len++;
if (isspecial(c))
return len;
}
It may be a cunning and cute logic, but I do not particularly like it. It
might be cleaner to rename it to isglobspecial(), drop NUL from it, and
have these two call existing call sites to explicitly check for (c == NUL)
for loop termination.
^ permalink raw reply
* Re: [PATCH] contrib/vim: change URL to point to the latest syntax files
From: Junio C Hamano @ 2009-01-13 8:06 UTC (permalink / raw)
To: Jeff King; +Cc: Markus Heidelberg, git
In-Reply-To: <20090113071623.GB12631@coredump.intra.peff.net>
Thanks, both.
^ permalink raw reply
* Re: [PATCH] Simple update to bash completions to prevent unbound variable errors.
From: Junio C Hamano @ 2009-01-13 8:01 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Boyd Stephen Smith Jr., Shawn O. Pearce, git
In-Reply-To: <496C1D90.1020609@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> writes:
> An alternative (to a Vim modeline) is to put
>
> #!bash
I actually like this much better than "# vim:" thing.
It talks about WHAT the file is ("It is a bash scriptlet"), as opposed to
"# vim:" that tells HOW one user wants to edit the file ("with this
settings I use vim to edit this file"). In case somebody misunderstood
me, my "Yuck" was not about Emacs vs vi holy war. [*1*].
As people noted, it may not have any meaning to the shell, but it serves
as an important documentation to humans. As the maintainer, I try to be
reasonably strict about keeping our shell scripts free of bash-ism to help
people on platforms without bash, but this file is about bash (and bash
only). We are free to use all bash-isms we usually try to stay away from
in our scripts marked with #!/bin/sh (namely, "local", "let", shell
arrays, and substitutions outside POSIX such as ${parameter:offset:length}
substring, ${#parameter} length, and ${parameter/pattern/string} regexp
replacement), as long as they are compatible across recent bash versions.
If tools like vim notice the same hint that says "this is bash" and
adjusts its behaviour accordingly, that is great.
Even though I've grown to know Shawn well enough to be able to tell that
certain kinds of changes would get his Ack and often apply patches myself
without waiting him to give his Ack, the completion script is ultimately
his code and you do not necessarily have to make me like it.
Your updated patch still had [ $# -eq 0 -o -z "$1" ] even though the
commit log message (which is not the place to describe changes between v1
and v2 submissions, by the way) claimed that you replaced them with
"${1-}". I am guessing it would need at least one more iteration to clean
up, but I think this patch is improving _provided if_ supporting "set -u"
in the user's interactive environment is a good idea to begin with.
I just hope that next person who complains about bash completion scripts
would not say that he has "set -e" in his interactive environment ;-) I
personally consider that "set -u" is equally silly, but it probably is
just me.
[Footnote]
*1* For the same reason, Local Variables section to please Emacs is
equally offending; it tends to be much bigger which is even worse.
^ permalink raw reply
* Re: [PATCH] contrib/vim: change URL to point to the latest syntax files
From: Jeff King @ 2009-01-13 7:56 UTC (permalink / raw)
To: Teemu Likonen; +Cc: Markus Heidelberg, git
In-Reply-To: <8763kjej3p.fsf@iki.fi>
On Tue, Jan 13, 2009 at 09:54:50AM +0200, Teemu Likonen wrote:
> Vim is essentially just a one-man project and the maintainer doesn't use
> version control system. He just piles "diff -c" -type patches on top of
> the previous release and sends them to vim-dev mailing list and to some
> FTP site. Then other people try to maintain VCS repositories based on
> the patches and resources that are available.
>
> Vim's bus factor: 1
Ah. He should use git. ;)
Thanks for the explanation.
-Peff
^ permalink raw reply
* Re: [PATCH] contrib/vim: change URL to point to the latest syntax files
From: Teemu Likonen @ 2009-01-13 7:54 UTC (permalink / raw)
To: Jeff King; +Cc: Markus Heidelberg, git
In-Reply-To: <20090113071623.GB12631@coredump.intra.peff.net>
Jeff King (2009-01-13 02:16 -0500) wrote:
> On Tue, Jan 13, 2009 at 03:10:26AM +0100, Markus Heidelberg wrote:
>
>> Vim's SVN repository doesn't offer the latest runtime files, since
>> normally they are only updated there on a release. Though currently
>> there is no difference between the SVN and HTTP/FTP version of the
>> git syntax files.
>
> So their version control _doesn't_ have the latest version, but it is
> available on the website? It's not that I don't believe you, but I
> don't think I want to know the version control workflow that leads to
> that.
Vim is essentially just a one-man project and the maintainer doesn't use
version control system. He just piles "diff -c" -type patches on top of
the previous release and sends them to vim-dev mailing list and to some
FTP site. Then other people try to maintain VCS repositories based on
the patches and resources that are available.
Vim's bus factor: 1
^ permalink raw reply
* Re: how to combine 2 commits?
From: bill lam @ 2009-01-13 7:51 UTC (permalink / raw)
To: git
In-Reply-To: <200901122327.21102.bss@iguanasuicide.net>
On Mon, 12 Jan 2009, Boyd Stephen Smith Jr. wrote:
> git rebase --interactive (read "git help rebase" first)
I tried rebase the last 3 commit, but it failed.
bill@b2j:jproject$ git log --pretty=oneline | head
39ed365c11391bede0e1b6578adfac6619b78c0a for yajpp to use unix LF
70c812db2439bc84a8dd7ea831067b9ebf29885c revert last crlf error
f338a768d635b868e6fddaae670ad91d46ea7c4e format scripts
bill@b2j:jproject$ git rebase -i HEAD~3
error: Entry 'trunk/jcalc/mmenu-mm.ijs' not uptodate. Cannot merge.
fatal: merging of trees a1eafe6cdbb428f851d6ca878bbc53149fb7e7eb and
a00e6dcd3ec3f4ffde0d1aad1958db724093de69 failed
Could not apply 70c812d... revert last crlf error
It looks like cannot resolve conflict of linefeed changes. It was
expected all scripts will conflict, so I have to abort the rebase.
What is the procedure to generate a patch of the HEAD from HEAD~4,
then cancel all changes from HEAD~3 up to HEAD, and then apply the
patch to the previous HEAD~4 ?
BTW, what is the norm of reply in this list, should it be reply to
list only, or reply to group (list plus all cc)?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩213 李商隱 無題二首之二
颯颯東風細雨來 芙蓉塘外有輕雷 金蟾齧璅燒香入 玉虎牽絲汲井迴
賈氏窺簾韓掾少 宓妃留枕魏王才 春心莫共花爭發 一寸想思一寸灰
^ permalink raw reply
* Re: "git diff --stat" doesn't show added empty file
From: Ping Yin @ 2009-01-13 7:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0901120805310.6528@localhost.localdomain>
On Tue, Jan 13, 2009 at 12:13 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 12 Jan 2009, Ping Yin wrote:
>> $ git diff --stat HEAD^..
>> 0 files changed, 0 insertions(+), 0 deletions(-)
>
> In the kernel, we use "git diff --stat --summary" for exactly this reason.
>
> Well, not exactly.
>
> The thing is, even if the file is _not_ empty, there's a huge difference
> between "added 100 lines to an already-existing file" and "created a new
> 100-line file". Which is exactly what "--summary" adds.
>
> And it sometimes even makes sense to show the summary without the
> diffstat. If you're _only_ interested in create/delete/rename information,
> you can do "git show --summary <cmit>". It won't give you line counts, but
> it will give you information about any changes to filenames, eg in the
> kernel archive, you could see an example of this with
>
> git show -M --summary 95b482a8d31116f3f5c2a5089569393234d06385
>
> where you have a combination of renames, creates and deletes.
>
> So I think it's already better than what you ask for.
>
> Linus
>
Thanks. --summary works.
I just want to get all changed files. I think "git diff --name-status
A..B" should be better.
Ping Yin
^ permalink raw reply
* Re: [PATCH] contrib/vim: change URL to point to the latest syntax files
From: Jeff King @ 2009-01-13 7:16 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: git
In-Reply-To: <200901130310.26727.markus.heidelberg@web.de>
On Tue, Jan 13, 2009 at 03:10:26AM +0100, Markus Heidelberg wrote:
> Vim's SVN repository doesn't offer the latest runtime files, since
> normally they are only updated there on a release. Though currently
> there is no difference between the SVN and HTTP/FTP version of the git
> syntax files.
So their version control _doesn't_ have the latest version, but it is
available on the website? It's not that I don't believe you, but I don't
think I want to know the version control workflow that leads to that.
> - http://vim.svn.sourceforge.net/viewvc/vim/trunk/runtime/syntax/gitsendemail.vim
> + http://ftp.vim.org/pub/vim/runtime/syntax/git.vim
Certainly they are nicer looking URLs, and I had just assumed the
originals would be recent-ish version. So:
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: how to combine 2 commits?
From: Matthieu Moy @ 2009-01-13 6:48 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrngmodgv.ple.sitaramc@sitaramc.homelinux.net>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> I like using "git rebase -i HEAD~5" (if I want to rebase the
> last 5 commits). In the editor that pops up, I reorder the
> ones that I know should be together, and on each set to be
> squashed, I change the "pick" to "s" (for squash) on all but
> the first one. Save the file and it's all done.
And right after, you probably want to do stg like
git diff master@{1} master
to see whether you actually changed the result by reordering your
patches.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Simple update to bash completions to prevent unbound variable errors.
From: Teemu Likonen @ 2009-01-13 6:35 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Boyd Stephen Smith Jr., Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <496C1D90.1020609@tedpavlic.com>
Ted Pavlic (2009-01-12 23:50 -0500) wrote:
> NOTE: On my system, I save git-completion.bash to .git_bash_completion.
> Because of that, Vim can't ftdetect off of the file name. The modeline
> allows ft=sh even when you don't end in .sh or .bash.
>
> An alternative (to a Vim modeline) is to put
>
> #!bash
>
> at the top of the script. That would do the same thing as the modeline
> (even though it would never actually get used by the sourced "script").
Another way is to set filetype detection locally. This way the project
files don't get filled with editor-specific stuff. You may want add
something like the following to your ~/.vim/filetype.vim file:
augroup filetypedetect
autocmd BufNewFile,BufRead .git_bash_completion setl ft=sh
augroup END
^ permalink raw reply
* Re: how to combine 2 commits?
From: Sitaram Chamarty @ 2009-01-13 6:35 UTC (permalink / raw)
To: git
In-Reply-To: <20090113045422.GA6940@b2j>
On 2009-01-13, bill lam <cbill.lam@gmail.com> wrote:
> Sorry I don't know the correct git terminology for it. I make some
> changes to scripts but also accidentally changed all scripts to use
> dos linefeed. Failed to notice this and commit all changes. Then I
> tried to correct it by changing all scripts back to unix
> linefeed and commit again.
>
> How to combine these 2 commits so that the changes of linefeed cancel
> out each other and the history only shows the intended changes of the
> few scripts.
I tend to make lots of small commits on the work tree, and
having to combine them meaningfully later.
I like using "git rebase -i HEAD~5" (if I want to rebase the
last 5 commits). In the editor that pops up, I reorder the
ones that I know should be together, and on each set to be
squashed, I change the "pick" to "s" (for squash) on all but
the first one. Save the file and it's all done.
Works like a charm. For me, moving commits around in an
editor, deleting them even, is very intuitive.
^ permalink raw reply
* Re: [PATCH] Simple update to bash completions to prevent unbound variable errors.
From: Junio C Hamano @ 2009-01-13 5:37 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Shawn O. Pearce, git
In-Reply-To: <496C18D8.9070707@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> writes:
>>> +# __gitcomp_1 requires 2 arguments
>>
>> ... and $1 and $2 mean?
>
> No clue. Patches are welcome.
To be absolutely honest, I think people with "set -u" in their interactive
environment are sick. Bourne shells have been substituting unset
variables to empty string for eons, and this is not _my_ itch to scratch.
It seems to be yours, though, and I was merely trying to help.
^ permalink raw reply
* Re: how to combine 2 commits?
From: Imran M Yousuf @ 2009-01-13 5:32 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git, bill lam
In-Reply-To: <200901122327.21102.bss@iguanasuicide.net>
On Tue, Jan 13, 2009 at 11:27 AM, Boyd Stephen Smith Jr.
<bss@iguanasuicide.net> wrote:
> On Monday 12 January 2009, bill lam <cbill.lam@gmail.com> wrote about 'how
> to combine 2 commits?':
>>How to combine these 2 commits so that the changes of linefeed cancel
>>out each other and the history only shows the intended changes of the
>>few scripts.
>
> Two ways I can think of:
> git rebase --interactive (read "git help rebase" first)
> git merge --squash (read "git help merge" first)
>
> The rebase is probably semantically closer to how you are thinking about
> things right now.
Another way I can think of is - git format-patch + git apply, i.e.
first generate 2 patches for the 2 commits and then apply them one on
top of another.
Best regards,
Imran
> --
> Boyd Stephen Smith Jr. ,= ,-_-. =.
> bss@iguanasuicide.net ((_/)o o(\_))
> ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
> http://iguanasuicide.net/ \_/
>
--
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Blog: http://imyousuf-tech.blogs.smartitengineering.com/
Mobile: +880-1711402557
^ permalink raw reply
* Re: how to combine 2 commits?
From: Boyd Stephen Smith Jr. @ 2009-01-13 5:27 UTC (permalink / raw)
To: git; +Cc: bill lam
In-Reply-To: <20090113045422.GA6940@b2j>
[-- Attachment #1: Type: text/plain, Size: 725 bytes --]
On Monday 12 January 2009, bill lam <cbill.lam@gmail.com> wrote about 'how
to combine 2 commits?':
>How to combine these 2 commits so that the changes of linefeed cancel
>out each other and the history only shows the intended changes of the
>few scripts.
Two ways I can think of:
git rebase --interactive (read "git help rebase" first)
git merge --squash (read "git help merge" first)
The rebase is probably semantically closer to how you are thinking about
things right now.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: how to combine 2 commits?
From: Jeff Whiteside @ 2009-01-13 5:08 UTC (permalink / raw)
To: git
In-Reply-To: <20090113045422.GA6940@b2j>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=GB2312, Size: 992 bytes --]
git terminology is "squash"
On Mon, Jan 12, 2009 at 11:54 PM, bill lam <cbill.lam@gmail.com> wrote:
>
> Sorry I don't know the correct git terminology for it. I make some
> changes to scripts but also accidentally changed all scripts to use
> dos linefeed. Failed to notice this and commit all changes. Then I
> tried to correct it by changing all scripts back to unix linefeed and commit again.
>
> How to combine these 2 commits so that the changes of linefeed cancel
> out each other and the history only shows the intended changes of the
> few scripts.
>
> --
> regards,
> ====================================================
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> ÌÆÔŠ234 Àî°× Ô¹Çé
> ÃÀÈË’ÔÖ麟 Éî×øõ¾¶êü µ«ÒŠœIºÛñ ²»ÖªÐĺÞÕl
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Simplest update to bash completions to prevent unbounded variable errors
From: Ted Pavlic @ 2009-01-13 4:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
Another try at fixing bash completions in "set -u" environments.
Here, I've gone back to changing $# to ${#-}, but only where necessary.
Additionally added some comments and omitted things like Vim modelines.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
contrib/completion/git-completion.bash | 42
++++++++++++++++++++++---------
1 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 7b074d7..323829e 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1,3 +1,4 @@
+#!bash
#
# bash completion support for core Git.
#
@@ -50,9 +51,11 @@ case "$COMP_WORDBREAKS" in
*) COMP_WORDBREAKS="$COMP_WORDBREAKS:"
esac
+# __gitdir accepts 0 or 1 arguments (i.e., location)
+# returns location of .git repo
__gitdir ()
{
- if [ -z "$1" ]; then
+ if [ $# -eq 0 ] || [ -z "$1" ]; then
if [ -n "$__git_dir" ]; then
echo "$__git_dir"
elif [ -d .git ]; then
@@ -67,6 +70,8 @@ __gitdir ()
fi
}
+# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
+# returns text to add to bash PS1 prompt (includes branch name)
__git_ps1 ()
{
local g="$(git rev-parse --git-dir 2>/dev/null)"
@@ -111,7 +116,7 @@ __git_ps1 ()
fi
fi
- if [ -n "$1" ]; then
+ if [ $# -gt 0 ] && [ -n "$1" ]; then
printf "$1" "${b##refs/heads/}$r"
else
printf " (%s)" "${b##refs/heads/}$r"
@@ -119,6 +124,7 @@ __git_ps1 ()
fi
}
+# __gitcomp_1 requires 2 arguments
__gitcomp_1 ()
{
local c IFS=' '$'\t'$'\n'
@@ -131,6 +137,8 @@ __gitcomp_1 ()
done
}
+# __gitcomp accepts 1, 2, 3, or 4 arguments
+# generates completion reply with compgen
__gitcomp ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
@@ -143,22 +151,23 @@ __gitcomp ()
;;
*)
local IFS=$'\n'
- COMPREPLY=($(compgen -P "$2" \
- -W "$(__gitcomp_1 "$1" "$4")" \
+ COMPREPLY=($(compgen -P "${2-}" \
+ -W "$(__gitcomp_1 "${1-}" "${4-}")" \
-- "$cur"))
;;
esac
}
+# __git_heads accepts 0 or 1 arguments (to pass to __gitdir)
__git_heads ()
{
- local cmd i is_hash=y dir="$(__gitdir "$1")"
+ local cmd i is_hash=y dir="$(__gitdir "${1-}")"
if [ -d "$dir" ]; then
git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
refs/heads
return
fi
- for i in $(git ls-remote "$1" 2>/dev/null); do
+ for i in $(git ls-remote "${1-}" 2>/dev/null); do
case "$is_hash,$i" in
y,*) is_hash=n ;;
n,*^{}) is_hash=y ;;
@@ -168,15 +177,16 @@ __git_heads ()
done
}
+# __git_tags accepts 0 or 1 arguments (to pass to __gitdir)
__git_tags ()
{
- local cmd i is_hash=y dir="$(__gitdir "$1")"
+ local cmd i is_hash=y dir="$(__gitdir "${1-}")"
if [ -d "$dir" ]; then
git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
refs/tags
return
fi
- for i in $(git ls-remote "$1" 2>/dev/null); do
+ for i in $(git ls-remote "${1-}" 2>/dev/null); do
case "$is_hash,$i" in
y,*) is_hash=n ;;
n,*^{}) is_hash=y ;;
@@ -186,9 +196,10 @@ __git_tags ()
done
}
+# __git_refs accepts 0 or 1 arguments (to pass to __gitdir)
__git_refs ()
{
- local i is_hash=y dir="$(__gitdir "$1")"
+ local i is_hash=y dir="$(__gitdir "${1-}")"
local cur="${COMP_WORDS[COMP_CWORD]}" format refs
if [ -d "$dir" ]; then
case "$cur" in
@@ -218,6 +229,7 @@ __git_refs ()
done
}
+# __git_refs2 requires 1 argument (to pass to __git_refs)
__git_refs2 ()
{
local i
@@ -226,6 +238,7 @@ __git_refs2 ()
done
}
+# __git_refs_remotes requires 1 argument (to pass to ls-remote)
__git_refs_remotes ()
{
local cmd i is_hash=y
@@ -470,6 +483,7 @@ __git_aliases ()
done
}
+# __git_aliased_command requires 1 argument
__git_aliased_command ()
{
local word cmdline=$(git --git-dir="$(__gitdir)" \
@@ -482,6 +496,7 @@ __git_aliased_command ()
done
}
+# __git_find_subcommand requires 1 argument
__git_find_subcommand ()
{
local word subcommand c=1
@@ -1766,13 +1781,16 @@ _gitk ()
__git_complete_revlist
}
-complete -o default -o nospace -F _git git
-complete -o default -o nospace -F _gitk gitk
+complete -o bashdefault -o default -o nospace -F _git git 2>/dev/null \
+ || complete -o default -o nospace -F _git git
+complete -o bashdefault -o default -o nospace -F _gitk gitk 2>/dev/null \
+ || complete -o default -o nospace -F _gitk gitk
# 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.
#
if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
-complete -o default -o nospace -F _git git.exe
+complete -o bashdefault -o default -o nospace -F _git git.exe 2>/dev/null \
+ || complete -o default -o nospace -F _git git.exe
fi
--
1.6.1.87.g15624
^ permalink raw reply related
* how to combine 2 commits?
From: bill lam @ 2009-01-13 4:54 UTC (permalink / raw)
To: git
Sorry I don't know the correct git terminology for it. I make some
changes to scripts but also accidentally changed all scripts to use
dos linefeed. Failed to notice this and commit all changes. Then I
tried to correct it by changing all scripts back to unix linefeed and commit again.
How to combine these 2 commits so that the changes of linefeed cancel
out each other and the history only shows the intended changes of the
few scripts.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩234 李白 怨情
美人捲珠簾 深坐蹙蛾眉 但見淚痕濕 不知心恨誰
^ permalink raw reply
* Re: [PATCH] Simple update to bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-13 4:50 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <496C19E0.6060308@tedpavlic.com>
> Without the modeline, the vim I was using didn't set ft=sh. It seemed
> like the original authors were careful to use tabs everywhere, which was
> the major reason I used the modeline. I added the fdm=marker just in
> case someone would want to clean up the code someday and do some folding.
NOTE: On my system, I save git-completion.bash to .git_bash_completion.
Because of that, Vim can't ftdetect off of the file name. The modeline
allows ft=sh even when you don't end in .sh or .bash.
An alternative (to a Vim modeline) is to put
#!bash
at the top of the script. That would do the same thing as the modeline
(even though it would never actually get used by the sourced "script").
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: [PATCH] Simple update to bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-13 4:34 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <200901122157.03658.bss@iguanasuicide.net>
> While I dislike emacs and use vim pretty much exclusively, I don't really see
> the need for a vim modeline. On top of that, fdm=marker is a bit silly since
> there aren't any markers. ff=unix and ft=sh are redundant, as any vim should
> detect these properly, given the filename.
Without the modeline, the vim I was using didn't set ft=sh. It seemed
like the original authors were careful to use tabs everywhere, which was
the major reason I used the modeline. I added the fdm=marker just in
case someone would want to clean up the code someday and do some folding.
> So, I'm slightly negative on the modeline hunk.
It was just a suggestion.
>> local one=${1-} two=${2-} cur=${3-} four=${4-}
>
> Even better to use variable names that match the usage, if possible.
I don't know much about bash completion. It would be nice if the
original authors could add some semantics, as I was just trying to come
up with scripts that would actually work with set -u.
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: [PATCH] Simple update to bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-13 4:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vy6xfew2n.fsf@gitster.siamese.dyndns.org>
>> A vim modeline has also been added for consistency.
>
> Yuck.
Better that than have a mixture of spaces and tabs.
>> +# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
>> +# returns text to add to bash PS1 prompt (includes branch name)
>
> Good. Would be better if you described what $1 and $2 mean.
In that case, there's only $1 (the format string).
Note that in most cases, I didn't know what $1 and $2 were. I was just
trying to fix it so that it would work on my system.
>> - if [ -n "$1" ]; then
>> + if [ $# -gt 0 ]&& [ -n "$1" ]; then
>
> I found the previous round's [ -n "${1-}" ] much easier to read, if we were to
> do this. If -n "${1-}", then "$1" is definitely set so nothing need to
> change in the then ... else part.
Hey -- I agree, but no one else liked ${1-}. And hg's bash completion
seems far superior because they avoid ever having to worry about it.
They actually thought about the arguments ahead of time.
>> +# __gitcomp_1 requires 2 arguments
>
> ... and $1 and $2 mean?
No clue. Patches are welcome.
> Yuck. If you are taking advantage of the fact that "local one"
> will bind one to emptiness anyway, can't you do something like:
>
> local one=${1-} two=${2-} cur=${3-} four=${4-}
Why even use one, two three, and four then?
I had ${#-} throughout, but I was told that that was ugly. So the best I
could do was come up with the above mess.
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ 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