Felipe Contreras wrote:
> First of all, 'gitfast' is just the name I gave to the oh-my-zsh
> plugin that uses git.git's completion stuff. The zsh support in git's
> bash completion has been working for years, I just copied the stuff to
> oh-my-zsh so those guys can use it easily.
Yeah, I know. I
Ramkumar Ramachandra writes:
> In its current form, the note talks about separating options from
> "branch names" and "refnames" in the same sentence. This is entirely
> inaccurate, as the rev spec need not be a set of branch names or ref
> names. Rewrite it to use the word "revisions".
>
> Sig
Ramkumar Ramachandra writes:
> First, and are ways to specify "revisions", not
> "commits", as gitrevisions.txt would indicate. Second,
> '..' is simply indicative of how users would normally
> want to specify the rev spec: it need not conform to this form, and
> can take any form that gitrevi
Johannes Sixt wrote:
> Am 21.04.2013 02:05, schrieb Jonathan Nieder:
>> Junio C Hamano wrote:
>>> But a _real user_ who wants to use a slash there has no way of doing
>>> so.
>>
>> Doesn't foo=// do that in the msys world? If I am reading
>> mingw/msys/rt/src/winsup/cygwin/path.cc correctly then
Am 21.04.2013 02:05, schrieb Jonathan Nieder:
> Junio C Hamano wrote:
>
>> But a _real user_ who wants to use a slash there has no way of doing
>> so.
>
> Doesn't foo=// do that in the msys world? If I am reading
> mingw/msys/rt/src/winsup/cygwin/path.cc correctly then the way to pass
> a true d
On Sat, Apr 20, 2013 at 11:36 PM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> To complement the reason; the zsh folks (or perhaps it's only one; who
>> works on the git stuff), absolutely prioritize "correctness" over
>> speed, that means if it takes ten seconds to list all the possib
Hi,
William Giokas wrote:
> $ git clone /tmp/foo:bar/baz /tmp/new-baz
>
> but running this gives me this output::
>
> Cloning into 'new-baz'...
> ssh: Could not resolve hostname /tmp/foo: Success
> fatal: Could not read from remote repository.
Here's a toy patch. I haven't thoug
Acked-by: Eric Wong
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
All,
It was brought to my attention today that git has some weird behaviour
when colons (:) are used in directory names.
In my distros packaging system, for git repositories we clone a bare
repo and then clone that bare repo locally as a temporary build
directory (no, we can't use cp, it's a bare
Felipe Contreras wrote:
> To complement the reason; the zsh folks (or perhaps it's only one; who
> works on the git stuff), absolutely prioritize "correctness" over
> speed, that means if it takes ten seconds to list all the possible
> files to complete, grouped nicely, that's exactly what they'll
On Sat, Apr 20, 2013 at 03:18:38PM -0700, Jonathan Nieder wrote:
> The "sometimes you just want to pass a command to 'exec'" use case
> does not convince me. I equally well might want to run "git" after
> another command, or run "git" if and only if a repository exists
> there, or do any number o
On Sat, Apr 20, 2013 at 04:42:49PM +0200, Michael J Gruber wrote:
> > And this mass of almost-the-same functions is gross, too, especially
> > given that the object_context contains a mode itself.
>
> Well, it's just providing different ways to call into the one and only
> function, in order to s
On Sat, Apr 20, 2013 at 03:38:53PM +0200, Michael J Gruber wrote:
> > Wait, this does the opposite of the last patch. If we do want to do
> > this, shouldn't the last one have been an "expect_failure"?
>
> The last patch just documents the status quo, which is not a bug per se.
> Therefore, no fa
On Sat, Apr 20, 2013 at 5:39 PM, Felipe Contreras
wrote:
> On Sat, Apr 20, 2013 at 1:53 PM, Jonathan Nieder wrote:
>> Jonathan Nieder wrote:
>>> Ramkumar Ramachandra wrote:
>>
However, I don't understand why we
maintain it, because there's a comprehensive fir
Re-sent to the mailing list because the original was bounced (HTML subpart):
On 21 April 2013 09:56, Duy Nguyen wrote:
>
> On Sun, Apr 21, 2013 at 6:51 AM, Junio C Hamano wrote:
> > Duy Nguyen writes:
> > But the shallow list is also used to compute the updated boundary
> > (i.e. "this client d
Junio C Hamano wrote:
> But a _real user_ who wants to use a slash there has no way of doing
> so.
Doesn't foo=// do that in the msys world? If I am reading
mingw/msys/rt/src/winsup/cygwin/path.cc correctly then the way to pass
a true double-slash is foo=///.
Jonathan
--
To unsubscribe from thi
On Sun, Apr 21, 2013 at 6:51 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
> But the shallow list is also used to compute the updated boundary
> (i.e. "this client does not have a valid history behind these
> commits")? When we know their current shallow boundary, after
> sending history that c
On Sat, Apr 20, 2013 at 6:07 AM, John Szakmeister wrote:
> I really like the idea of remote-hg, but it appears to be awfully slow
> on the clone step:
The short answer is no. I do have a couple of patches that improve
performance, but not by a huge factor.
I have profiled the code, and there are
On Sat, Apr 20, 2013 at 10:44 PM, Jonathan Nieder wrote:
> Johan Herland wrote:
>
>> The DWIM mode of checkout allows you to run "git checkout foo" when there is
>> no existing local ref or path called "foo" and there is exactly one remote
>> with a remote-tracking branch called "foo".
>
> Thanks
On Sat, Apr 20, 2013 at 1:53 PM, Jonathan Nieder wrote:
> Jonathan Nieder wrote:
>> Ramkumar Ramachandra wrote:
>
>>> However, I don't understand why we
>>> maintain it, because there's a comprehensive first-class completer in
>>> ZSH core [1] which I use all the time.
Ramkumar Ramachandra wrote:
> First, and are ways to specify "revisions", not
> "commits", as gitrevisions.txt would indicate.
What's the difference between a revision and a commit? The definition
in gitglossary(7) only confuses me.
--
To unsubscribe from this list: send the line "unsubscribe
Jeff King wrote:
> On Fri, Apr 19, 2013 at 08:21:48PM +0800, Nazri Ramliy wrote:
>> Often I find myself needing to find out quickly the status of a repository
>> that
>> is not in my currenct working directory, like this:
>>
>> $ (cd ~/foo; git log -1)
>>
>> With this patch now i can sim
So this showed up after running the test suite of current master at
v1.8.2.1-501-gd2949c7:
fixed 0
success 9838
failed 0
broken 83
total 1
Ten thousand tests is worth celebrating. Congratulations! :)
Regards,
Øyvind
--
To unsubscribe from this list: send the line "unsubscribe
Duy Nguyen writes:
> On Sat, Apr 20, 2013 at 8:05 PM, Michael Heemskerk
> wrote:
>> When the client sends a 'shallow' line for an object that the server does
>> not have, the server currently dies with the error: "did not find object
>> for shallow ". The client may have received the object from
Johan Herland wrote:
> The DWIM mode of checkout allows you to run "git checkout foo" when there is
> no existing local ref or path called "foo" and there is exactly one remote
> with a remote-tracking branch called "foo".
Thanks for testing this. I'm surprised no one suggested a test since
v1.7
Johannes Sixt writes:
>> But I think it can be useful outside the context of send-email as
>> well, and having one independent tool that does one single job well
>> is a better design. Perhaps it is better to name it less specific
>> to send-email's cc-cmd option. "git people"? "git whom"? "g
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>> However, I don't understand why we
>> maintain it, because there's a comprehensive first-class completer in
>> ZSH core [1] which I use all the time. Shouldn't the completion folks
>> be contributing to this inste
Hi,
Ramkumar Ramachandra wrote:
> However, I don't understand why we
> maintain it, because there's a comprehensive first-class completer in
> ZSH core [1] which I use all the time. Shouldn't the completion folks
> be contributing to this instead?
Only if they want t
Hi folks,
I apologize for being off the grid for a while. We had a baby and
unexpectedly ended up in the NICU. We just got him home a week ago.
Everyone is doing fine but I had to pretty much drop all non-essential
work for a month or so.
Rest assured that I have all of the git-subtree-related
Ramkumar Ramachandra writes:
> Ever since 'git log -L' made it to `pu`, I've been playing with it to
> see how it can be useful. Here are some of my observations:
>
> 1. Specifying line ranges by hand are too painful. I would really
> love it if it could parse the lines off a patch prepared by
The current code for validating tracking branches (e.g. the argument to
the -t/--track option) hardcodes refs/heads/* and refs/remotes/* as the
potential locations for tracking branches. This works with the refspecs
created by "git clone" or "git remote add", but is suboptimal in other
cases:
- I
The definition of a remote-tracking branch in the glossary have been
out-of-date for a while (by e.g. referring to "Pull:" from old-style
$GIT_DIR/remotes files).
Also, the preceding patches have formalized that a remote-tracking branch
must match a configured refspec in order to be usable as an u
We are formalizing a requirement that any remote-tracking branch to be used
as an upstream (i.e. as an argument to --track), _must_ "belong" to a
configured remote by being matched by the "dst" side of a fetch refspec.
Without this patch, this test would start failing when the new behavior is
intr
We are formalizing a requirement that any remote-tracking branch to be used
as an upstream (i.e. as an argument to --track), _must_ "belong" to a
configured remote by being matched by the "dst" side of a fetch refspec.
This test uses --track against a "remotes/trunk" ref which does not belong
to a
We are formalizing a requirement that any remote-tracking branch to be used
as an upstream (i.e. as an argument to --track), _must_ "belong" to a
configured remote by being matched by the "dst" side of a fetch refspec.
This patch encodes the new expected behavior of this test, and marks the
test w
When using "git checkout foo" to DWIM the creation of local "foo" from some
existing upstream "foo", we assume conventional refspecs as created by "git
clone" or "git remote add", and fail to work correctly if the current
refspecs do not follow the conventional "refs/remotes/$remote/*" pattern.
Si
The DWIM mode of checkout allows you to run "git checkout foo" when there
is no existing local ref or path called "foo", and there is exactly _one_
remote with a remote-tracking branch called "foo". Git will automatically
create a new local branch called "foo" using the remote-tracking "foo" as
its
Hi,
This is second iteration of this series. The initial three patches are
unchanged, although the commit message of #3 has been rephrased based
on Junio's comments.
Patches #4-#6 fixes existing tests in preparation for patch #7, which
changes the validation of the remote-tracking branch passed t
The DWIM mode of checkout allows you to run "git checkout foo" when there is
no existing local ref or path called "foo", and there is exactly one remote
with a remote-tracking branch called "foo". Git will then automatically
create a new local branch called "foo" using the remote-tracking "foo" as
Jeff King venit, vidit, dixit 20.04.2013 06:06:
> On Fri, Apr 19, 2013 at 06:44:45PM +0200, Michael J Gruber wrote:
>
>> Currently, "diff" and "cat-file" for blobs obey "--textconv" options
>> (with the former defaulting to "--textconv" and the latter to
>> "--no-textconv") whereas "show" does not
Junio C Hamano venit, vidit, dixit 19.04.2013 20:24:
> Michael J Gruber writes:
>
>> This series teaches show and grep to obey textconv: show by
>> default (like diff), grep only on request (--textconv). We might
>> switch the default for the latter also, of course. I'd actually
>> like that.
>
Jeff King venit, vidit, dixit 20.04.2013 06:04:
> On Fri, Apr 19, 2013 at 06:44:44PM +0200, Michael J Gruber wrote:
>
>> "git show " obeys the textconc setting while "git show "
>> does not. Demonstrate this in the test.
>
> s/textconc/textconv
Thanks, plus s/obey/honor/
>> diff --git a/t/t4030
Jeff King venit, vidit, dixit 20.04.2013 06:24:
> On Fri, Apr 19, 2013 at 06:44:49PM +0200, Michael J Gruber wrote:
>
>> @@ -820,12 +820,13 @@ int cmd_grep(int argc, const char **argv, const char
>> *prefix)
>> for (i = 0; i < argc; i++) {
>> const char *arg = argv[i];
>>
Jeff King venit, vidit, dixit 20.04.2013 06:17:
> On Fri, Apr 19, 2013 at 06:44:46PM +0200, Michael J Gruber wrote:
>
>> -die("git cat-file --textconv: unable to run textconv on
>> %s",
>> -obj_name);
>> -break;
>> +if (textconv_
On Thu, Apr 11, 2013 at 06:55:03PM +0300, Barbu Paul - Gheorghe wrote:
> Should I create a new patch removing them all?
Sounds like a good idea to me. And update the commit message with
Junio's suggestions.
Regards
Simon
--
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0
On Thu, Apr 11, 2013 at 11:36:26AM +0100, John Tapsell wrote:
> Is there a way to make --cc default?
If you use aliases, something like this is easy:
git config --global --add alias.lp 'log --patch --cc'
I use aliases heavily, so that's my fix for now.
But I think the current behaviour is
dav...@gmail.com wrote on Sat, 20 Apr 2013 03:50 -0700:
> On Thu, Apr 18, 2013 at 5:09 PM, Pete Wyckoff wrote:
> >> First issue
> >> ---
> >>
> >> git-p4 assumes the output of 'p4 print' adds a newline to the
> >> target. To work around this, git-p4.py strips the last char from
> >> symli
In its current form, the note talks about separating options from
"branch names" and "refnames" in the same sentence. This is entirely
inaccurate, as the rev spec need not be a set of branch names or ref
names. Rewrite it to use the word "revisions".
Signed-off-by: Ramkumar Ramachandra
---
Doc
"--" is used to separate pathspecs from the rev specs, and not rev
specs from the options, as the shortlog_usage string currently
indicates. In correcting this usage string, make it consistent with
the log_usage string.
Signed-off-by: Ramkumar Ramachandra
---
builtin/shortlog.c | 4 +---
1 file
There are broadly two problems with the current SYNOPSIS. First, it
completely omits the detail that paths can be specified. Second, it
attempts to list all the options: this is futile as, in addition to
the options unique to it, it accepts all the options that git-rev-list
accepts. In fixing th
First, and are ways to specify "revisions", not
"commits", as gitrevisions.txt would indicate. Second,
'..' is simply indicative of how users would normally
want to specify the rev spec: it need not conform to this form, and
can take any form that gitrevisions.txt lists. A 'git log :/quuxery'
i
To be consistent with the documentation of all the other commands,
remove (-h|--help) from the OPTIONS section.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-shortlog.txt | 4
1 file changed, 4 deletions(-)
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlo
Hi,
I was going through the shortlog documentation and was saddened to see
that it was inaccurate and inconsistent with the log documentation. I
use shortlog quite a lot, and like it very much. So, here's a small
series fixing some problems.
[3/5] and [4/5] came out of my desire to copy out par
I really like the idea of remote-hg, but it appears to be awfully slow
on the clone step:
...
progress revision 81499 'master' (81500/81664)
progress revision 81599 'master' (81600/81664)
Checking out files: 100% (3744/3744), done.
git clone hg::https://bitbucket.org/python_mir
On Thu, Apr 18, 2013 at 5:09 PM, Pete Wyckoff wrote:
>> First issue
>> ---
>>
>> git-p4 assumes the output of 'p4 print' adds a newline to the
>> target. To work around this, git-p4.py strips the last char from
>> symlinks as shown in the following snippet:
>>
>> if type_base == "syml
On Apr 20, 2013, at 9:19 AM, Paul Mackerras wrote:
> On Thu, Apr 11, 2013 at 01:02:48AM +0600, Tair Sabirgaliev wrote:
>> On OSX Tcl/Tk application windows are created behind all
>> the applications down the stack of windows. This is very
>> annoying, because once a gitk window appears, it's the
On Sat, Apr 20, 2013 at 8:05 PM, Michael Heemskerk
wrote:
> When the client sends a 'shallow' line for an object that the server does
> not have, the server currently dies with the error: "did not find object
> for shallow ". The client may have received the object from a
> different server, or th
Hi Eric.
ESR> cvs-fast-export does not have incremental-import support.
ESR> Whether git-cvs-import has it depend on which version you have
ESR> and what backend it it is using. I don't maintain that wrapper.
Did you mean "git-fast-import"? Or do you know any wrapper that
already uses cvsps3 --fas
Hi,
Ever since 'git log -L' made it to `pu`, I've been playing with it to
see how it can be useful. Here are some of my observations:
1. Specifying line ranges by hand are too painful. I would really
love it if it could parse the lines off a patch prepared by
format-patch or something.
2. Spec
Hi,
I realize that we maintain a bash completion script, and a thin
wrapper around it for ZSH. However, I don't understand why we
maintain it, because there's a comprehensive first-class completer in
ZSH core [1] which I use all the time. Shouldn't the completion folks
be contributing to this in
On Fri, Apr 19, 2013 at 9:44 PM, Junio C Hamano wrote:
> I am _guessing_ that you mean a case like this:
>
> [remote "origin"]
> fetch = refs/heads/*:refs/remotes/origin/*
> [remote "xyzzy"]
> fetch = refs/heads/*:refs/remotes/xyzzy/nitfol/*
>
61 matches
Mail list logo
