* [PATCH] checkout: warn about 'branch name' rather than 'local branch'
From: Sverre Rabbelier @ 2010-01-29 21:09 UTC (permalink / raw)
To: Junio C Hamano, Git List, Ron1, Jacob Helwig; +Cc: Sverre Rabbelier
In-Reply-To: <fabb9a1e1001291256j71e2c95cic21cb5a6a0cc1fe8@mail.gmail.com>
These days, you can say "git checkout topic" to automagically create
a local "topic" branch that forks from "origin/topic" remote tracking
branch when you have one, thanks to Dscho's UI improvement ideas. As
such it is more appropriate to say that the user is checking out
something that is not a branch name, rather than saying it is not a
'local branch'.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Junio, I used part of your reply as the commit message, is that ok?
Only change is s/local branch/branch name/.
builtin-checkout.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 5277817..4b34314 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -523,7 +523,7 @@ static void update_refs_for_switch(struct checkout_opts *opts,
REF_NODEREF, DIE_ON_ERR);
if (!opts->quiet) {
if (old->path)
- fprintf(stderr, "Note: moving to '%s' which isn't a local branch\nIf you want to create a new branch from this checkout, you may do so\n(now or later) by using -b with the checkout command again. Example:\n git checkout -b <new_branch_name>\n", new->name);
+ fprintf(stderr, "Note: moving to '%s' which isn't a branch name\nIf you want to create a new branch from this checkout, you may do so\n(now or later) by using -b with the checkout command again. Example:\n git checkout -b <new_branch_name>\n", new->name);
describe_detached_head("HEAD is now at", new->commit);
}
}
--
1.6.6.rc1.56.gaea25.dirty
^ permalink raw reply related
* Re: master^ is not a local branch -- huh?!?
From: Ron1 @ 2010-01-29 21:16 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.1001292131330.3749@intel-tinevez-2-302>
In article <alpine.DEB.1.00.1001292131330.3749@intel-tinevez-2-302>,
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 29 Jan 2010, Jacob Helwig wrote:
>
> > On Fri, Jan 29, 2010 at 12:20, Ron1 <ron1@flownet.com> wrote:
> > > [ron@mickey]$ git checkout master
> > > Already on 'master'
> > > [ron@mickey]$ git checkout master^
> > > Note: moving to 'master^' which isn't a local branch
> > > If you want to create a new branch from this checkout, you may do so
> > > (now or later) by using -b with the checkout command again. Example:
> > > git checkout -b <new_branch_name>
> > > HEAD is now at 7be05e0... test
> > > [ron@mickey]$ git branch
> > > * (no branch)
> > > master
> > > [ron@mickey]$
> > >
> > > Huh?!?
> > >
> > > This is a test repository which has never been pulled from nor pushed to
> > > anywhere. So how is it possible that I have a non-local branch?
> >
> > master^ is a commit (the first parent of master), not a branch (local
> > or otherwise).
>
> Indeed. Maybe you (Ron1) need to get a bit more acquainted to Git before
> complaining.
Chill, dude. I'm not complaining. I'm just confused.
I know that master^ is a commit and not a branch. I thought I was
invoking the third variant of git-checkout (as given on the git-checkout
man page) and checking out a commit (which the man page calls a
tree-ish).
In any case, since my question seems to have sparked some discussion,
I'd like to offer two observations:
1. Saying "isn't a local branch" is mightily confusing, because it is
ambiguous whether the problem is that it isn't a branch or if it isn't
local.
2. If I pass something to git checkout (or any other command for that
matter) that it expects to be a branch but isn't a branch it would be
much better if it just gave an error and did nothing rather than give a
(confusing) warning and try to extrapolate the user's intentions.
Whatever a user could possibly mean by 'git checkout master^' it is
almost certainly not what that command actually does at the moment.
rg
^ permalink raw reply
* Re: Please pull gitk.git master branch
From: Junio C Hamano @ 2010-01-29 20:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
In-Reply-To: <20100129115927.GD2585@brick.ozlabs.ibm.com>
Thanks; will do.
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Sverre Rabbelier @ 2010-01-29 20:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Ron1, Jacob Helwig
In-Reply-To: <7veil8iqnj.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Jan 29, 2010 at 21:48, Junio C Hamano <gitster@pobox.com> wrote:
> I think "not a branch" is a good suggestion, whether the target of
> checkout is "master^" or "origin/topic".
Mhhh, for added clarity, do we want to change it to "branch name"? Since ...
$ git grep "branch name" Documentation/ | wc -l
58
... suggests that we use that in other places as well?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-01-29 20:48 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List, Ron1, Jacob Helwig
In-Reply-To: <fabb9a1e1001291235h26681e65qe4851cae1c536b6d@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
>> master^ is a commit (the first parent of master), not a branch (local
>> or otherwise).
>
> Perhaps we should change the message to say "not a branch" if it's not
> a reference to a remote branch? Or simply changing the text to "not a
> (local) branch"?
I think "not a branch" is a good suggestion, whether the target of
checkout is "master^" or "origin/topic".
These days, you can say "git checkout topic" to automagically create a
local "topic" branch that forks from "origin/topic" remote tracking branch
when you have one, thanks to Dscho's UI improvement ideas (one less
reason you may end up on a detached HEAD state without wanting to).
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Scott R. Godin @ 2010-01-29 20:36 UTC (permalink / raw)
To: git
In-Reply-To: <ron1-2E17EF.12204629012010@news.gmane.org>
On 01/29/2010 03:20 PM, Ron1 wrote:
> [ron@mickey]$ git checkout master
> Already on 'master'
> [ron@mickey]$ git checkout master^
> Note: moving to 'master^' which isn't a local branch
> If you want to create a new branch from this checkout, you may do so
> (now or later) by using -b with the checkout command again. Example:
> git checkout -b<new_branch_name>
> HEAD is now at 7be05e0... test
> [ron@mickey]$ git branch
> * (no branch)
> master
> [ron@mickey]$
>
> Huh?!?
>
> This is a test repository which has never been pulled from nor pushed to
> anywhere. So how is it possible that I have a non-local branch?
>
> Thanks,
> rg
>
I believe what you're seeing is known as a detached head (see
<http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html>
though I could be wrong about this.)
I think you may have intended to do git checkout HEAD^ or something
similar? basically what you did was (I think) checkout (or attempt to
checkout) the parent commit on master.
this may offer some additional food for thought:
<http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html#_exploring_history>
--
(please respond to the list as opposed to my email box directly,
unless you are supplying private information you don't want public
on the list)
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Jacob Helwig @ 2010-01-29 20:38 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List, Ron1
In-Reply-To: <fabb9a1e1001291235h26681e65qe4851cae1c536b6d@mail.gmail.com>
On Fri, Jan 29, 2010 at 12:35, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Fri, Jan 29, 2010 at 21:27, Jacob Helwig <jacob.helwig@gmail.com> wrote:
>> On Fri, Jan 29, 2010 at 12:20, Ron1 <ron1@flownet.com> wrote:
>>> This is a test repository which has never been pulled from nor pushed to
>>> anywhere. So how is it possible that I have a non-local branch?
>>
>> master^ is a commit (the first parent of master), not a branch (local
>> or otherwise).
>
> Perhaps we should change the message to say "not a branch" if it's not
> a reference to a remote branch? Or simply changing the text to "not a
> (local) branch"?
>
I think "not a branch" would be better than "not a (local) branch".
In my mind, the latter reads almost exactly the same as the current
message.
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Octavio Alvarez @ 2010-01-29 20:32 UTC (permalink / raw)
To: Ron1, git
In-Reply-To: <ron1-2E17EF.12204629012010@news.gmane.org>
On Fri, 29 Jan 2010 12:20:46 -0800, Ron1 <ron1@flownet.com> wrote:
> [ron@mickey]$ git checkout master
> Already on 'master'
> [ron@mickey]$ git checkout master^
> Note: moving to 'master^' which isn't a local branch
> If you want to create a new branch from this checkout, you may do so
> (now or later) by using -b with the checkout command again. Example:
> git checkout -b <new_branch_name>
> HEAD is now at 7be05e0... test
> [ron@mickey]$ git branch
> * (no branch)
> master
> [ron@mickey]$
>
> Huh?!?
>
> This is a test repository which has never been pulled from nor pushed to
> anywhere. So how is it possible that I have a non-local branch?
"Is a non-local branch" is not the same as "is not a local branch".
Think "branches" as tags that advance when you commit over them.
If you do gitk --all, only those commits with a green tag are
"branches".
It means that if you switch to master^ and commit, your commit will
be applied but not tracked (since there is not any branch to advance).
You would need to do git checkout -b 'new_branch', and then commit.
Now, new_branch will advance with your new commit.
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Sverre Rabbelier @ 2010-01-29 20:35 UTC (permalink / raw)
To: Git List; +Cc: Ron1, Jacob Helwig
In-Reply-To: <8c9a061001291227v34ca0745l1ab35ef6ca5863dc@mail.gmail.com>
Heya,
On Fri, Jan 29, 2010 at 21:27, Jacob Helwig <jacob.helwig@gmail.com> wrote:
> On Fri, Jan 29, 2010 at 12:20, Ron1 <ron1@flownet.com> wrote:
>> This is a test repository which has never been pulled from nor pushed to
>> anywhere. So how is it possible that I have a non-local branch?
>
> master^ is a commit (the first parent of master), not a branch (local
> or otherwise).
Perhaps we should change the message to say "not a branch" if it's not
a reference to a remote branch? Or simply changing the text to "not a
(local) branch"?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Johannes Schindelin @ 2010-01-29 20:35 UTC (permalink / raw)
To: Jacob Helwig; +Cc: Ron1, git
In-Reply-To: <8c9a061001291227v34ca0745l1ab35ef6ca5863dc@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1517 bytes --]
Hi,
On Fri, 29 Jan 2010, Jacob Helwig wrote:
> On Fri, Jan 29, 2010 at 12:20, Ron1 <ron1@flownet.com> wrote:
> > [ron@mickey]$ git checkout master
> > Already on 'master'
> > [ron@mickey]$ git checkout master^
> > Note: moving to 'master^' which isn't a local branch
> > If you want to create a new branch from this checkout, you may do so
> > (now or later) by using -b with the checkout command again. Example:
> > git checkout -b <new_branch_name>
> > HEAD is now at 7be05e0... test
> > [ron@mickey]$ git branch
> > * (no branch)
> > master
> > [ron@mickey]$
> >
> > Huh?!?
> >
> > This is a test repository which has never been pulled from nor pushed to
> > anywhere. So how is it possible that I have a non-local branch?
>
> master^ is a commit (the first parent of master), not a branch (local
> or otherwise).
Indeed. Maybe you (Ron1) need to get a bit more acquainted to Git before
complaining.
Git is not user-friendly (much to my chagrin, and I tried to change it,
but it is not going to happen), so the only way out is to really read up
on good tutorials/manuals before you complain about something that is not
working as you expect it.
Just as a general hint, I think the best documentation about Git was
written by J. Bruce Fields (the user manual) and Scott Chacon (everything
that has GitHub written on it, and Git Pro, and much, much more). If you
happen to speak Japanese, Junio's book might help you understand the ideas
behind the current Git user interface, too.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] bash: support user-supplied completion scripts for user's git commands
From: Junio C Hamano @ 2010-01-29 20:32 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Shawn O. Pearce, David Rhodes Clymer, git
In-Reply-To: <20100129190642.GA31303@neumann>
SZEDER Gábor <szeder@ira.uka.de> writes:
> Instead of having a huge hard-coded list of command-completion
> function pairs (in _git()), the completion script will figure out
> which completion function to call based on the command's name. That
> is, when completing the options of 'git foo', the main completion
> script will check whether the function '_git_foo' is declared, and if
> declared, it will invoke that function to perform the completion. If
> such a function is not declared, it will fall back to complete file
> names. So, users will only need to provide this '_git_foo' completion
> function in a separate file, source that file, and it will be used the
> next time they press TAB after 'git foo '.
I think the basic idea is sound, but I have a minor issue with the names.
Admittedly, we have already taken over _git_foo (and "_git") namespace,
and anybody who uses bash with the completion support cannot write their
own shell function with these names for purposes that are unrelated to
completion, so in that sense, the patch is not introducing a new problem,
but making it a documented interface and casting it in stone will make the
namespace contamination issue harder to rectify later.
So if we were to go in the direction as the patch proposes (which I think
is a good idea), we might want to rename them to __git_completion_foo or
something that is less likely to collide with whatever names users might
want to use. It is my understanding that the only published interface so
far is __git_ps1.
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Jacob Helwig @ 2010-01-29 20:27 UTC (permalink / raw)
To: Ron1; +Cc: git
In-Reply-To: <ron1-2E17EF.12204629012010@news.gmane.org>
On Fri, Jan 29, 2010 at 12:20, Ron1 <ron1@flownet.com> wrote:
> [ron@mickey]$ git checkout master
> Already on 'master'
> [ron@mickey]$ git checkout master^
> Note: moving to 'master^' which isn't a local branch
> If you want to create a new branch from this checkout, you may do so
> (now or later) by using -b with the checkout command again. Example:
> git checkout -b <new_branch_name>
> HEAD is now at 7be05e0... test
> [ron@mickey]$ git branch
> * (no branch)
> master
> [ron@mickey]$
>
> Huh?!?
>
> This is a test repository which has never been pulled from nor pushed to
> anywhere. So how is it possible that I have a non-local branch?
>
> Thanks,
> rg
>
master^ is a commit (the first parent of master), not a branch (local
or otherwise).
^ permalink raw reply
* master^ is not a local branch -- huh?!?
From: Ron1 @ 2010-01-29 20:20 UTC (permalink / raw)
To: git
[ron@mickey]$ git checkout master
Already on 'master'
[ron@mickey]$ git checkout master^
Note: moving to 'master^' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at 7be05e0... test
[ron@mickey]$ git branch
* (no branch)
master
[ron@mickey]$
Huh?!?
This is a test repository which has never been pulled from nor pushed to
anywhere. So how is it possible that I have a non-local branch?
Thanks,
rg
^ permalink raw reply
* Re: [RFC/PATCH] MSVC: Windows-native implementation of pthread_cond_broadcast
From: Johannes Schindelin @ 2010-01-29 20:13 UTC (permalink / raw)
To: Zoltán Füzesi; +Cc: git, j.sixt
In-Reply-To: <1264793213-8805-1-git-send-email-zfuzesi@eaglet.hu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 437 bytes --]
Hi,
On Fri, 29 Jan 2010, Zoltán Füzesi wrote:
> Johannes, how about this?
Do you really mean me?
> I haven't tested it.
Then why the hell do you address me????
Seriously again, please test first before you post this. Once you have
real proof that it works as you intend it, I will be _happy_ to have a
look and most likely merge it into 4msysgit.git. Before you tested it, I
will be just annoyed.
Thanks for your work,
Dscho
^ permalink raw reply
* Re: [PATCH] bash: support user-supplied completion scripts for user's git commands
From: Shawn O. Pearce @ 2010-01-29 20:04 UTC (permalink / raw)
To: SZEDER G?bor; +Cc: Junio C Hamano, David Rhodes Clymer, git
In-Reply-To: <20100129200033.GA32636@neumann>
SZEDER G?bor <szeder@ira.uka.de> wrote:
>
> _git_lgm () {
> _git_log
> }
>
> Unfortunately, it doesn't work at all.
>
> In _git() first we have 'lgm' in $command, which is ok, but then comes
> this alias handling thing
>
> local expansion=$(__git_aliased_command "$command")
> [ "$expansion" ] && command="$expansion"
>
> which writes '!sh' into $command, and that doesn't look quite right
__git_aliased_command is returning the first word out of the alias.
I think we need to change this block here to:
case "$expansion" of
\!*) : leave command as alias ;;
'') : leave command alone ;;
*) command="$expansion" ;;
esac
Or something like that. Because an alias whose value starts with
! is a shell command to be executed, so we want to use _git_$command
for completion, but other aliases are builtin commands and we should
use their first word token (what __git_aliased_command returns)
as the name of the completion function.
I think. :-)
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH] MSVC: Windows-native implementation of pthread_cond_broadcast
From: Johannes Sixt @ 2010-01-29 20:02 UTC (permalink / raw)
To: Zoltán Füzesi; +Cc: git
In-Reply-To: <1264793213-8805-1-git-send-email-zfuzesi@eaglet.hu>
On Freitag, 29. Januar 2010, Zoltán Füzesi wrote:
> Johannes, how about this? I haven't tested it.
Neither have I, but I do not expect that it work: You neither modify the
waiters count nor do you wait for it to be modified; IOW, you have a busy
loop. cond_broadcast is not that trivial. I hope to send a patch tonight.
-- Hannes
^ permalink raw reply
* Re: [PATCH] bash: support user-supplied completion scripts for user's git commands
From: SZEDER Gábor @ 2010-01-29 20:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, David Rhodes Clymer, git
In-Reply-To: <20100129191326.GD22101@spearce.org>
Hi Shawn,
On Fri, Jan 29, 2010 at 11:13:26AM -0800, Shawn O. Pearce wrote:
> SZEDER G?bor <szeder@ira.uka.de> wrote:
> > How about something like this for subcommands (not aliases)? It's a
> > good code size reduction anyway.
>
> Hmm, I like this. I just didn't know how to implement it... :-)
>
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
>
> > + local completion_func="_git_${command//-/_}"
> > + declare -F $completion_func >/dev/null && $completion_func
>
> Yay for knowing bash. :-)
Heh. I've found out about this 'declare -F' thing about two hours ago
(;
However.
I thought this should actually "Just Work" for aliases, too. e.g.
Junio could use the following completion function to get 'git log's
options for his lgm alias:
_git_lgm () {
_git_log
}
Unfortunately, it doesn't work at all.
In _git() first we have 'lgm' in $command, which is ok, but then comes
this alias handling thing
local expansion=$(__git_aliased_command "$command")
[ "$expansion" ] && command="$expansion"
which writes '!sh' into $command, and that doesn't look quite right
for me, although I admit that I can't seem to figure out how this
__git_aliased_command() is supposed to work (so much about knowing
bash ;). Any insight?
Best,
Gábor
^ permalink raw reply
* [RFC/PATCH] MSVC: Windows-native implementation of pthread_cond_broadcast
From: Zoltán Füzesi @ 2010-01-29 19:26 UTC (permalink / raw)
To: git; +Cc: j.sixt, Zoltán Füzesi
In-Reply-To: <4B62CEAB.5050608@viscovery.net>
Threaded grep feature relies on this function, but its implementation was
missing from the Win32 Pthreads API.
Signed-off-by: Zoltán Füzesi <zfuzesi@eaglet.hu>
---
Johannes, how about this? I haven't tested it.
compat/win32/pthread.c | 12 ++++++++++++
compat/win32/pthread.h | 2 ++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/compat/win32/pthread.c b/compat/win32/pthread.c
index 631c0a4..498b552 100644
--- a/compat/win32/pthread.c
+++ b/compat/win32/pthread.c
@@ -108,3 +108,15 @@ int pthread_cond_signal(pthread_cond_t *cond)
else
return 0;
}
+
+int pthread_cond_broadcast(pthread_cond_t *cond)
+{
+ LONG prev_count;
+ while (cond->waiters) {
+ if (!ReleaseSemaphore(cond->sema, 1, &prev_count))
+ return err_win_to_posix(GetLastError());
+ if (prev_count == LONG_MAX - 1)
+ break;
+ }
+ return 0;
+}
diff --git a/compat/win32/pthread.h b/compat/win32/pthread.h
index b8e1bcb..11426f5 100644
--- a/compat/win32/pthread.h
+++ b/compat/win32/pthread.h
@@ -44,6 +44,8 @@ extern int pthread_cond_wait(pthread_cond_t *cond, CRITICAL_SECTION *mutex);
extern int pthread_cond_signal(pthread_cond_t *cond);
+extern int pthread_cond_broadcast(pthread_cond_t *cond);
+
/*
* Simple thread creation implementation using pthread API
*/
--
1.7.0.rc0.48.gdace5.dirty
^ permalink raw reply related
* Re: [PATCH] bash: support user-supplied completion scripts for user's git commands
From: Shawn O. Pearce @ 2010-01-29 19:13 UTC (permalink / raw)
To: SZEDER G?bor; +Cc: Junio C Hamano, David Rhodes Clymer, git
In-Reply-To: <20100129190642.GA31303@neumann>
SZEDER G?bor <szeder@ira.uka.de> wrote:
> The bash completion script already provides support to complete
> aliases, options and refs for aliases (if the alias can be traced back
> to a supported git command by __git_aliased_command()), and the user's
> custom git commands, but it does not support the options of the user's
> custom git commands (of course; how could it know about the options of
> a custom git command?). Users of such custom git commands could
> extend git's bash completion script by writing functions to support
> their commands, but they might have issues with it: they might not
> have the rights to modify a system-wide git completion script, and
> they will need to track and merge upstream changes in the future.
>
> This patch addresses this by providing means for users to supply
> custom completion scriplets for their custom git commands without
> modifying the main git bash completion script.
>
> Instead of having a huge hard-coded list of command-completion
> function pairs (in _git()), the completion script will figure out
> which completion function to call based on the command's name. That
> is, when completing the options of 'git foo', the main completion
> script will check whether the function '_git_foo' is declared, and if
> declared, it will invoke that function to perform the completion. If
> such a function is not declared, it will fall back to complete file
> names. So, users will only need to provide this '_git_foo' completion
> function in a separate file, source that file, and it will be used the
> next time they press TAB after 'git foo '.
>
> There are two git commands (stage and whatchanged), for which the
> completion functions of other commands were used, therefore they
> got their own completion function.
>
> Signed-off-by: SZEDER G?bor <szeder@ira.uka.de>
> ---
>
> How about something like this for subcommands (not aliases)? It's a
> good code size reduction anyway.
Hmm, I like this. I just didn't know how to implement it... :-)
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> + local completion_func="_git_${command//-/_}"
> + declare -F $completion_func >/dev/null && $completion_func
Yay for knowing bash. :-)
--
Shawn.
^ permalink raw reply
* [PATCH] bash: support user-supplied completion scripts for user's git commands
From: SZEDER Gábor @ 2010-01-29 19:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, David Rhodes Clymer, git
In-Reply-To: <7vockciyb8.fsf@alter.siamese.dyndns.org>
The bash completion script already provides support to complete
aliases, options and refs for aliases (if the alias can be traced back
to a supported git command by __git_aliased_command()), and the user's
custom git commands, but it does not support the options of the user's
custom git commands (of course; how could it know about the options of
a custom git command?). Users of such custom git commands could
extend git's bash completion script by writing functions to support
their commands, but they might have issues with it: they might not
have the rights to modify a system-wide git completion script, and
they will need to track and merge upstream changes in the future.
This patch addresses this by providing means for users to supply
custom completion scriplets for their custom git commands without
modifying the main git bash completion script.
Instead of having a huge hard-coded list of command-completion
function pairs (in _git()), the completion script will figure out
which completion function to call based on the command's name. That
is, when completing the options of 'git foo', the main completion
script will check whether the function '_git_foo' is declared, and if
declared, it will invoke that function to perform the completion. If
such a function is not declared, it will fall back to complete file
names. So, users will only need to provide this '_git_foo' completion
function in a separate file, source that file, and it will be used the
next time they press TAB after 'git foo '.
There are two git commands (stage and whatchanged), for which the
completion functions of other commands were used, therefore they
got their own completion function.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
How about something like this for subcommands (not aliases)? It's a
good code size reduction anyway.
contrib/completion/git-completion.bash | 67 ++++++--------------------------
1 files changed, 12 insertions(+), 55 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index da46bf8..2cecf4f 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1433,6 +1433,11 @@ _git_send_email ()
COMPREPLY=()
}
+_git_stage ()
+{
+ _git_add
+}
+
__git_config_get_set_variables ()
{
local prevword word config_file= c=$COMP_CWORD
@@ -2164,6 +2169,11 @@ _git_tag ()
esac
}
+_git_whatchanged ()
+{
+ _git_log
+}
+
_git ()
{
local i c=1 command __git_dir
@@ -2203,61 +2213,8 @@ _git ()
local expansion=$(__git_aliased_command "$command")
[ "$expansion" ] && command="$expansion"
- case "$command" in
- am) _git_am ;;
- add) _git_add ;;
- apply) _git_apply ;;
- archive) _git_archive ;;
- bisect) _git_bisect ;;
- bundle) _git_bundle ;;
- branch) _git_branch ;;
- checkout) _git_checkout ;;
- cherry) _git_cherry ;;
- cherry-pick) _git_cherry_pick ;;
- clean) _git_clean ;;
- clone) _git_clone ;;
- commit) _git_commit ;;
- config) _git_config ;;
- describe) _git_describe ;;
- diff) _git_diff ;;
- difftool) _git_difftool ;;
- fetch) _git_fetch ;;
- format-patch) _git_format_patch ;;
- fsck) _git_fsck ;;
- gc) _git_gc ;;
- grep) _git_grep ;;
- help) _git_help ;;
- init) _git_init ;;
- log) _git_log ;;
- ls-files) _git_ls_files ;;
- ls-remote) _git_ls_remote ;;
- ls-tree) _git_ls_tree ;;
- merge) _git_merge;;
- mergetool) _git_mergetool;;
- merge-base) _git_merge_base ;;
- mv) _git_mv ;;
- name-rev) _git_name_rev ;;
- notes) _git_notes ;;
- pull) _git_pull ;;
- push) _git_push ;;
- rebase) _git_rebase ;;
- remote) _git_remote ;;
- replace) _git_replace ;;
- reset) _git_reset ;;
- revert) _git_revert ;;
- rm) _git_rm ;;
- send-email) _git_send_email ;;
- shortlog) _git_shortlog ;;
- show) _git_show ;;
- show-branch) _git_show_branch ;;
- stash) _git_stash ;;
- stage) _git_add ;;
- submodule) _git_submodule ;;
- svn) _git_svn ;;
- tag) _git_tag ;;
- whatchanged) _git_log ;;
- *) COMPREPLY=() ;;
- esac
+ local completion_func="_git_${command//-/_}"
+ declare -F $completion_func >/dev/null && $completion_func
}
_gitk ()
--
1.7.0.rc0.78.g2070a
^ permalink raw reply related
* Re: [PATCH] fast-import: Stream very large blobs directly to pack
From: Shawn O. Pearce @ 2010-01-29 18:44 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git, Nicolas Pitre
In-Reply-To: <fabb9a1e1001291041w48776835m9b291923fbb859c3@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Fri, Jan 29, 2010 at 19:37, Shawn O. Pearce <spearce@spearce.org> wrote:
> > I was intentionally slating this for maint, to fix a bug a user
> > reported when handling large streams.
>
> Ah, sorry, did not notice that.
>
> Speaking of which, how does one figure out what commit a patch
> is/could be based on? Couldn't we include that in the part behind the
> triple dash?
You have to tell the other guy in your cover letter section. You can
try to guess if the index information is accurate by grepping
around a log output looking for that blob sha-1 and then finding
what branch that's in. Its not pretty.
IIRC other DVCS systems include the ancestor identity in their
patch output. Git doesn't bother, because in a multi-patch series
the 2nd (and subsequent) patches would have useless id information.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] fast-import: Stream very large blobs directly to pack
From: Sverre Rabbelier @ 2010-01-29 18:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, Nicolas Pitre
In-Reply-To: <20100129183705.GB22101@spearce.org>
Heya,
On Fri, Jan 29, 2010 at 19:37, Shawn O. Pearce <spearce@spearce.org> wrote:
> I was intentionally slating this for maint, to fix a bug a user
> reported when handling large streams.
Ah, sorry, did not notice that.
Speaking of which, how does one figure out what commit a patch
is/could be based on? Couldn't we include that in the part behind the
triple dash?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] fast-import: Stream very large blobs directly to pack
From: Shawn O. Pearce @ 2010-01-29 18:37 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git, Nicolas Pitre
In-Reply-To: <fabb9a1e1001291035l5cd09cb6q1f12037f96dce8a1@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Fri, Jan 29, 2010 at 02:23, Shawn O. Pearce <spearce@spearce.org> wrote:
> > index 60d0aa2..8114f93 100644
>
> Looks like you based it off an old version of fast-import, at least
> not on what is in master atm, since that has my fast-import series.
> Rebasing shouldn't be too hard, you'll just have to move the option
> parsing to the appropriate function.
I was intentionally slating this for maint, to fix a bug a user
reported when handling large streams.
But yea... I guess I also owe Junio a rebased form for master so
he has less merge conflicts to resolve.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] fast-import: Stream very large blobs directly to pack
From: Sverre Rabbelier @ 2010-01-29 18:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, Nicolas Pitre
In-Reply-To: <20100129012350.GD20488@spearce.org>
Heya,
On Fri, Jan 29, 2010 at 02:23, Shawn O. Pearce <spearce@spearce.org> wrote:
> index 60d0aa2..8114f93 100644
Looks like you based it off an old version of fast-import, at least
not on what is in master atm, since that has my fast-import series.
Rebasing shouldn't be too hard, you'll just have to move the option
parsing to the appropriate function.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2] fast-import: Stream very large blobs directly to pack
From: Shawn O. Pearce @ 2010-01-29 18:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Nicolas Pitre
In-Reply-To: <m3aavwbwaz.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Documentation/git-fast-import.txt | 6 ++
> > fast-import.c | 172 +++++++++++++++++++++++++++++++++----
> > t/t5705-clone-2gb.sh | 2 +-
> > t/t9300-fast-import.sh | 46 ++++++++++
> > 4 files changed, 208 insertions(+), 18 deletions(-)
>
> > +--big-file-threshold=<n>::
> > + Maximum size of a blob that fast-import will attempt to
> > + create a delta for, expressed in MiB. The default is 512.
> > + Some importers may wish to lower this on systems with
> > + constrained memory.
> > +
>
> Shouldn't there be config variable corresponding to this command line
> option, so that it can be set once for [constrained] system?
Implemented as core.bigFileThreshold in this patch... but I didn't
document it...
--
Shawn.
^ 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