Junio C Hamano wrote:
> But it turns out that in the context of these functions it refers to
> "what users consider paths in objects stored in the object database"
> (as opposed to working tree paths). That is what ls-tree would take
> (i.e. and :). And I do not offhand think
> of a better name
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Revert 77c1305 and 3c3b46b
>
> The core of the argument seems to be that
> __git_complete_revlist_file() is a misleading name for the completion
> done by archive and ls-tree, but __git_complete_file() is somehow a
> less misleading name
Junio C Hamano wrote:
> Revert 77c1305 and 3c3b46b
The core of the argument seems to be that
__git_complete_revlist_file() is a misleading name for the completion
done by archive and ls-tree, but __git_complete_file() is somehow a
less misleading name? Irrespective of what the valid completio
SZEDER Gábor writes:
>> There still remain two users of __git_complete_file, completions for
>> "archive" and "ls-tree". As these commands do not take range
>> notation, and "git show" no longer uses __git_complete_file, the
>> implementation of can be updated not to complete ranges, but that is
Hi,
On Sun, Jun 09, 2013 at 02:20:33PM -0700, Junio C Hamano wrote:
> Regarding that rr/complete-difftool topic, let's revert the tip 2
> commits (the "ls-tree, archive and show" one, and the follow-up
> resurrection of __git_complete_file) with this:
>
> Revert 77c1305 and 3c3b46b
>
>
SZEDER Gábor writes:
>> It is somewhat annoying that "git diff gi" stops at expanding
>> it to "git diff git" and then upon another "git diff git"
>> offers tags whose names begin with "git" (e.g. gitgui-0.10.0) but
>> the pathname git.c is not included in the choices. My wish was to
>> take the
Ramkumar Ramachandra writes:
> Yes, please merge. The commit message looks good as well: it doesn't
> say anything about waiting for 2.0.
The commit message doesn't, but the doc does. I'll resend without the
2.0 mention.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from
Junio C Hamano wrote:
> * mm/color-auto-default (2013-05-15) 2 commits
> - make color.ui default to 'auto'
> - config: refactor management of color.ui's default value
>
> Flip the default for color.ui to 'auto', which is what many
> tutorials recommend new users to do. The updated code claims
On Fri, Jun 07, 2013 at 02:53:02PM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > On Fri, Jun 07, 2013 at 12:46:25PM -0700, Junio C Hamano wrote:
> >> Thanks for a pointer. I think what I was suggesting was slightly
> >> different in that I was hoping to see a single helper that knows
SZEDER Gábor writes:
> On Fri, Jun 07, 2013 at 12:46:25PM -0700, Junio C Hamano wrote:
>> Thanks for a pointer. I think what I was suggesting was slightly
>> different in that I was hoping to see a single helper that knows to
>> complete to object names (possibly including trees/blobs with the
>
On Fri, Jun 07, 2013 at 12:46:25PM -0700, Junio C Hamano wrote:
> Thanks for a pointer. I think what I was suggesting was slightly
> different in that I was hoping to see a single helper that knows to
> complete to object names (possibly including trees/blobs with the
> treeish:path notation), ran
On Sat, Jun 08, 2013 at 01:17:28AM +0530, Ramkumar Ramachandra wrote:
> SZEDER Gábor wrote:
> > because nowadays __git_complete_file() is a wrapper around
> > __git_complete_revlist_file().
>
> What? It was never anything different from a poorly-named alias for
> __git_complete_revlist_file().
A
SZEDER Gábor wrote:
> because nowadays __git_complete_file() is a wrapper around
> __git_complete_revlist_file().
What? It was never anything different from a poorly-named alias for
__git_complete_revlist_file(). You have already agreed that
__git_complete_file() is a horrible name, so why not d
SZEDER Gábor writes:
>> Now I do not recall suggesting it, and you (and I today after 2
>> years) may disagree with the rationale, but at least we can read
>> what was the "intended" meaning, I think.
>
> See
>
> http://thread.gmane.org/gmane.comp.version-control.git/167728/focus=168838
>
> I s
On Thu, Jun 06, 2013 at 06:05:44PM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote:
> >> * rr/complete-difftool (2013-06-03) 2 commits
> >> (merged to 'next' on 2013-06-04 at 01c7611)
> >> + completion: clarify ls-tree, a
On Fri, Jun 07, 2013 at 11:41:07AM -0700, Junio C Hamano wrote:
> "git log -Gcomplete_file -p contrib/completion" found this one:
>
> commit 1d66ec587e7d903afdf12a81718772a9eadc15a1
> Author: SZEDER Gábor
> Date: Thu Mar 10 19:12:29 2011 +0100
>
> bash: complete 'git diff ...branc'
(snip)
Junio C Hamano wrote:
> "git log -Gcomplete_file -p contrib/completion" found this one:
>
> Now I do not recall suggesting it, and you (and I today after 2
> years) may disagree with the rationale, but at least we can read
> what was the "intended" meaning, I think.
Having spent so much time docum
On Fri, Jun 07, 2013 at 11:00:14PM +0530, Ramkumar Ramachandra wrote:
> SZEDER Gábor wrote:
> > the one at the top because
> > of the reasons given in $gmane/226272
>
> Sorry about the delay: I went to sleep for a couple of days :P
>
> > the one at the bottom because
> > of the misleading commit
Ramkumar Ramachandra writes:
> SZEDER Gábor wrote:
>> the one at the top because
>> of the reasons given in $gmane/226272
>
> Sorry about the delay: I went to sleep for a couple of days :P
>
>> the one at the bottom because
>> of the misleading commit message (__git_complete_file() always
>> comp
SZEDER Gábor wrote:
> the one at the top because
> of the reasons given in $gmane/226272
Sorry about the delay: I went to sleep for a couple of days :P
> the one at the bottom because
> of the misleading commit message (__git_complete_file() always
> completed refs first as part of the ref:file n
Forgot to cc; sorry about that.
Junio C Hamano writes:
> SZEDER Gábor writes:
>
>> On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote:
>>> * rr/complete-difftool (2013-06-03) 2 commits
>>> (merged to 'next' on 2013-06-04 at 01c7611)
>>> + completion: clarify ls-tree, archive, sho
SZEDER Gábor writes:
> On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote:
>> * rr/complete-difftool (2013-06-03) 2 commits
>> (merged to 'next' on 2013-06-04 at 01c7611)
>> + completion: clarify ls-tree, archive, show completion
>> + completion: difftool takes both revs and files
On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote:
> * rr/complete-difftool (2013-06-03) 2 commits
> (merged to 'next' on 2013-06-04 at 01c7611)
> + completion: clarify ls-tree, archive, show completion
> + completion: difftool takes both revs and files
>
> Update command line co
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-publi
24 matches
Mail list logo
