On Fri, Apr 19, 2013 at 9:44 PM, Junio C Hamano gits...@pobox.com 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/*
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
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.
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
On Sat, Apr 20, 2013 at 8:05 PM, Michael Heemskerk
mheemsk...@atlassian.com 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 obj-id. The client may have received the object from a
On Apr 20, 2013, at 9:19 AM, Paul Mackerras pau...@samba.org 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
On Thu, Apr 18, 2013 at 5:09 PM, Pete Wyckoff p...@padd.com 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 ==
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
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
To be consistent with the documentation of all the other commands,
remove (-h|--help) from the OPTIONS section.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-shortlog.txt | 4
1 file changed, 4 deletions(-)
diff --git a/Documentation/git-shortlog.txt
First, since and until are ways to specify revisions, not
commits, as gitrevisions.txt would indicate. Second,
'since..until' 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
-- 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 artag...@gmail.com
---
builtin/shortlog.c
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
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
dav...@gmail.com wrote on Sat, 20 Apr 2013 03:50 -0700:
On Thu, Apr 18, 2013 at 5:09 PM, Pete Wyckoff p...@padd.com 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
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
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:
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
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 commit obeys the textconc setting while git show blob
does not. Demonstrate this in the test.
s/textconc/textconv
Thanks, plus s/obey/honor/
diff --git
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: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 obey this option,
Junio C Hamano venit, vidit, dixit 19.04.2013 20:24:
Michael J Gruber g...@drmicha.warpmail.net 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
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
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
its
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.
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 starting
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 with
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
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 any
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:
- If
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
Ramkumar Ramachandra artag...@gmail.com 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
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
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 to.
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 instead?
Johannes Sixt j...@kdbg.org 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?
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
Duy Nguyen pclo...@gmail.com writes:
On Sat, Apr 20, 2013 at 8:05 PM, Michael Heemskerk
mheemsk...@atlassian.com 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 obj-id. The
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
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 simply do:
Ramkumar Ramachandra wrote:
First, since and until 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
On Sat, Apr 20, 2013 at 1:53 PM, Jonathan Nieder jrnie...@gmail.com 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
On Sat, Apr 20, 2013 at 10:44 PM, Jonathan Nieder jrnie...@gmail.com 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.
On Sat, Apr 20, 2013 at 6:07 AM, John Szakmeister j...@szakmeister.net 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
On Sun, Apr 21, 2013 at 6:51 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com 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,
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 this
Re-sent to the mailing list because the original was bounced (HTML subpart):
On 21 April 2013 09:56, Duy Nguyen pclo...@gmail.com wrote:
On Sun, Apr 21, 2013 at 6:51 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
But the shallow list is also used to compute
On Sat, Apr 20, 2013 at 5:39 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Sat, Apr 20, 2013 at 1:53 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Jonathan Nieder wrote:
Ramkumar Ramachandra wrote:
However, I don't understand why we
maintain it,
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 failure,
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 satisfy
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 of other
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 do,
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
Acked-by: Eric Wong normalper...@yhbt.net
--
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
54 matches
Mail list logo
