* Re: install does not obey DESTDIR or --prefix for perl modules
From: Brandon Casey @ 2009-09-21 16:58 UTC (permalink / raw)
To: c; +Cc: git
In-Reply-To: <20090921160551.GD8173@gryning.com>
Craig Taylor wrote:
> Hi all
>
> I'm compiling/installing git in a Solaris environment without root.
> Using 'make DESTDIR=<some path> install' to stage an install to an
> alternate location.
> The perl module component of 'make DESTDIR=<some path> install' installs
> into the system perl lib path without prepending the forced install
> destination or my '--prefix'.
> This seems counter intuitive and I would consider a bug.
Try 'make prefix=<some path>'.
btw, this is in the first paragraph of the INSTALL document.
-brandon
^ permalink raw reply
* Re: install does not obey DESTDIR or --prefix for perl modules
From: Junio C Hamano @ 2009-09-21 17:58 UTC (permalink / raw)
To: Brandon Casey; +Cc: c, git
In-Reply-To: <Ow6bpZou9Vi0tKlyAN-qfjlAAtXvMqpXEAiG54zZ3C8fLI_6_Bt3oA@cipher.nrlssc.navy.mil>
Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:
> Craig Taylor wrote:
>> Hi all
>>
>> I'm compiling/installing git in a Solaris environment without root.
>> Using 'make DESTDIR=<some path> install' to stage an install to an
>> alternate location.
>> The perl module component of 'make DESTDIR=<some path> install' installs
>> into the system perl lib path without prepending the forced install
>> destination or my '--prefix'.
>> This seems counter intuitive and I would consider a bug.
>
> Try 'make prefix=<some path>'.
>
> btw, this is in the first paragraph of the INSTALL document.
But is that what Craig is trying to do?
I think he wants to build git to be installed in /usr/bin/git or whatever,
and he would say "prefix=/usr". He however wants "make install" to write
into /var/tmp/g/usr/bin/git, not /usr/bin/git, so that he can for example
make a tarball with "cd /var/tmp/g && tar cf ../git.tar .", and extract it
as root under the real '/'. "make DESTDIR=/var/tmp/g" is exactly for
that, and if it is not working I would say it is a bug.
^ permalink raw reply
* [PATCH v2] Remove '< >' from [<options>] since it's not necessary.
From: Thiago Farina @ 2009-09-21 18:12 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
Documentation/git-log.txt | 2 +-
Documentation/git-stash.txt | 4 ++--
builtin-log.c | 2 +-
git-stash.sh | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 3d79de1..985ffab 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -8,7 +8,7 @@ git-log - Show commit logs
SYNOPSIS
--------
-'git log' [<options>] [<since>..<until>] [[\--] <path>...]
+'git log' [options] [<since>..<until>] [[\--] <path>...]
DESCRIPTION
-----------
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 3f14b72..8a6d85c 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -8,7 +8,7 @@ git-stash - Stash the changes in a dirty working directory away
SYNOPSIS
--------
[verse]
-'git stash' list [<options>]
+'git stash' list [options]
'git stash' show [<stash>]
'git stash' drop [-q|--quiet] [<stash>]
'git stash' ( pop | apply ) [--index] [-q|--quiet] [<stash>]
@@ -64,7 +64,7 @@ from your worktree.
The `--patch` option implies `--keep-index`. You can use
`--no-keep-index` to override this.
-list [<options>]::
+list [options]::
List the stashes that you currently have. Each 'stash' is listed
with its name (e.g. `stash@\{0}` is the latest stash, `stash@\{1}` is
diff --git a/builtin-log.c b/builtin-log.c
index 25e21ed..1685546 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -28,7 +28,7 @@ static const char *fmt_patch_subject_prefix = "PATCH";
static const char *fmt_pretty;
static const char * const builtin_log_usage =
- "git log [<options>] [<since>..<until>] [[--] <path>...]\n"
+ "git log [options] [<since>..<until>] [[--] <path>...]\n"
" or: git show [options] <object>...";
static void cmd_log_init(int argc, const char **argv, const char *prefix,
diff --git a/git-stash.sh b/git-stash.sh
index 4febbbf..e5ab34a 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -2,7 +2,7 @@
# Copyright (c) 2007, Nanako Shiraishi
dashless=$(basename "$0" | sed -e 's/-/ /')
-USAGE="list [<options>]
+USAGE="list [options]
or: $dashless show [<stash>]
or: $dashless drop [-q|--quiet] [<stash>]
or: $dashless ( pop | apply ) [--index] [-q|--quiet] [<stash>]
--
1.6.5.rc1.37.gf5c31.dirty
^ permalink raw reply related
* Re: install does not obey DESTDIR or --prefix for perl modules
From: Brandon Casey @ 2009-09-21 18:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: c, git
In-Reply-To: <7vskeguqmb.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:
>
>> Craig Taylor wrote:
>>> Hi all
>>>
>>> I'm compiling/installing git in a Solaris environment without root.
>>> Using 'make DESTDIR=<some path> install' to stage an install to an
>>> alternate location.
>>> The perl module component of 'make DESTDIR=<some path> install' installs
>>> into the system perl lib path without prepending the forced install
>>> destination or my '--prefix'.
>>> This seems counter intuitive and I would consider a bug.
>> Try 'make prefix=<some path>'.
>>
>> btw, this is in the first paragraph of the INSTALL document.
>
> But is that what Craig is trying to do?
>
> I think he wants to build git to be installed in /usr/bin/git or whatever,
> and he would say "prefix=/usr". He however wants "make install" to write
> into /var/tmp/g/usr/bin/git, not /usr/bin/git, so that he can for example
> make a tarball with "cd /var/tmp/g && tar cf ../git.tar .", and extract it
> as root under the real '/'. "make DESTDIR=/var/tmp/g" is exactly for
> that, and if it is not working I would say it is a bug.
Ah. I did not realize that that is what DESTDIR is for.
Thanks for the correction.
-brandon
^ permalink raw reply
* Re: install does not obey DESTDIR or --prefix for perl modules
From: Craig Taylor @ 2009-09-21 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, git
In-Reply-To: <7vskeguqmb.fsf@alter.siamese.dyndns.org>
On Mon, Sep 21, 2009 at 10:58:20AM -0700, Junio C Hamano wrote:
> Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:
>
> > Craig Taylor wrote:
> >> Hi all
> >>
> >> I'm compiling/installing git in a Solaris environment without root.
> >> Using 'make DESTDIR=<some path> install' to stage an install to an
> >> alternate location.
> >> The perl module component of 'make DESTDIR=<some path> install' installs
> >> into the system perl lib path without prepending the forced install
> >> destination or my '--prefix'.
> >> This seems counter intuitive and I would consider a bug.
> >
> > Try 'make prefix=<some path>'.
> >
> > btw, this is in the first paragraph of the INSTALL document.
>
> But is that what Craig is trying to do?
>
> I think he wants to build git to be installed in /usr/bin/git or whatever,
> and he would say "prefix=/usr". He however wants "make install" to write
> into /var/tmp/g/usr/bin/git, not /usr/bin/git, so that he can for example
> make a tarball with "cd /var/tmp/g && tar cf ../git.tar .", and extract it
> as root under the real '/'. "make DESTDIR=/var/tmp/g" is exactly for
> that, and if it is not working I would say it is a bug.
Exactly as you describe here, different paths but same goal.
All binaries follow the DESTDIR path except the perl modules.
To register this as a bug do I need to do more than send this email?
Thanks
CraigT
--
c^ [c%5e]
No think. No Talk. Train.
^ permalink raw reply
* Re: [PATCH JGit 1/5] adding tests for ObjectDirectory
From: Shawn O. Pearce @ 2009-09-21 19:30 UTC (permalink / raw)
To: mr.gaffo; +Cc: git, mike.gaffney
In-Reply-To: <1253062116-13830-2-git-send-email-mr.gaffo@gmail.com>
mr.gaffo@gmail.com wrote:
> diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectDirectoryTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectDirectoryTest.java
> + private File testDir;
> +
> + @Override
> + protected void setUp() throws Exception {
> + testDir = new File(new File(System.getProperty("java.io.tmpdir")), UUID.randomUUID().toString());
> + }
Can't we use the same logic we use in RepositoryTestCase to create
the temporary directory for this test? I would rather keep the
temporary space under target/ when testing under Maven, as it
makes it far easier to clean up the directory. Plus we know we
have sufficient write space there.
> + @Override
> + protected void tearDown() throws Exception {
> + if (testDir.exists()){
Style nit: Space between ) and {
> + public void testExistsWithNonExistantDirectory() throws Exception {
> + assertFalse(new ObjectDirectory(new File("/some/nonexistant/file")).exists());
Please create a path name below your testDir which you know won't
exist. I don't want this test to rely upon the fact that some
absolute path doesn't exist that is outside of our namespace control.
> + private void createTestDir(){
You use this method once, inline it inside
testExistsWithExistingDirectory().
Otherwise, the test case is OK, but is still quite sparse with
regards to functionality of the class being tested. Was it your
intention to only cover the most basic parts at this time? Its more
coverage than we have now, so I'm happy, but just wanted to point
out it certainly isn't complete (e.g. no pack support).
--
Shawn.
^ permalink raw reply
* Re: [PATCH JGit 2/5] Create abstract method on ObjectDatabase for accessing the list of local pack files.
From: Shawn O. Pearce @ 2009-09-21 19:40 UTC (permalink / raw)
To: mr.gaffo; +Cc: git, mike.gaffney
In-Reply-To: <1253062116-13830-3-git-send-email-mr.gaffo@gmail.com>
mr.gaffo@gmail.com wrote:
> diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectDirectoryTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ObjectDirectoryTest.java
> + public void testListLocalPacksWhenThereIsAPack() throws Exception {
> + createTestDir();
> + File packsDir = new File(testDir, "pack");
> + packsDir.mkdirs();
Why not allow the ObjectDirectory code to create the directory
before copying the pack into it?
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectDatabase.java b/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectDatabase.java
> + /**
> + * The list of Packs THIS repo contains
Don't you mean the list of packs this object database contains?
An object database may not be a git repository. Though yes, the
common case is that it is a repository.
> + * @return List<PackFile> of package names contained in this repo.
> + * Should be an empty list if there are none.
> + */
> + public abstract List<PackFile> listLocalPacks();
I think you should define this to be an unmodifiable list, not just
any list. Its sad that the Java type system didn't support this
idea back when they added the new collections APIs.
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectDirectory.java b/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectDirectory.java
> + @Override
> + public List<PackFile> listLocalPacks() {
> + tryAgain1();
> + return new ArrayList<PackFile>(Arrays.asList(packList.get().packs));
Instead of copying, why not return an unmodifiableList wrapped
around the array? PackList will never modify its internal array.
--
Shawn.
^ permalink raw reply
* Re: install does not obey DESTDIR or --prefix for perl modules
From: Junio C Hamano @ 2009-09-21 19:44 UTC (permalink / raw)
To: c; +Cc: Brandon Casey, git
In-Reply-To: <20090921191943.GE8173@gryning.com>
Craig Taylor <c@gryning.com> writes:
> Exactly as you describe here, different paths but same goal.
> All binaries follow the DESTDIR path except the perl modules.
>
> To register this as a bug do I need to do more than send this email?
Do you use NO_PERL_MAKEMAKER in your build?
If not, we need to summon an expert on ExtUtils::MakeMaker to look into
this issue, but if you do, perhaps you can try this patch and report how
well it works for you.
---
perl/Makefile | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/perl/Makefile b/perl/Makefile
index e3dd1a5..4ab21d6 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -29,11 +29,11 @@ $(makfile): ../GIT-CFLAGS Makefile
'$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
echo ' cp private-Error.pm blib/lib/Error.pm' >> $@
echo install: >> $@
- echo ' mkdir -p "$(instdir_SQ)"' >> $@
- echo ' $(RM) "$(instdir_SQ)/Git.pm"; cp Git.pm "$(instdir_SQ)"' >> $@
- echo ' $(RM) "$(instdir_SQ)/Error.pm"' >> $@
+ echo ' mkdir -p "$$(DESTDIR)$(instdir_SQ)"' >> $@
+ echo ' $(RM) "$$(DESTDIR)$(instdir_SQ)/Git.pm"; cp Git.pm "$$(DESTDIR)$(instdir_SQ)"' >> $@
+ echo ' $(RM) "$$(DESTDIR)$(instdir_SQ)/Error.pm"' >> $@
'$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
- echo ' cp private-Error.pm "$(instdir_SQ)/Error.pm"' >> $@
+ echo ' cp private-Error.pm "$$(DESTDIR)$(instdir_SQ)/Error.pm"' >> $@
echo instlibdir: >> $@
echo ' echo $(instdir_SQ)' >> $@
else
^ permalink raw reply related
* Re: install does not obey DESTDIR or --prefix for perl modules
From: Craig Taylor @ 2009-09-21 19:46 UTC (permalink / raw)
To: Ben Walton; +Cc: Junio C Hamano, Brandon Casey, git
In-Reply-To: <1253561929-sup-8931@ntdws12.chass.utoronto.ca>
On Mon, Sep 21, 2009 at 03:40:04PM -0400, Ben Walton wrote:
> Excerpts from Craig Taylor's message of Mon Sep 21 15:19:43 -0400 2009:
>
> > Exactly as you describe here, different paths but same goal.
> > All binaries follow the DESTDIR path except the perl modules.
>
> I haven't had this problem and I've been packaging git for solaris (8
> or newer) since early 2009. If you're interested in my build notes,
> feel free to ping me.
>
> Thanks
> -Ben
Will take you up on this. I'll re-raise this if they don't help.
Thanks
CraigT
--
c^ [c%5e]
Even when you are standing in front of defeat, do it smiling.
^ permalink raw reply
* Re: [PATCH JGit 2/5] Create abstract method on ObjectDatabase for accessing the list of local pack files.
From: Michael Gaffney @ 2009-09-21 19:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090921194035.GM14660@spearce.org>
Shawn O. Pearce wrote:
> Why not allow the ObjectDirectory code to create the directory
> before copying the pack into it?
Good point, this was one of the first tests I did before I got to that
part of ObjectDirectory. Will fix.
> Don't you mean the list of packs this object database contains?
> An object database may not be a git repository. Though yes, the
> common case is that it is a repository.
What's the difference in terminology? Not aruging, just wanting to know
what we're calling a repo and what we're not so that I use it correctly.
Will fix.
>> + public abstract List<PackFile> listLocalPacks();
>
> I think you should define this to be an unmodifiable list, not just
> any list. Its sad that the Java type system didn't support this
> idea back when they added the new collections APIs.
Should it be a collection as well instead of a list; what would you
specifically suggest?
> Instead of copying, why not return an unmodifiableList wrapped
> around the array? PackList will never modify its internal array.
Same as above
-Mike
^ permalink raw reply
* Re: install does not obey DESTDIR or --prefix for perl modules
From: Craig Taylor @ 2009-09-21 19:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, git
In-Reply-To: <7vocp4ulq2.fsf@alter.siamese.dyndns.org>
On Mon, Sep 21, 2009 at 12:44:05PM -0700, Junio C Hamano wrote:
> Craig Taylor <c@gryning.com> writes:
>
> > Exactly as you describe here, different paths but same goal.
> > All binaries follow the DESTDIR path except the perl modules.
> >
> > To register this as a bug do I need to do more than send this email?
>
> Do you use NO_PERL_MAKEMAKER in your build?
>
> If not, we need to summon an expert on ExtUtils::MakeMaker to look into
> this issue, but if you do, perhaps you can try this patch and report how
> well it works for you.
>
> ---
> perl/Makefile | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/perl/Makefile b/perl/Makefile
> index e3dd1a5..4ab21d6 100644
> --- a/perl/Makefile
> +++ b/perl/Makefile
> @@ -29,11 +29,11 @@ $(makfile): ../GIT-CFLAGS Makefile
> '$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
> echo ' cp private-Error.pm blib/lib/Error.pm' >> $@
> echo install: >> $@
> - echo ' mkdir -p "$(instdir_SQ)"' >> $@
> - echo ' $(RM) "$(instdir_SQ)/Git.pm"; cp Git.pm "$(instdir_SQ)"' >> $@
> - echo ' $(RM) "$(instdir_SQ)/Error.pm"' >> $@
> + echo ' mkdir -p "$$(DESTDIR)$(instdir_SQ)"' >> $@
> + echo ' $(RM) "$$(DESTDIR)$(instdir_SQ)/Git.pm"; cp Git.pm "$$(DESTDIR)$(instdir_SQ)"' >> $@
> + echo ' $(RM) "$$(DESTDIR)$(instdir_SQ)/Error.pm"' >> $@
> '$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
> - echo ' cp private-Error.pm "$(instdir_SQ)/Error.pm"' >> $@
> + echo ' cp private-Error.pm "$$(DESTDIR)$(instdir_SQ)/Error.pm"' >> $@
> echo instlibdir: >> $@
> echo ' echo $(instdir_SQ)' >> $@
> else
I have 2 perl environments available to me on the system (at home now so
can't dig further).
Both can pretty stripped which can make thing "challenging" it's
possible ExtUtils::MakeMaker doesn't even exist.
Please everyone who is looking at this thread let it sleep for 24h and I
shall test further/revive it tomorrow.
Many thanks
CraigT
--
c^ [c%5e]
Learn first whatever hardship you may have to endure is but temporary
^ permalink raw reply
* Re: [PATCH] Trivial fix: Make all the builtin usage strings to use the same pattern.
From: Thiago Farina @ 2009-09-21 20:05 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <pN7ragma8Ra75P8lN7iHuXE6FyUXHXFlnHUVFZqJV4WM7w5mCkVHcQ@cipher.nrlssc.navy.mil>
On Mon, Sep 21, 2009 at 12:28 PM, Brandon Casey
<brandon.casey.ctr@nrlssc.navy.mil> wrote:
> Thiago Farina wrote:
>> They follow the pattern of file name:
>> File name pattern: builtin-command-name.c
>> Usage string pattern: builtin_command_name_usage
>>
>> Signed-off-by: Thiago Farina <tfransosi@gmail.com>
>> ---
>
>> diff --git a/builtin-blame.c b/builtin-blame.c
>> index 7512773..4adae84 100644
>> --- a/builtin-blame.c
>> +++ b/builtin-blame.c
>> @@ -21,10 +21,11 @@
>> #include "parse-options.h"
>> #include "utf8.h"
>>
>> -static char blame_usage[] = "git blame [options] [rev-opts] [rev] [--] file";
>> +static char builtin_blame_usage[] =
>
> Should this one also use 'const'?
It can use const here. I will do this change in the next patch.
>
>> +"git blame [options] [rev-opts] [rev] [--] file";
>>
>> static const char *blame_opt_usage[] = {
>> - blame_usage,
>> + builtin_blame_usage,
>> "",
>> "[rev-opts] are documented in git-rev-list(1)",
>> NULL
>
>> diff --git a/builtin-count-objects.c b/builtin-count-objects.c
>> index 1b0b6c8..fbe0972 100644
>> --- a/builtin-count-objects.c
>> +++ b/builtin-count-objects.c
>> @@ -65,7 +65,7 @@ static void count_objects(DIR *d, char *path, int len, int verbose,
>> }
>> }
>>
>> -static char const * const count_objects_usage[] = {
>> +static char const * const builtin_count_objects_usage[] = {
>
> This one is different from the others. I assume 'char const *' is
> the same as 'const char *', though I'm used to seeing the latter
> form. If we're going for consistency, maybe this should be changed
> too. Ultra minor nit-pick. I noticed it, so I mentioned it, but
> its your choice.
To maintain the consistency I will follow the latter form, since all
others are using "const char *".
Thanks for catching the ones that I missed. I will update them in the
next patch.
^ permalink raw reply
* Re: install does not obey DESTDIR or --prefix for perl modules
From: Ben Walton @ 2009-09-21 19:40 UTC (permalink / raw)
To: c; +Cc: Junio C Hamano, Brandon Casey, git
In-Reply-To: <20090921191943.GE8173@gryning.com>
[-- Attachment #1: Type: text/plain, Size: 572 bytes --]
Excerpts from Craig Taylor's message of Mon Sep 21 15:19:43 -0400 2009:
> Exactly as you describe here, different paths but same goal.
> All binaries follow the DESTDIR path except the perl modules.
I haven't had this problem and I've been packaging git for solaris (8
or newer) since early 2009. If you're interested in my build notes,
feel free to ping me.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Trivial fix: Display a more friendly message with git-shell.
From: Thiago Farina @ 2009-09-21 20:45 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Johannes Sixt, git
In-Reply-To: <vpqeiq0ssn7.fsf@bauges.imag.fr>
Hi Matthieu
On Mon, Sep 21, 2009 at 3:45 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Perhaps one more line saying what 'man git-shell' says in addition
> would help:
>
> $ git-shell
> git-shell: Restricted login shell for GIT-only SSH access
> Usage: ...
I added this line to the output usage, but would be good to show the
commands that git-shell accept too?
^ permalink raw reply
* Re: [msysGit] Issue 332 in msysgit: .gitattributes dir/ patterns are not processed
From: Heiko Voigt @ 2009-09-21 21:39 UTC (permalink / raw)
To: git; +Cc: msysgit
In-Reply-To: <001636d33903a05b960474181c0a@google.com>
On Mon, Sep 21, 2009 at 03:26:55PM +0000, codesite-noreply@google.com wrote:
> New issue 332 by vsuvo...@geolearning.com: .gitattributes dir/ patterns are
> not processed
> http://code.google.com/p/msysgit/issues/detail?id=332
>
> What steps will reproduce the problem?
> 1. Create a project and initialize git:
> md foo
> cd foo
> git init
>
> 2. create subdirectory and a file in it:
> md bar
> echo sample text >bar\testfile.txt
>
> 3. create .gitatributes, add/commit it:
> echo bar/ binary >.gitattributes
> git add .gitattributes
> git commit -m "ground zero"
>
> 4. check bar\testfile.txt
> git check-attr binary bar/testfile.txt
>
> What is the expected output? What do you see instead?
> expected output: "bar/testfile.txt": binary: set
> see instead: "bar/testfile.txt": binary: unspecified
This issue came up on the msysgit bug tracker. So here is either the
documentation wrong or the implementation.
Because it does not make sense to specify any attributes to directories
itself I would expect the contents of the directory to get the
attributes.
What do you think?
cheers Heiko
^ permalink raw reply
* Re: [PATCH] Trivial fix: Make all the builtin usage strings to use the same pattern.
From: Thiago Farina @ 2009-09-21 21:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4AB7A534.2070406@viscovery.net>
On Mon, Sep 21, 2009 at 1:09 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Thiago Farina schrieb:
>> They follow the pattern of file name:
>> File name pattern: builtin-command-name.c
>> Usage string pattern: builtin_command_name_usage
>
> Well, file names are not so constant: every now and then an external
> command is turned into a builtin (and the filename is changed), and we
> have even seen that a builtin was turned into an external command.
> Moreover, some commands are implemented in the same file, for example 'git
> log' and 'git show'. How about naming the variable after the command name?
> E.g.:
>
> command: git cat-file
> variable: git_cat_file_usage
That sounds good, I will follow this pattern in the next patch. So all
existing builtin_command_name_usage will be changed to
git_command_name_usage, command_name_usage to git_command_name_usage,
etc.
^ permalink raw reply
* Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Pat Thoyts @ 2009-09-21 23:56 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Murphy, John, Paul Mackerras, git
In-Reply-To: <4AB7A2E7.5000601@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
>Murphy, John schrieb:
>
>On Windows, 'gitk --all' starts with branch-0797, on Linux it starts with
>branch-0999 aka master.
That script gives me a repository I can test against. thanks.
The start_rev_list function calls parseviewrevs and expands the
arguments into a list of appropriate revision ids. In this case --all
gets expanded to a list of 1000 sha1 ids. This is appended to any
other view arguments and passed to git log on the command line
yielding our error.
git log can accept a --all argument it seems so it looks like we can
just short-circuit the parseviewrevs function when --all is passed in
and return --all instead of expanding the list. The following seems to
work for me with this test repository.
John, if this works for you can you also check that editing and
creating new gitk views on your real repository continues to work ok.
commit 7f289ca8370e5e2f9622a4fbc30b934eb97b984f
Author: Pat Thoyts <patthoyts@users.sourceforge.net>
Date: Tue Sep 22 00:55:50 2009 +0100
Avoid expanding --all when passing arguments to git log.
There is no need to expand --all into a list of all revisions as
git log can accept --all as an argument. This avoids any
command-line
length limitations caused by expanding --all into a list of all
revision ids.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
diff --git a/gitk b/gitk
index a0214b7..635b97e 100755
--- a/gitk
+++ b/gitk
@@ -241,6 +241,8 @@ proc parseviewrevs {view revs} {
if {$revs eq {}} {
set revs HEAD
+ } elseif {$revs eq "--all"} {
+ return $revs
}
if {[catch {set ids [eval exec git rev-parse $revs]} err]} {
# we get stdout followed by stderr in $err
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply related
* [PATCH] RelNotes-1.6.5: fix spelling of 'Mozilla'
From: Miklos Vajna @ 2009-09-22 0:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/RelNotes-1.6.5.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/RelNotes-1.6.5.txt b/Documentation/RelNotes-1.6.5.txt
index 25529f7..3c46192 100644
--- a/Documentation/RelNotes-1.6.5.txt
+++ b/Documentation/RelNotes-1.6.5.txt
@@ -46,7 +46,7 @@ Updates since v1.6.4
* On major platforms, the system can be compiled to use with Linus's
block-sha1 implementation of the SHA-1 hash algorithm, which
outperforms the default fallback implementation we borrowed from
- Mozzilla.
+ Mozilla.
* Unnecessary inefficiency in deepening of a shallow repository has
been removed.
--
1.6.4
^ permalink raw reply related
* RE: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Murphy, John @ 2009-09-22 1:23 UTC (permalink / raw)
To: Pat Thoyts, Johannes Sixt; +Cc: Paul Mackerras, git
In-Reply-To: <874oqvc0n3.fsf@users.sourceforge.net>
Pat Thoyts writes:
> John, if this works for you can you also check that editing and
> creating new gitk views on your real repository continues to work ok.
Works like a charm.
I look forward to it coming in a new version of git.
Thank you very much.
^ permalink raw reply
* Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Junio C Hamano @ 2009-09-22 1:39 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Johannes Sixt, Murphy, John, Paul Mackerras, git
In-Reply-To: <874oqvc0n3.fsf@users.sourceforge.net>
Pat Thoyts <patthoyts@users.sourceforge.net> writes:
> commit 7f289ca8370e5e2f9622a4fbc30b934eb97b984f
> Author: Pat Thoyts <patthoyts@users.sourceforge.net>
> Date: Tue Sep 22 00:55:50 2009 +0100
>
> Avoid expanding --all when passing arguments to git log.
> There is no need to expand --all into a list of all revisions as
> git log can accept --all as an argument. This avoids any
> command-line
> length limitations caused by expanding --all into a list of all
> revision ids.
>
> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
>
> diff --git a/gitk b/gitk
> index a0214b7..635b97e 100755
> --- a/gitk
> +++ b/gitk
> @@ -241,6 +241,8 @@ proc parseviewrevs {view revs} {
>
> if {$revs eq {}} {
> set revs HEAD
> + } elseif {$revs eq "--all"} {
> + return $revs
> }
That looks like an ugly hack (aka sweeping the issue under the rug).
What if there are many tags and the user used --tags? Don't you have
exactly the same problem? Likewise, what if $revs were "..master"?
The right approach would be to understand what limit it is busting (it is
not likely to be the command line length limit for this particular "exec",
as it only gets "git" "rev-parse" "--all") first, and then fix that.
> if {[catch {set ids [eval exec git rev-parse $revs]} err]} {
> # we get stdout followed by stderr in $err
^ permalink raw reply
* Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Junio C Hamano @ 2009-09-22 1:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Pat Thoyts, Johannes Sixt, Murphy, John, Paul Mackerras, git
In-Reply-To: <7v1vlzvjtg.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Pat Thoyts <patthoyts@users.sourceforge.net> writes:
>
>> commit 7f289ca8370e5e2f9622a4fbc30b934eb97b984f
>> Author: Pat Thoyts <patthoyts@users.sourceforge.net>
>> Date: Tue Sep 22 00:55:50 2009 +0100
>>
>> Avoid expanding --all when passing arguments to git log.
>> There is no need to expand --all into a list of all revisions as
>> git log can accept --all as an argument. This avoids any
>> command-line
>> length limitations caused by expanding --all into a list of all
>> revision ids.
>>
>> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
>>
>> diff --git a/gitk b/gitk
>> index a0214b7..635b97e 100755
>> --- a/gitk
>> +++ b/gitk
>> @@ -241,6 +241,8 @@ proc parseviewrevs {view revs} {
>>
>> if {$revs eq {}} {
>> set revs HEAD
>> + } elseif {$revs eq "--all"} {
>> + return $revs
>> }
>
> That looks like an ugly hack (aka sweeping the issue under the rug).
>
> What if there are many tags and the user used --tags? Don't you have
> exactly the same problem? Likewise, what if $revs were "..master"?
Sorry, I meant "--all --not master" to grab all the topics not merged to
master yet.
But my point still stands.
I do not understand what computed values storedin vposids() and vnegids()
arrays are being used in the other parts of the program that rely on this
function to do what it was asked to do, but if this patch can ever be
correct, a much simpler solution to make this function almost no-op and
always return {} (empty array ret is initialized to) would be an equally
valid fix, no? And my gut feeling tells me that such a change to make
this function a no-op _can't_ be a valid fix.
> The right approach would be to understand what limit it is busting (it is
> not likely to be the command line length limit for this particular "exec",
> as it only gets "git" "rev-parse" "--all") first, and then fix that.
>
>> if {[catch {set ids [eval exec git rev-parse $revs]} err]} {
>> # we get stdout followed by stderr in $err
^ permalink raw reply
* [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Michael Wookey @ 2009-09-22 4:10 UTC (permalink / raw)
To: git
MSVC builds define UNICODE which results in the "WIDE" variation of
Win32 API's being used.
Explicitly use the ANSI variation of the API's for compatibility with
msysgit.
Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
---
compat/mingw.c | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 6b5b5b2..39be42f 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -135,7 +135,7 @@ int mingw_open (const char *filename, int oflags, ...)
fd = open(filename, oflags, mode);
if (fd < 0 && (oflags & O_CREAT) && errno == EACCES) {
- DWORD attrs = GetFileAttributes(filename);
+ DWORD attrs = GetFileAttributesA(filename);
if (attrs != INVALID_FILE_ATTRIBUTES && (attrs & FILE_ATTRIBUTE_DIRECTORY))
errno = EISDIR;
}
@@ -607,7 +607,7 @@ static char *lookup_prog(const char *dir, const
char *cmd, int isexe, int exe_on
return xstrdup(path);
path[strlen(path)-4] = '\0';
if ((!exe_only || isexe) && access(path, F_OK) == 0)
- if (!(GetFileAttributes(path) & FILE_ATTRIBUTE_DIRECTORY))
+ if (!(GetFileAttributesA(path) & FILE_ATTRIBUTE_DIRECTORY))
return xstrdup(path);
return NULL;
}
@@ -641,14 +641,14 @@ static int env_compare(const void *a, const void *b)
static pid_t mingw_spawnve(const char *cmd, const char **argv, char **env,
int prepend_cmd)
{
- STARTUPINFO si;
+ STARTUPINFOA si;
PROCESS_INFORMATION pi;
struct strbuf envblk, args;
unsigned flags;
BOOL ret;
/* Determine whether or not we are associated to a console */
- HANDLE cons = CreateFile("CONOUT$", GENERIC_WRITE,
+ HANDLE cons = CreateFileA("CONOUT$", GENERIC_WRITE,
FILE_SHARE_WRITE, NULL, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, NULL);
if (cons == INVALID_HANDLE_VALUE) {
@@ -717,7 +717,7 @@ static pid_t mingw_spawnve(const char *cmd, const
char **argv, char **env,
}
memset(&pi, 0, sizeof(pi));
- ret = CreateProcess(cmd, args.buf, NULL, NULL, TRUE, flags,
+ ret = CreateProcessA(cmd, args.buf, NULL, NULL, TRUE, flags,
env ? envblk.buf : NULL, NULL, &si, &pi);
if (env)
@@ -965,23 +965,23 @@ int mingw_rename(const char *pold, const char *pnew)
if (errno != EEXIST)
return -1;
repeat:
- if (MoveFileEx(pold, pnew, MOVEFILE_REPLACE_EXISTING))
+ if (MoveFileExA(pold, pnew, MOVEFILE_REPLACE_EXISTING))
return 0;
/* TODO: translate more errors */
gle = GetLastError();
if (gle == ERROR_ACCESS_DENIED &&
- (attrs = GetFileAttributes(pnew)) != INVALID_FILE_ATTRIBUTES) {
+ (attrs = GetFileAttributesA(pnew)) != INVALID_FILE_ATTRIBUTES) {
if (attrs & FILE_ATTRIBUTE_DIRECTORY) {
errno = EISDIR;
return -1;
}
if ((attrs & FILE_ATTRIBUTE_READONLY) &&
- SetFileAttributes(pnew, attrs & ~FILE_ATTRIBUTE_READONLY)) {
- if (MoveFileEx(pold, pnew, MOVEFILE_REPLACE_EXISTING))
+ SetFileAttributesA(pnew, attrs & ~FILE_ATTRIBUTE_READONLY)) {
+ if (MoveFileExA(pold, pnew, MOVEFILE_REPLACE_EXISTING))
return 0;
gle = GetLastError();
/* revert file attributes on failure */
- SetFileAttributes(pnew, attrs);
+ SetFileAttributesA(pnew, attrs);
}
}
if (tries < ARRAY_SIZE(delay) && gle == ERROR_ACCESS_DENIED) {
@@ -1006,7 +1006,7 @@ struct passwd *getpwuid(int uid)
static struct passwd p;
DWORD len = sizeof(user_name);
- if (!GetUserName(user_name, &len))
+ if (!GetUserNameA(user_name, &len))
return NULL;
p.pw_name = user_name;
p.pw_gecos = "unknown";
@@ -1151,7 +1151,7 @@ void mingw_open_html(const char *unixpath)
{
const char *htmlpath = make_backslash_path(unixpath);
printf("Launching default browser to display HTML ...\n");
- ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
+ ShellExecuteA(NULL, "open", htmlpath, NULL, "\\", 0);
}
int link(const char *oldpath, const char *newpath)
@@ -1160,7 +1160,7 @@ int link(const char *oldpath, const char *newpath)
static T create_hard_link = NULL;
if (!create_hard_link) {
create_hard_link = (T) GetProcAddress(
- GetModuleHandle("kernel32.dll"), "CreateHardLinkA");
+ GetModuleHandleA("kernel32.dll"), "CreateHardLinkA");
if (!create_hard_link)
create_hard_link = (T)-1;
}
--
1.6.5.rc1.44.ga1675
^ permalink raw reply related
* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Johannes Sixt @ 2009-09-22 6:08 UTC (permalink / raw)
To: Michael Wookey, Marius Storm-Olsen; +Cc: git
In-Reply-To: <d2e97e800909212110w423e3b2fm85ac6f76439e0591@mail.gmail.com>
Michael Wookey schrieb:
> MSVC builds define UNICODE which results in the "WIDE" variation of
> Win32 API's being used.
>
> Explicitly use the ANSI variation of the API's for compatibility with
> msysgit.
>
> Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
Marius,
I would like to understand why you did not have this issue.
The patch itself looks fine.
-- Hannes
^ permalink raw reply
* Re: Cygwin git dies silently
From: Clemens Buchacher @ 2009-09-22 7:08 UTC (permalink / raw)
To: John Ousterhout; +Cc: git
In-Reply-To: <33D78C6C5C9F45379BC3C07BD3017260@ouster>
[re-adding the list to Cc for future reference]
On Mon, Sep 21, 2009 at 03:37:43PM -0700, John Ousterhout wrote:
> your message eventually led me to the problem, which
> is that somehow I didn't have libz installed. Once I installed libz
> git is now working.
I'm surprised that cygwin did not take care of installing the dependencies
for you. After all, you were installing the version "that came with cygwin"?
If that is the case, please file a bug report with cygwin, because it's
clearly a problem with their packaging.
Thanks,
Clemens
^ permalink raw reply
* Re: [PATCH] Trivial fix: Display a more friendly message with git-shell.
From: Matthieu Moy @ 2009-09-22 7:28 UTC (permalink / raw)
To: Thiago Farina; +Cc: Johannes Sixt, git
In-Reply-To: <a4c8a6d00909211345q593e673bo4964204afa5ce807@mail.gmail.com>
Thiago Farina <tfransosi@gmail.com> writes:
> Hi Matthieu
> On Mon, Sep 21, 2009 at 3:45 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Perhaps one more line saying what 'man git-shell' says in addition
>> would help:
>>
>> $ git-shell
>> git-shell: Restricted login shell for GIT-only SSH access
>> Usage: ...
> I added this line to the output usage, but would be good to show the
> commands that git-shell accept too?
Well, at some point, I think the user will have to read the man page.
I find it better to have a non-agressive error message, but I'm not
sure it's relevant to try to give the complete manual here.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ 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