* Installing git-svn on Linux without root
From: Andrew Keller @ 2012-02-04 2:10 UTC (permalink / raw)
To: Git List
I am attempting to install git, including the ability to access subversion repositories on a Linux machine. I do not have root access on the machine, so I prepended my PATH with a folder in my home directory.
Installing Git worked just fine, but when I try to clone a subversion repository, I get:
$ git svn clone file:///svn --prefix=svn/ --no-metadata --trunk=dba/trunk --branches=dba/branches --tags=dba/tags dba
Initialized empty Git repository in /home/kelleran/Documents/togit/converted/dba/.git/
Can't locate SVN/Core.pm in @INC (@INC contains: /homedirs/kelleran/local/lib/perl5/site_perl/5.8.8 /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8 .) at /homedirs/kelleran/local/libexec/git-core/git-svn line 41.
Google suggested that the above error could be due to missing perl bindings. So, I installed swig, and followed the instructions for installing the perl bindings: http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/swig/INSTALL (I used the alternate build steps, since I had to set the prefix).
Unfortunately, I still get exactly the same error. So, I looked to see whether or not the missing library was installed:
$ find ~/local -iname Core.pm
/homedirs/kelleran/local/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/SVN/Core.pm
So, the module does exist, but not in a location included by @INC. This sounds like a simple misconfiguration during the installation on my part, but after reading the manuals and searching the web, I was unable to find a parameter that gets git to be able to see the perl bindings.
I'm guessing I need either more sleep or a fresh point of view. Any thoughts?
The machine is running Linux 2.6.32 64-bit, and has perl 5.8.8. Of the software I installed, I am using:
libpcre 8.21
swig 2.8.4
neon 0.29.6
apr 1.3.x
apr-util 1.3.x
subversion 1.7.2
git 1.7.9
Thanks,
Andrew Keller
^ permalink raw reply
* Re: [RFC/PATCH] verify-tag: check sig of all tags to given object
From: Junio C Hamano @ 2012-02-04 3:16 UTC (permalink / raw)
To: Tom Grennan; +Cc: git, jasampler
In-Reply-To: <1328318751-4470-1-git-send-email-tom.grennan@ericsson.com>
Tom Grennan <tom.grennan@ericsson.com> writes:
> If the command argument is a non-tag object, scan and verify all tags to
> the given object; for example:
>
> john$ git tag -s -m "I approve" john-README master:README
> ...
> john$ git tag -s -m "I recommend" john-HEAD HEAD
> ...
> john$ git push <url> tag john-README
> john$ git push <url> tag john-HEAD
>
> jane$ git fetch --tags <url>
> jane$ git tag -s -m "I also approve" jane-README master:README
> ...
> jane$ git push <url> tag jane-README
>
> jeff$ git fetch --tags <url>
> jeff$ git verify-tag master:README
> tag john-README: OK
> tag jane-README: OK
> jeff$ git verify-tag HEAD
> tag john-HEAD: OK
>
> Signed-off-by: Tom Grennan <tom.grennan@ericsson.com>
You did not describe what problem you are trying to solve, but the above
tells me that the design of this feature has a lot of room to be improved
to be useful for even a single trivial use scenario I can think of off the
top of my head.
Let's say after tagging v1.7.10, for some reason (as I do not know what
problem you are trying to solve), I decided to ask my back-up maintainers,
let's call them Shawn and Jeff, to sign that tag. Shawn is expected to do
this:
spearce$ git fetch tag v1.7.10
spearce$ git tag -s -m "This tag is Gitster's" v1.7.10-spearce v1.7.10
spearce$ git push http://example.com/spearce/git tags/v1.7.10-spearce
Jeff will do the same, and I'll fetch v1.7.10-spearce and v1.7.10-peff
tags from them.
It is natural for me to be able to ask "I want to verify all tags that
point at the object I asked to be signed, namely, v1.7.10" from this
feature.
But
gitster$ git verify-tag v1.7.10
would not be a way to do so, as that would check my signature in v1.7.10
tag itself.
It gets even worse. Suppose Jeff does this instead by mistake:
peff$ git fetch v1.7.10
peff$ git tag v1.7.10-peff v1.7.10
peff$ git push http://example.com/peff/git tags/v1.7.10-peff
Even if you added "git verify-tag --pointed v1.7.10" to disambiguate the
request to use the new feature, the result is unusable, as I would see:
gitster$ git verify-tag --pointed v1.7.10
v1.7.10-spearce: OK
v1.7.10-peff: OK
v1.7.10-spearce and v1.7.10-peff both resolve to my v1.7.10, and they both
are signed by known key, but v1.7.10-peff is a lightweight tag that points
directly at my v1.7.10 and I would be seeing a signature of my own as "OK".
^ permalink raw reply
* Re: [PATCH v4 03/13] parseopt: make OPT_INTEGER support hexadecimal as well
From: Nguyen Thai Ngoc Duy @ 2012-02-04 4:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaa4zmsku.fsf@alter.siamese.dyndns.org>
2012/2/4 Junio C Hamano <gitster@pobox.com>:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> - *(int *)opt->value = strtol(arg, (char **)&s, 10);
>> + if (!prefixcmp(arg, "0x") || !prefixcmp(arg, "0X"))
>> + *(int *)opt->value = strtol(arg + 2, (char **)&s, 16);
>> + else
>> + *(int *)opt->value = strtol(arg, (char **)&s, 10);
>
> Can't you just do "strtol(arg, (char **)&s, 0)" instead?
I could but that means "01234" is now in base 8 and that's currently
accepted as base 10. 0x1234 does not have this problem because current
git rejects it.
--
Duy
^ permalink raw reply
* Re: [PATCH v4 10/13] branch: add --column
From: Nguyen Thai Ngoc Duy @ 2012-02-04 5:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwr83ldfz.fsf@alter.siamese.dyndns.org>
2012/2/4 Junio C Hamano <gitster@pobox.com>:
> I am not sure about the utility of columnar output for "git branch" in the
> short form. You no longer can just scan the leftmost column to scan for
> '*' to see the current branch.
I rely on color for that. Without color you may need to scan more
columns for '*'. Though I would really like to see "git branch
--current" added to show just current branch if I'm on colorless
terminal.
--
Duy
^ permalink raw reply
* Re: Git performance results on a large repository
From: Joey Hess @ 2012-02-04 5:07 UTC (permalink / raw)
To: Joshua Redstone; +Cc: git@vger.kernel.org
In-Reply-To: <CB5074CF.3AD7A%joshua.redstone@fb.com>
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
Joshua Redstone wrote:
> The test repo has 4 million commits, linear history and about 1.3 million
> files.
Have you tried separating these two factors, to see how badly each is
affecting performance?
If the number of commits is the problem (seems likely for git blame at
least), a shallow clone would avoid that overhead.
I think that git often writes .git/index inneficiently when staging
files (though your `git add` is pretty fast) and committing. It rewrites
the whole file to .git/index.lck and the renames it over .git/index at
the end. I have code that keeps a journal of changes to avoid rewriting
the index repeatedly, but it's application specific. Fixing git to write
the index more intelligently is something I'd like to see.
Hint for git status: `git status .` in a smaller subdirectory will be much
faster than the default that stats everything.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] verify-tag: check sig of all tags to given object
From: Tom Grennan @ 2012-02-04 5:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jasampler, tomg.grennan
In-Reply-To: <D140688E-B86C-4A67-9AD6-56160C26884D@ericsson.com>
Junio C Hamano <gitster@pobox.com<mailto:gitster@pobox.com>> writes:
>Tom Grennan <tom.grennan@ericsson.com<mailto:tom.grennan@ericsson.com>> writes:
>>
>>If the command argument is a non-tag object, scan and verify all tags to
>>the given object; for example:
>>
>>john$ git tag -s -m "I approve" john-README master:README
>>...
>>john$ git tag -s -m "I recommend" john-HEAD HEAD
>>...
>>john$ git push <url> tag john-README
>>john$ git push <url> tag john-HEAD
>>
>>jane$ git fetch --tags <url>
>>jane$ git tag -s -m "I also approve" jane-README master:README
>>...
>>jane$ git push <url> tag jane-README
>>
>>jeff$ git fetch --tags <url>
>>jeff$ git verify-tag master:README
>>tag john-README: OK
>>tag jane-README: OK
>>jeff$ git verify-tag HEAD
>>tag john-HEAD: OK
>>
>>Signed-off-by: Tom Grennan <tom.grennan@ericsson.com<mailto:tom.grennan@ericsson.com>>
>
>You did not describe what problem you are trying to solve, but the above
>tells me that the design of this feature has a lot of room to be improved
>to be useful for even a single trivial use scenario I can think of off the
>top of my head.
>
>Let's say after tagging v1.7.10, for some reason (as I do not know what
>problem you are trying to solve), I decided to ask my back-up maintainers,
>let's call them Shawn and Jeff, to sign that tag. Shawn is expected to do
>this:
>
> spearce$ git fetch tag v1.7.10
> spearce$ git tag -s -m "This tag is Gitster's" v1.7.10-spearce v1.7.10
> spearce$ git push http://example.com/spearce/git tags/v1.7.10-spearce
>
>Jeff will do the same, and I'll fetch v1.7.10-spearce and v1.7.10-peff
>tags from them.
>
>It is natural for me to be able to ask "I want to verify all tags that
>point at the object I asked to be signed, namely, v1.7.10" from this
>feature.
>
>But
>
> gitster$ git verify-tag v1.7.10
>
>would not be a way to do so, as that would check my signature in v1.7.10
>tag itself.
>
>It gets even worse. Suppose Jeff does this instead by mistake:
>
> peff$ git fetch v1.7.10
> peff$ git tag v1.7.10-peff v1.7.10
> peff$ git push http://example.com/peff/git tags/v1.7.10-peff
>
>Even if you added "git verify-tag --pointed v1.7.10" to disambiguate the
>request to use the new feature, the result is unusable, as I would see:
>
> gitster$ git verify-tag --pointed v1.7.10
> v1.7.10-spearce: OK
> v1.7.10-peff: OK
>
>v1.7.10-spearce and v1.7.10-peff both resolve to my v1.7.10, and they both
>are signed by known key, but v1.7.10-peff is a lightweight tag that points
>directly at my v1.7.10 and I would be seeing a signature of my own as "OK".
Sorry for messing up this thread. I had remote access trouble with work.
Wouldn't you want Shawn and Jeff to tag the object (commit, tree, or
blob) that you had tagged?
spearce$ git fetch tag v1.7.10
spearce$ eval $(git verify-tag -v v1.7.10 | sed -n '1s/ /=/p')
spearce$ git tag -s -m "This tag is Gitster's" v1.7.10-spearce $object
spearce$ git push http://example.com/spearce/git tags/v1.7.10-spearce
Or,
spearce$ git fetch tag v1.7.10
spearce$ git tag -s -m "This tag is Gitster's" v1.7.10-spearce --pointed v1.7.10
spearce$ git push http://example.com/spearce/git tags/v1.7.10-spearce
Then,
gitster$ git verify-tag $object
tag v1.7.10: OK
tag v1.7.10-spearce: OK
Or,
gitster$ git verify-tag --pointed v1.7.10
tag v1.7.10: OK
tag v1.7.10-spearce: OK
I hadn't thought of tagging a tag. As you indicate, this would be
tricky to disambiguate.
So, I intended this to verify all tags of the non-tag object that one
asked to be signed; no sign, no record.
BTW, it may also be convenient to use auto-generated tag names for the
secondary sign-offs, perhaps using the tag SHA as it's refs/tags/SHA.
spearce$ git tag -s -m "This is Gitster's v1.7.10" -- --pointed v1.7.10
peff$ git tag -s -m "This is Gitster's v1.7.10" -- --pointed v1.7.10
gitster$ git verify-tag --pointed v1.7.10
tag v1.7.10: OK
tag XXX....XXX: OK
tag YYY....YYY: OK
`git tag -l` could then ignore refs/tags/SHA with content SHA.
--
TomG
^ permalink raw reply
* Re: [RFC/PATCH] verify-tag: check sig of all tags to given object
From: Junio C Hamano @ 2012-02-04 5:16 UTC (permalink / raw)
To: Tom Grennan; +Cc: git, jasampler
In-Reply-To: <7v8vkjl24d.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> You did not describe what problem you are trying to solve, but the above
> tells me that the design of this feature has a lot of room to be improved
> to be useful for even a single trivial use scenario I can think of off the
> top of my head.
Having said all that, the biggest problem I have with the approach of this
patch is that it does not decompose the necessary functionalities in a way
that allows combinations of options people naturally would expect from the
description of the feature.
"git tag" can be used to create (-a), delete (-d), show (-l) and verify
(-v). Among these modes, creation has to work on a single tag, so it is a
bit special. But the other three modes could also use the filtering
feature of what "show" supports among themselves.
The mode to show tags (-l) starts from _all_ tags, but limits the output
to those that match given patterns, and the output can further be limited
to the ones that contain a given commit. The verify mode and the delete
mode do not offer this behaviour and require the user to specify exact tag
names. If you are adding "I want to do X on all tags that point at this
object" feature, in which X happens to be "verification" in your case,
don't you think other people would naturally want to use the feature with
X=show instead?
The right first step to do this would be to enhance the "filter" logic so
that it not just lets "--contains", but also "--points-at", be specified.
Once that is done, you could just say:
$ git tag -l --points-at master:README
to list all the tags that point at the blob, and then your original
example becomes:
$ git tag --points-at master:README | xargs git tag -v
It even allows something like this:
$ git tag --points-at master:README 'v1.[0-4].?' |
xargs git tag -v
to work on tags that point at the blob but only those whose names match
the given pattern, i.e. versions from v1.0 series up to v1.4 series but
not later.
After that is done, you could teach the --verify mode to also accept the
patterns, not exact names, so that the above could become:
$ git tag --verify --points-at master:README
$ git tag --verify --points-at master:README 'v1.[0-4].?'
Theoretically, the "start from all and then filter" feature could be
shared also with "delete" mode, but I would not recommend doing so for
safety reasons (i.e. "delete" is destructive). Even so, if somebody does
want to do a bulk delete, it is just a simple matter of:
$ git tag --points-at master:README 'v1.[0-4].?' |
xargs git tag -d
So it is not a big deal if you did not to teach --delete to share the
filtering logic with "show".
For exactly the same reason, --verify mode does not have to share the
logic, either. Not having to use "| xargs" is merely an icing on the cake.
Hmm?
^ permalink raw reply
* Re: [RFC/PATCH] verify-tag: check sig of all tags to given object
From: Junio C Hamano @ 2012-02-04 5:22 UTC (permalink / raw)
To: Tom Grennan; +Cc: git, jasampler, tomg.grennan
In-Reply-To: <20120204050818.GA2477@tgrennan-laptop>
Tom Grennan <tmgrennan@gmail.com> writes:
> Wouldn't you want Shawn and Jeff to tag the object (commit, tree, or
> blob) that you had tagged?
No.
We _designed_ our tag objects so that they are capable of pointing at
another tag, not the object that is pointed at that other tag. And that
is the example usage I gave you.
The statement by Shawn and Jeff, "This tag is Gitster's" is exactly that.
It was not about asserting the authenticity of the commit. It was about
the tag object I created.
> gitster$ git verify-tag --pointed v1.7.10
> tag v1.7.10: OK
Just saying "$name: OK" will *never* be acceptable. "A signature made by
any key in my keychain is fine" is not the usual use case. At least the
output needs to be "Good signature from X".
^ permalink raw reply
* Re: [PATCH v4 03/13] parseopt: make OPT_INTEGER support hexadecimal as well
From: Junio C Hamano @ 2012-02-04 5:32 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8Ba2qxyT4XqeRmUv63Z3rT1-FmBkZ3tB6YMh6qrXjLP1Q@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 2012/2/4 Junio C Hamano <gitster@pobox.com>:
>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>>
>>> - *(int *)opt->value = strtol(arg, (char **)&s, 10);
>>> + if (!prefixcmp(arg, "0x") || !prefixcmp(arg, "0X"))
>>> + *(int *)opt->value = strtol(arg + 2, (char **)&s, 16);
>>> + else
>>> + *(int *)opt->value = strtol(arg, (char **)&s, 10);
>>
>> Can't you just do "strtol(arg, (char **)&s, 0)" instead?
>
> I could but that means "01234" is now in base 8 and that's currently
> accepted as base 10.
Yes, but I wonder if that is a problem in practice. Who in the right mind
would give 00001000 to tell git that they want one thousand?
^ permalink raw reply
* Re: [RFC/PATCH] verify-tag: check sig of all tags to given object
From: Tom Grennan @ 2012-02-04 5:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jasampler, tom.grennan
In-Reply-To: <7vsjirjhp7.fsf@alter.siamese.dyndns.org>
On Fri, Feb 03, 2012 at 09:22:44PM -0800, Junio C Hamano wrote:
>Tom Grennan <tmgrennan@gmail.com> writes:
>
>> Wouldn't you want Shawn and Jeff to tag the object (commit, tree, or
>> blob) that you had tagged?
>
>No.
>
>We _designed_ our tag objects so that they are capable of pointing at
>another tag, not the object that is pointed at that other tag. And that
>is the example usage I gave you.
>
>The statement by Shawn and Jeff, "This tag is Gitster's" is exactly that.
>It was not about asserting the authenticity of the commit. It was about
>the tag object I created.
Hmm, how about "git verify-tag [[-v] [--to]] <tag|object>"?
With "--to", all tags to the given tag (or object) are verified.
Without "--to" just the given <tag> is verified.
>> gitster$ git verify-tag --pointed v1.7.10
>> tag v1.7.10: OK
>
>Just saying "$name: OK" will *never* be acceptable. "A signature made by
>any key in my keychain is fine" is not the usual use case. At least the
>output needs to be "Good signature from X".
OK, I'll have to play with the gpg --verify-options.
--
TomG
^ permalink raw reply
* Re: [PATCH v4 03/13] parseopt: make OPT_INTEGER support hexadecimal as well
From: Nguyen Thai Ngoc Duy @ 2012-02-04 6:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobtfjh9d.fsf@alter.siamese.dyndns.org>
On Sat, Feb 4, 2012 at 12:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> 2012/2/4 Junio C Hamano <gitster@pobox.com>:
>>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>>>
>>>> - *(int *)opt->value = strtol(arg, (char **)&s, 10);
>>>> + if (!prefixcmp(arg, "0x") || !prefixcmp(arg, "0X"))
>>>> + *(int *)opt->value = strtol(arg + 2, (char **)&s, 16);
>>>> + else
>>>> + *(int *)opt->value = strtol(arg, (char **)&s, 10);
>>>
>>> Can't you just do "strtol(arg, (char **)&s, 0)" instead?
>>
>> I could but that means "01234" is now in base 8 and that's currently
>> accepted as base 10.
>
> Yes, but I wonder if that is a problem in practice. Who in the right mind
> would give 00001000 to tell git that they want one thousand?
That could come from a script, extracting info from a source (maybe a
log file) and not stripping leading zeros. If we go this route, I
think we should have one release that rejects such numbers first. If
nobody complains, then we proceed and allow octal in the next release.
--
Duy
^ permalink raw reply
* Re: [RFC/PATCH] verify-tag: check sig of all tags to given object
From: Junio C Hamano @ 2012-02-04 6:20 UTC (permalink / raw)
To: Tom Grennan; +Cc: git, jasampler, tom.grennan
In-Reply-To: <20120204055656.GC2477@tgrennan-laptop>
Tom Grennan <tmgrennan@gmail.com> writes:
> On Fri, Feb 03, 2012 at 09:22:44PM -0800, Junio C Hamano wrote:
>>Tom Grennan <tmgrennan@gmail.com> writes:
>>
>>> Wouldn't you want Shawn and Jeff to tag the object (commit, tree, or
>>> blob) that you had tagged?
>>
>>No.
>>
>>We _designed_ our tag objects so that they are capable of pointing at
>>another tag, not the object that is pointed at that other tag. And that
>>is the example usage I gave you.
>>
>>The statement by Shawn and Jeff, "This tag is Gitster's" is exactly that.
>>It was not about asserting the authenticity of the commit. It was about
>>the tag object I created.
>
> Hmm, how about "git verify-tag [[-v] [--to]] <tag|object>"?
> With "--to", all tags to the given tag (or object) are verified.
> Without "--to" just the given <tag> is verified.
>
>>> gitster$ git verify-tag --pointed v1.7.10
>>> tag v1.7.10: OK
>>
>>Just saying "$name: OK" will *never* be acceptable. "A signature made by
>>any key in my keychain is fine" is not the usual use case. At least the
>>output needs to be "Good signature from X".
>
> OK, I'll have to play with the gpg --verify-options.
If it wasn't clear enough from my other message, I would rather not to see
any change to --verify codepath as the first step. Don't you think that
the simplest and cleanest first step is to add --points-at to the list
mode, so that with help from "| xargs git tag -v" you can bulk-verify
without any other change?
^ permalink raw reply
* Re: [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Jeff King @ 2012-02-04 6:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, git
In-Reply-To: <7vipjnmt8a.fsf@alter.siamese.dyndns.org>
On Fri, Feb 03, 2012 at 02:45:25PM -0800, Junio C Hamano wrote:
> > Nice. I was going to suggest a wrapper like "write_sh_script" so you
> > didn't have to spell out $SHELL_PATH, but I think the auto-detection
> > makes sense (and falling back to shell makes even more sense, as that
> > covers 99% of the cases anyway).
>
> Let's not over-engineer this and stick to the simple-stupid-sufficient.
>
> Something like this?
Here it is as patches with commit messages. I don't think it's worth
doing a mechanical conversion of the whole test suite to write_script.
[1/2]: tests: add write_script helper function
[2/2]: t0300: use write_script helper
-Peff
^ permalink raw reply
* [PATCH 1/2] tests: add write_script helper function
From: Jeff King @ 2012-02-04 6:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, git
In-Reply-To: <20120204062712.GA20076@sigill.intra.peff.net>
From: Junio C Hamano <gitster@pobox.com>
Many of the scripts in the test suite write small helper
shell scripts to disk. It's best if these shell scripts
start with "#!$SHELL_PATH" rather than "#!/bin/sh", because
/bin/sh on some platforms is too buggy to be used.
However, it can be cumbersome to expand $SHELL_PATH, because
the usual recipe for writing a script is:
cat >foo.sh <<-\EOF
#!/bin/sh
echo my arguments are "$@"
EOF
To expand $SHELL_PATH, you have to either interpolate the
here-doc (which would require quoting "\$@"), or split the
creation into two commands (interpolating the $SHELL_PATH
line, but not the rest of the script). Let's provide a
helper function that makes that less syntactically painful.
While we're at it, this helper can also take care of the
"chmod +x" that typically comes after the creation of such a
script, saving the caller a line.
Signed-off-by: Jeff King <peff@peff.net>
---
I suspect you already have this in your repo, but maybe the commit
message is useful.
t/test-lib.sh | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index b22bee7..254849e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -400,6 +400,14 @@ test_config_global () {
git config --global "$@"
}
+write_script () {
+ {
+ echo "#!${2-"$SHELL_PATH"}" &&
+ cat
+ } >"$1" &&
+ chmod +x "$1"
+}
+
# Use test_set_prereq to tell that a particular prerequisite is available.
# The prerequisite can later be checked for in two ways:
#
--
1.7.9.rc1.28.gf4be5
^ permalink raw reply related
* [PATCH 2/2] t0300: use write_script helper
From: Jeff King @ 2012-02-04 6:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, git
In-Reply-To: <20120204062712.GA20076@sigill.intra.peff.net>
t0300 creates some helper shell scripts, and marks them with
"!/bin/sh". Even though the scripts are fairly simple, they
can fail on broken shells (specifically, Solaris /bin/sh
will persist a temporary assignment to IFS in a "read"
command).
Rather than work around the problem for Solaris /bin/sh,
using write_script will make sure we point to a known-good
shell that the user has given us.
Signed-off-by: Jeff King <peff@peff.net>
---
This works fine on my Linux box, but just to sanity check that I didn't
screw anything up in the whopping 5 lines of changes, can you confirm
this fixes the issue for you, Ben?
t/t0300-credentials.sh | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/t/t0300-credentials.sh b/t/t0300-credentials.sh
index 885af8f..0b46248 100755
--- a/t/t0300-credentials.sh
+++ b/t/t0300-credentials.sh
@@ -14,14 +14,13 @@ test_expect_success 'setup helper scripts' '
done
EOF
- cat >git-credential-useless <<-\EOF &&
+ write_script git-credential-useless <<-\EOF &&
#!/bin/sh
. ./dump
exit 0
EOF
- chmod +x git-credential-useless &&
- cat >git-credential-verbatim <<-\EOF &&
+ write_script git-credential-verbatim <<-\EOF &&
#!/bin/sh
user=$1; shift
pass=$1; shift
@@ -29,7 +28,6 @@ test_expect_success 'setup helper scripts' '
test -z "$user" || echo username=$user
test -z "$pass" || echo password=$pass
EOF
- chmod +x git-credential-verbatim &&
PATH="$PWD:$PATH"
'
--
1.7.9.rc1.28.gf4be5
^ permalink raw reply related
* Re: [RFC/PATCH] verify-tag: check sig of all tags to given object
From: Tom Grennan @ 2012-02-04 6:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jasampler
In-Reply-To: <7vhaz7jf1d.fsf@alter.siamese.dyndns.org>
On Fri, Feb 03, 2012 at 10:20:14PM -0800, Junio C Hamano wrote:
>Tom Grennan <tmgrennan@gmail.com> writes:
>
>> On Fri, Feb 03, 2012 at 09:22:44PM -0800, Junio C Hamano wrote:
>>>Tom Grennan <tmgrennan@gmail.com> writes:
>>>
>>>> Wouldn't you want Shawn and Jeff to tag the object (commit, tree, or
>>>> blob) that you had tagged?
>>>
>>>No.
>>>
>>>We _designed_ our tag objects so that they are capable of pointing at
>>>another tag, not the object that is pointed at that other tag. And that
>>>is the example usage I gave you.
>>>
>>>The statement by Shawn and Jeff, "This tag is Gitster's" is exactly that.
>>>It was not about asserting the authenticity of the commit. It was about
>>>the tag object I created.
>>
>> Hmm, how about "git verify-tag [[-v] [--to]] <tag|object>"?
>> With "--to", all tags to the given tag (or object) are verified.
>> Without "--to" just the given <tag> is verified.
>>
>>>> gitster$ git verify-tag --pointed v1.7.10
>>>> tag v1.7.10: OK
>>>
>>>Just saying "$name: OK" will *never* be acceptable. "A signature made by
>>>any key in my keychain is fine" is not the usual use case. At least the
>>>output needs to be "Good signature from X".
>>
>> OK, I'll have to play with the gpg --verify-options.
>
>If it wasn't clear enough from my other message, I would rather not to see
>any change to --verify codepath as the first step. Don't you think that
>the simplest and cleanest first step is to add --points-at to the list
>mode, so that with help from "| xargs git tag -v" you can bulk-verify
>without any other change?
No, I missed that. So you're suggesting,
git tag [-n[<num>]] -l [--contains <commit>] [--points-at <object>] [<pattern>...]
If so, I'll look into it tomorrow.
thanks,
TomG
^ permalink raw reply
* Re: Git performance results on a large repository
From: Nguyen Thai Ngoc Duy @ 2012-02-04 6:53 UTC (permalink / raw)
To: Joshua Redstone; +Cc: git@vger.kernel.org
In-Reply-To: <CB5074CF.3AD7A%joshua.redstone@fb.com>
On Fri, Feb 3, 2012 at 9:20 PM, Joshua Redstone <joshua.redstone@fb.com> wrote:
> I timed a few common operations with both a warm OS file cache and a cold
> cache. i.e., I did a 'echo 3 | tee /proc/sys/vm/drop_caches' and then did
> the operation in question a few times (first timing is the cold timing,
> the next few are the warm timings). The following results are on a server
> with average hard drive (I.e., not flash) and > 10GB of ram.
>
> 'git status' : 39 minutes cold, and 24 seconds warm.
>
> 'git blame': 44 minutes cold, 11 minutes warm.
>
> 'git add' (appending a few chars to the end of a file and adding it): 7
> seconds cold and 5 seconds warm.
>
> 'git commit -m "foo bar3" --no-verify --untracked-files=no --quiet
> --no-status': 41 minutes cold, 20 seconds warm. I also hacked a version
> of git to remove the three or four places where 'git commit' stats every
> file in the repo, and this dropped the times to 30 minutes cold and 8
> seconds warm.
Have you tried "git update-index --assume-unchaged"? That should
reduce mass lstat() and hopefully improve the above numbers. The
interface is not exactly easy-to-use, but if it has significant gain,
then we can try to improve UI.
On the index size issue, ideally we should make minimum writes to
index instead of rewriting 191 MB index. An improvement we could do
now is to compress it, reduce disk footprint, thus disk I/O. If you
compress the index with gzip, how big is it?
--
Duy
^ permalink raw reply
* Re: [PATCH 2/2] t0300: use write_script helper
From: Junio C Hamano @ 2012-02-04 6:58 UTC (permalink / raw)
To: Jeff King; +Cc: Ben Walton, git
In-Reply-To: <20120204063018.GB21559@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> t0300 creates some helper shell scripts, and marks them with
> "!/bin/sh". Even though the scripts are fairly simple, they
> can fail on broken shells (specifically, Solaris /bin/sh
> will persist a temporary assignment to IFS in a "read"
> command).
>
> Rather than work around the problem for Solaris /bin/sh,
> using write_script will make sure we point to a known-good
> shell that the user has given us.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This works fine on my Linux box, but just to sanity check that I didn't
> screw anything up in the whopping 5 lines of changes, can you confirm
> this fixes the issue for you, Ben?
>
> t/t0300-credentials.sh | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/t/t0300-credentials.sh b/t/t0300-credentials.sh
> index 885af8f..0b46248 100755
> --- a/t/t0300-credentials.sh
> +++ b/t/t0300-credentials.sh
> @@ -14,14 +14,13 @@ test_expect_success 'setup helper scripts' '
> done
> EOF
>
> - cat >git-credential-useless <<-\EOF &&
> + write_script git-credential-useless <<-\EOF &&
> #!/bin/sh
An innocuous facepalm I'd be glad to remove myself ;-)
> . ./dump
> exit 0
> EOF
> - chmod +x git-credential-useless &&
>
> - cat >git-credential-verbatim <<-\EOF &&
> + write_script git-credential-verbatim <<-\EOF &&
> #!/bin/sh
But other than that, looks good.
> user=$1; shift
> pass=$1; shift
> @@ -29,7 +28,6 @@ test_expect_success 'setup helper scripts' '
> test -z "$user" || echo username=$user
> test -z "$pass" || echo password=$pass
> EOF
> - chmod +x git-credential-verbatim &&
>
> PATH="$PWD:$PATH"
> '
^ permalink raw reply
* Re: [PATCH 2/2] t0300: use write_script helper
From: Jeff King @ 2012-02-04 7:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, git
In-Reply-To: <7vd39vjda9.fsf@alter.siamese.dyndns.org>
On Fri, Feb 03, 2012 at 10:58:06PM -0800, Junio C Hamano wrote:
> > diff --git a/t/t0300-credentials.sh b/t/t0300-credentials.sh
> > index 885af8f..0b46248 100755
> > --- a/t/t0300-credentials.sh
> > +++ b/t/t0300-credentials.sh
> > @@ -14,14 +14,13 @@ test_expect_success 'setup helper scripts' '
> > done
> > EOF
> >
> > - cat >git-credential-useless <<-\EOF &&
> > + write_script git-credential-useless <<-\EOF &&
> > #!/bin/sh
>
> An innocuous facepalm I'd be glad to remove myself ;-)
Heh, it took me a second to notice it, even after you mentioned it. And
it's even right there in the context. At least the line written by
write_script takes precedence. :)
Thanks.
-Peff
^ permalink raw reply
* Re: Push from an SSH Terminal
From: Junio C Hamano @ 2012-02-04 7:47 UTC (permalink / raw)
To: Jeff King; +Cc: Sven Strickroth, Neal Groothuis, Feanil Patel, git
In-Reply-To: <20120203213654.GD1890@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Feb 03, 2012 at 12:10:27PM -0500, Neal Groothuis wrote:
> ...
>> Check to see if the GIT_ASKPASS and/or SSH_ASKPASS environment variables
>> are set, and if the core.askpass config variable is set. If any of these
>> are set, unset them. Git should fall back to a simple password prompt.
>
> Hmm, yeah that is likely the problem. I was thinking git would fall back
> to asking on the terminal, but it does not. We probably should.
How well would it mesh with the goal of the ss/git-svn-prompt-sans-terminal
topic, which is now stalled [*1*]? I do not mean this change and the other
topic textually conflict with each other---but the philosophies of this
topic and the other one seem to conflict. Not falling back to the terminal
that is not available and failing the command outright might make more
sense.
I dunno.
[Footnote]
*1* Will the topic see any action soon? I am inclined to throw the topic
into "not even the original author is not interested" category otherwise.
^ permalink raw reply
* What's cooking in git.git (Feb 2012, #01; Fri, 3)
From: Junio C Hamano @ 2012-02-04 7:51 UTC (permalink / raw)
To: git
What's cooking in git.git (Feb 2012, #01; Fri, 3)
--------------------------------------------------
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in
'next'.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* nd/diffstat-gramnum (2012-02-03) 1 commit
- Use correct grammar in diffstat summary line
The commands in the "git diff" family and "git apply --stat" that count
the number of files changed and the number of lines inserted/deleted have
been updated to match the output from "diffstat". This also opens the
door to i18n this line.
Will merge to 'next'.
* jx/i18n-more-marking (2012-02-01) 2 commits
- i18n: format_tracking_info "Your branch is behind" message
- i18n: git-commit whence_s "merge/cherry-pick" message
Will merge to 'next'.
* jk/grep-binary-attribute (2012-02-02) 9 commits
- grep: pre-load userdiff drivers when threaded
- grep: load file data after checking binary-ness
- grep: respect diff attributes for binary-ness
- grep: cache userdiff_driver in grep_source
- grep: drop grep_buffer's "name" parameter
- convert git-grep to use grep_source interface
- grep: refactor the concept of "grep source" into an object
- grep: move sha1-reading mutex into low-level code
- grep: make locking flag global
Fixes a longstanding bug that there was no way to tell "git grep" that a
path may look like text but it is not, which "git diff" can do using the
attributes system. Now "git grep" honors the same "binary" (or "-diff")
attribute.
Will merge to 'next'.
* jc/parse-date-raw (2012-02-03) 2 commits
- parse_date(): '@' prefix forces git-timestamp
- parse_date(): allow ancient git-timestamp
"rebase" and "commit --amend" failed to work on commits with ancient
timestamps near year 1970.
Waiting for comments.
* jk/git-dir-lookup (2012-02-02) 1 commit
- standardize and improve lookup rules for external local repos
Will merge to 'next'.
* jk/prompt-fallback-to-tty (2012-02-03) 2 commits
- prompt: fall back to terminal if askpass fails
- prompt: clean up strbuf usage
The code to ask for password did not fall back to the terminal input when
GIT_ASKPASS is set but does not work (e.g. lack of X with GUI askpass
helper).
* jk/tests-write-script (2012-02-03) 2 commits
- t0300: use write_script helper
- tests: add write_script helper function
Will merge to 'next'.
* jn/gitweb-search-utf-8 (2012-02-03) 1 commit
- gitweb: Allow UTF-8 encoded CGI query parameters and path_info
Search box in "gitweb" did not accept non-ASCII characters correctly.
Will merge to 'next'.
* jn/rpm-spec (2012-02-03) 1 commit
- git.spec: Workaround localized messages not put in any RPM
Fix breakage in v1.7.9 Makefile; rpmbuild notices an unpackaged but
installed *.mo file and fails.
Will merge to 'next'.
--------------------------------------------------
[Graduated to "master"]
* jc/pull-signed-tag (2012-01-23) 1 commit
(merged to 'next' on 2012-01-23 at 4257553)
+ merge: use editor by default in interactive sessions
"git merge" in an interactive session learned to spawn the editor by
default to let the user edit the auto-generated merge message, to
encourage people to explain their merges better. Legacy scripts can
export MERGE_AUTOEDIT=no to retain the historical behaviour.
* tr/merge-edit-guidance (2012-01-31) 1 commit
(merged to 'next' on 2012-01-31 at bb678f7)
+ merge: add instructions to the commit message when editing
"git merge" adds advice text to the commit log template when running
interactively.
--------------------------------------------------
[Stalled]
* jc/advise-push-default (2011-12-18) 1 commit
- push: hint to use push.default=upstream when appropriate
Peff had a good suggestion outlining an updated code structure so that
somebody new can try to dip his or her toes in the development. Any
takers?
Waiting for a reroll.
* ss/git-svn-prompt-sans-terminal (2012-01-04) 3 commits
- fixup! 15eaaf4
- git-svn, perl/Git.pm: extend Git::prompt helper for querying users
- perl/Git.pm: "prompt" helper to honor GIT_ASKPASS and SSH_ASKPASS
The bottom one has been replaced with a rewrite based on comments from
Ævar. The second one needs more work, both in perl/Git.pm and prompt.c, to
give precedence to tty over SSH_ASKPASS when terminal is available.
* nd/commit-ignore-i-t-a (2012-01-16) 2 commits
- commit, write-tree: allow to ignore CE_INTENT_TO_ADD while writing trees
- cache-tree: update API to take abitrary flags
May want to consider this as fixing an earlier UI mistake, and not as a
feature that devides the userbase.
--------------------------------------------------
[Cooking]
* fc/zsh-completion (2012-02-03) 3 commits
- completion: simplify __gitcomp and __gitcomp_nl implementations
- completion: use ls -1 instead of rolling a loop to do that ourselves
- completion: work around zsh option propagation bug
Fix git subcommand completion for zsh (in contrib/completion).
Will merge to 'next'.
* jc/maint-request-pull-for-tag (2012-01-31) 1 commit
(merged to 'next' on 2012-02-01 at 7649f18)
+ request-pull: explicitly ask tags/$name to be pulled
When asking for a tag to be pulled, "request-pull" shows the name of the
tag prefixed with "tags/"
* nd/find-pack-entry-recent-cache-invalidation (2012-02-01) 2 commits
(merged to 'next' on 2012-02-01 at e26aed0)
+ find_pack_entry(): do not keep packed_git pointer locally
+ sha1_file.c: move the core logic of find_pack_entry() into fill_pack_entry()
* nd/pack-objects-parseopt (2012-02-01) 3 commits
- pack-objects: convert to use parse_options()
- pack-objects: remove bogus comment
- pack-objects: do not accept "--index-version=version,"
Will merge to 'next'.
"pack-objects" learned use parse-options, losing custom command line
parsing code.
* bl/gitweb-project-filter (2012-02-01) 8 commits
(merged to 'next' on 2012-02-01 at 2c96ce7)
+ gitweb: Make project search respect project_filter
+ gitweb: improve usability of projects search form
+ gitweb: place links to parent directories in page header
+ gitweb: show active project_filter in project_list page header
+ gitweb: limit links to alternate forms of project_list to active project_filter
+ gitweb: add project_filter to limit project list to a subdirectory
+ gitweb: prepare git_get_projects_list for use outside 'forks'.
+ gitweb: move hard coded .git suffix out of git_get_projects_list
"gitweb" allows intermediate entries in the directory hierarchy that leads
to a projects to be clicked, which in turn shows the list of projects
inside that directory.
* rt/completion-branch-edit-desc (2012-01-29) 1 commit
(merged to 'next' on 2012-02-01 at 0627ebf)
+ completion: --edit-description option for git-branch
Originally merged to 'next' on 2012-01-31.
Will merge to 'master'.
* jn/svn-fe (2012-02-02) 47 commits
- vcs-svn: suppress a -Wtype-limits warning
- vcs-svn: allow import of > 4GiB files
- vcs-svn: rename check_overflow arguments for clarity
(merged to 'next' on 2012-02-01 at 9288c95)
+ vcs-svn/svndiff.c: squelch false "unused" warning from gcc
+ Merge branch 'svn-fe' of git://repo.or.cz/git/jrn into jn/svn-fe
+ vcs-svn: reset first_commit_done in fast_export_init
+ Merge branch 'db/text-delta' into svn-fe
+ vcs-svn: do not initialize report_buffer twice
+ Merge branch 'db/text-delta' into svn-fe
+ vcs-svn: avoid hangs from corrupt deltas
+ vcs-svn: guard against overflow when computing preimage length
+ Merge branch 'db/delta-applier' into db/text-delta
+ vcs-svn: implement text-delta handling
+ Merge branch 'db/delta-applier' into db/text-delta
+ Merge branch 'db/delta-applier' into svn-fe
+ vcs-svn: cap number of bytes read from sliding view
+ test-svn-fe: split off "test-svn-fe -d" into a separate function
+ vcs-svn: let deltas use data from preimage
+ vcs-svn: let deltas use data from postimage
+ vcs-svn: verify that deltas consume all inline data
+ vcs-svn: implement copyfrom_data delta instruction
+ vcs-svn: read instructions from deltas
+ vcs-svn: read inline data from deltas
+ vcs-svn: read the preimage when applying deltas
+ vcs-svn: parse svndiff0 window header
+ vcs-svn: skeleton of an svn delta parser
+ vcs-svn: make buffer_read_binary API more convenient
+ vcs-svn: learn to maintain a sliding view of a file
+ Makefile: list one vcs-svn/xdiff object or header per line
+ Merge branch 'db/svn-fe-code-purge' into svn-fe
+ vcs-svn: drop obj_pool
+ vcs-svn: drop treap
+ vcs-svn: drop string_pool
+ vcs-svn: pass paths through to fast-import
+ Merge branch 'db/strbufs-for-metadata' into db/svn-fe-code-purge
+ Merge branch 'db/length-as-hash' (early part) into db/svn-fe-code-purge
+ Merge branch 'db/vcs-svn-incremental' into svn-fe
+ vcs-svn: avoid using ls command twice
+ vcs-svn: use mark from previous import for parent commit
+ vcs-svn: handle filenames with dq correctly
+ vcs-svn: quote paths correctly for ls command
+ vcs-svn: eliminate repo_tree structure
+ vcs-svn: add a comment before each commit
+ vcs-svn: save marks for imported commits
+ vcs-svn: use higher mark numbers for blobs
+ vcs-svn: set up channel to read fast-import cat-blob response
+ Merge commit 'v1.7.5' into svn-fe
Originally merged to 'next' on 2012-01-29.
"vcs-svn"/"svn-fe" learned to read dumps with svn-deltas and support
incremental imports.
Will merge to 'next' through the tip and then to 'master' soon after.
* jc/split-blob (2012-01-24) 6 commits
- chunked-object: streaming checkout
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
Not ready.
I finished the streaming checkout codepath, but as explained in 127b177
(bulk-checkin: support chunked-object encoding, 2011-11-30), these are
still early steps of a long and painful journey. At least pack-objects and
fsck need to learn the new encoding for the series to be usable locally,
and then index-pack/unpack-objects needs to learn it to be used remotely.
Given that I heard a lot of noise that people want large files, and that I
was asked by somebody at GitTogether'11 privately for an advice on how to
pay developers (not me) to help adding necessary support, I am somewhat
dissapointed that the original patch series that was sent almost two
months ago still remains here without much comments and updates from the
developer community. I even made the interface to the logic that decides
where to split chunks easily replaceable, and I deliberately made the
logic in the original patch extremely stupid to entice others, especially
the "bup" fanboys, to come up with a better logic, thinking that giving
people an easy target to shoot for, they may be encouraged to help
out. The plan is not working :-(.
^ permalink raw reply
* Re: Push from an SSH Terminal
From: Jeff King @ 2012-02-04 8:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sven Strickroth, Neal Groothuis, Feanil Patel, git
In-Reply-To: <7vwr83hwg0.fsf@alter.siamese.dyndns.org>
On Fri, Feb 03, 2012 at 11:47:11PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Fri, Feb 03, 2012 at 12:10:27PM -0500, Neal Groothuis wrote:
> > ...
> >> Check to see if the GIT_ASKPASS and/or SSH_ASKPASS environment variables
> >> are set, and if the core.askpass config variable is set. If any of these
> >> are set, unset them. Git should fall back to a simple password prompt.
> >
> > Hmm, yeah that is likely the problem. I was thinking git would fall back
> > to asking on the terminal, but it does not. We probably should.
>
> How well would it mesh with the goal of the ss/git-svn-prompt-sans-terminal
> topic, which is now stalled [*1*]? I do not mean this change and the other
> topic textually conflict with each other---but the philosophies of this
> topic and the other one seem to conflict. Not falling back to the terminal
> that is not available and failing the command outright might make more
> sense.
I don't see a conflict in the two series. That one seems to do two
things for perl programs:
1. respect SSH_ASKPASS along with GIT_ASKPASS
2. prefer askpass over asking on the terminal
But both of those are already the case in the C code.
If you look into the original complaint mentioned in the commit
messages, though, you will see that the some GUIs will appear to hang
when the terminal is prompted (because the prompt is reading from some
location invisible to the user). So in that sense, my patches could be a
regression for those users, as outright failing is better for them.
But I would argue that the bug is not prompting on the terminal, but
rather that the terminal-prompting code does not recognize when there is
no terminal connection to the user (and AFAICT, this is a Windows
problem). Any solution that doesn't fix that is really just papering
over the problem, and hurting people[1] on sane systems.
So I'd rather see the version of getpass() in compat/mingw.c better
learn to realize when we aren't actually connected to a console.
-Peff
[1] The amount of hurt is relatively small, though. It only hurts people
who set GIT_ASKPASS but can't use it (e.g., you set it in your
.bashrc because you connect via "ssh -X", but this time you happen
to be ssh-ing from a Windows box). And you can generally fix that
outside of git (e.g., by checking $DISPLAY before setting the
variable).
So one one hand, I don't want to make a decision on behavior for
Unix users because we have to cater to Windows shortcomings. On the
other hand, while fixing the root problem is preferable, if
for whatever reason we can't reliably find out whether the user is
actually going to see and respond to the prompt on Windows, it may
be practical to just paper over the issue. On the gripping hand,
after the Sven's series, TortoiseGit users would see the hang
(instead of a failure) _only_ if their askpass command failed. Which
is also perhaps not that big a deal.
^ permalink raw reply
* Re: BUG 1.7.9: git-update-ref strange behavior with ref with trailing newline
From: Junio C Hamano @ 2012-02-04 8:11 UTC (permalink / raw)
To: Jeff King; +Cc: Mark Jason Dominus, git
In-Reply-To: <20120202223250.GA28618@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> As far as the newlines go, I'm surprised we don't reject that. We should
> probably run check_refname_format on the proposed contents of the
> symbolic-ref.
Historically the plumbing commands were deliberately left loose on the
input side in the beginning, for the explicit purpose of allowing us to
more easily experiment, tweaking the low level data structures and file
formats. It's like being able to use a disk editor to experiment with the
filesystem. You feed good data, and you will see expected results. You
perform something other parts of the system does not yet expect, and you
find places that need further adjusting if you were to extend the format
you are futzing with the "bare metal manipulation tool" ;-)
It is not surprising at all that we haven't tightened the ones that normal
users would not use, and symbolic-ref is one of them. You needed to write
scripts that would use symbolic-ref yourself more often in the early days
of Git, but back in those days, (1) people who wrote scripts with plumbing
commands tended to know what they were doing and (2) we did not have that
much interaction between subsystems, like reflogs vs symrefs.
Now, those days are long gone, and we are done with experiments pretty
much. We should tighten remaining holes as we find them.
^ permalink raw reply
* Re: Push from an SSH Terminal
From: Junio C Hamano @ 2012-02-04 8:16 UTC (permalink / raw)
To: Jeff King; +Cc: Sven Strickroth, Neal Groothuis, Feanil Patel, git
In-Reply-To: <20120204080910.GA28317@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Feb 03, 2012 at 11:47:11PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> ...
>> How well would it mesh with the goal of the ss/git-svn-prompt-sans-terminal
>> topic, which is now stalled [*1*]? I do not mean this change and the other
>> topic textually conflict with each other---but the philosophies of this
>> topic and the other one seem to conflict.
>
> I don't see a conflict in the two series. That one seems to do two
> things for perl programs ...
That is the "[not] textually conflict" part of my message.
> If you look into the original complaint mentioned in the commit
> messages, though, you will see that the some GUIs will appear to hang
> when the terminal is prompted (because the prompt is reading from some
> location invisible to the user). So in that sense, my patches could be a
> regression for those users, as outright failing is better for them.
Yes, that is what I meant by "philosophies conflict".
> But I would argue that the bug is not prompting on the terminal, but
> rather that the terminal-prompting code does not recognize when there is
> no terminal connection to the user (and AFAICT, this is a Windows
> problem). Any solution that doesn't fix that is really just papering
> over the problem, and hurting people[1] on sane systems.
>
> So I'd rather see the version of getpass() in compat/mingw.c better
> learn to realize when we aren't actually connected to a console.
That is a sane diagnosis, I'd have to agree.
Thanks for a dose of sanity.
> [1] The amount of hurt is relatively small, though. It only hurts people
> who set GIT_ASKPASS but can't use it (e.g., you set it in your
> .bashrc because you connect via "ssh -X", but this time you happen
> to be ssh-ing from a Windows box). And you can generally fix that
> outside of git (e.g., by checking $DISPLAY before setting the
> variable).
>
> So one one hand, I don't want to make a decision on behavior for
> Unix users because we have to cater to Windows shortcomings. On the
> other hand, while fixing the root problem is preferable, if
> for whatever reason we can't reliably find out whether the user is
> actually going to see and respond to the prompt on Windows, it may
> be practical to just paper over the issue. On the gripping hand,
> after the Sven's series, TortoiseGit users would see the hang
> (instead of a failure) _only_ if their askpass command failed. Which
> is also perhaps not that big a deal.
Wow, you do have many hands ;-).
^ permalink raw reply
* Re: Git performance results on a large repository
From: slinky @ 2012-02-04 8:57 UTC (permalink / raw)
To: git
In-Reply-To: <CB5074CF.3AD7A%joshua.redstone@fb.com>
Joshua Redstone <joshua.redstone <at> fb.com> writes:
> The git performance we observed here is too slow for our needs. So the
> question becomes, if we want to keep using git going forward, what's the
> best way to improve performance. It seems clear we'll probably need some
> specialized servers (e.g., to perform git-blame quickly) and maybe
> specialized file system integration to detect what files have changed in a
> working tree.
Hi Joshua,
sounds like you have everything in a single .git. Split up the massive
repository to separate smaller .git repositories.
For example, Android code base is quite big. They use the repo tool to manage a
number of separate .git repositories as one big aggregate "repository".
Cheers,
Slinky
^ 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