* Re: Pair Programming Workflow Suggestions
From: Tim Visher @ 2009-09-20 15:37 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Sean Estabrooks, Git Mailing List
In-Reply-To: <20090916141730.GA24893@vidovic>
On Wed, Sep 16, 2009 at 10:17 AM, Nicolas Sebrecht <nicolas.s.dev@gmx.fr> wrote:
> The 16/09/09, Tim Visher wrote:
>>
>> Pairing, on the other hand, is much more
>> tightly integrated than that. Just like in Brian's post, it's really
>> a situation of Dev1 _&_ Dev2 wrote this feature, but one of them
>> happened to be typing and doing most of the nitty-gritty developing.
>> Changing the authors between committs almost seems to introduce an
>> arbitrary level of distinction where it's no longer _both_ but _one
>> then the other_. Does that make my question any clearer?
>
> FMPOV (and to follow the Pair Programming purpose), there isn't an "I"
> in "Pair". So having the same author name and sign-off for each pair is
> what makes most sense. IMHO, "dev1_and_dev2" is actually the best
> option.
That's certainly interesting. I guess I just assumed, not having too
much practical experience with actually pairing, that the driver would
be doing most of the coding for a given commit… It's true that that's
not really the case.
Do you guys use Hudson or something similar when you're pairing?
How's your experience regarding how it interoperates with the
dev_1_and_dev_2 naming convention?
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* [PATCH] Trivial fix: Display a more friendly message with git-shell.
From: Thiago Farina @ 2009-09-20 17:11 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
Instead of simply die without give a helpful message, displays the usage
string that shows to the user how it can be used.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
shell.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/shell.c b/shell.c
index e4864e0..aa7f47e 100644
--- a/shell.c
+++ b/shell.c
@@ -3,6 +3,8 @@
#include "exec_cmd.h"
#include "strbuf.h"
+static const char shell_usage[] = "git shell -c <command> <argument>";
+
static int do_generic_cmd(const char *me, char *arg)
{
const char *my_argv[4];
@@ -74,7 +76,7 @@ int main(int argc, char **argv)
* where "cmd" is a very limited subset of git commands.
*/
else if (argc != 3 || strcmp(argv[1], "-c"))
- die("What do you think I am? A shell?");
+ usage(shell_usage);
prog = argv[2];
if (!strncmp(prog, "git", 3) && isspace(prog[3]))
--
1.6.5.rc1.37.gf5c31.dirty
^ permalink raw reply related
* [(resend) PATCH] push: Correctly initialize nonfastforward in transport_push.
From: Matthieu Moy @ 2009-09-20 17:33 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
The variable is assigned unconditionally in print_push_status, but
print_push_status is not reached by all codepaths. In particular, this
fixes a bug where "git push ... nonexisting-branch" was complaining about
non-fast forward.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Just making sure the patch hasn't been forgotten ... (and changed the
subject from do_push to transport_push)
Regards,
transport.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/transport.c b/transport.c
index 4cb8077..18db3d3 100644
--- a/transport.c
+++ b/transport.c
@@ -871,6 +871,7 @@ int transport_push(struct transport *transport,
int refspec_nr, const char **refspec, int flags,
int * nonfastforward)
{
+ *nonfastforward = 0;
verify_remote_names(refspec_nr, refspec);
if (transport->push)
--
1.6.5.rc1.11.g2d184.dirty
^ permalink raw reply related
* Documentation problems
From: Bruce Korb @ 2009-09-20 17:58 UTC (permalink / raw)
To: git
Hi,
I'm trying to figure out what a ``tree-ish''.
I cannot seem to use many of the commands until I know.
<tree-ish>
Indicates a tree, commit or tag object name. A command that takes a
<tree-ish> argument ultimately wants to operate on a <tree> object
but automatically dereferences <commit> and <tag> objects that point at a <tree>.
I need a translation. :( Thank you. Regards, Bruce
P.S. I have a SuSE installation with everything relating to GIT installed.
The man pages reference commands like, "git-ls-tree --name-only" except
that there isn't any such command. Unless you reverse engineer the
implementation of "git", discover the /usr/lib/git directory and add it
to your path. That hassle is rather inconvenient. More hints about
where the git commands get squirreled away would be useful. Thank you.
^ permalink raw reply
* Re: Documentation problems
From: Matthieu Moy @ 2009-09-20 18:24 UTC (permalink / raw)
To: Bruce Korb; +Cc: git
In-Reply-To: <4AB66D4C.70301@gmail.com>
Bruce Korb <bruce.korb@gmail.com> writes:
> Hi,
>
> I'm trying to figure out what a ``tree-ish''.
> I cannot seem to use many of the commands until I know.
>
> <tree-ish>
> Indicates a tree, commit or tag object name. A command that takes a
> <tree-ish> argument ultimately wants to operate on a <tree> object
> but automatically dereferences <commit> and <tag> objects that point at a <tree>.
>
> I need a translation. :( Thank you. Regards, Bruce
tree = directory (with its content).
For example, the last commit in the current branch is a Git object of
type "commit", which contains mostly a log message, a few headers, and
a pointer to the tree object corresponding to the content of the
directory in which you made the commit (modulo what you excluded from
the commit of course). Therefore, the name of this commit, although
not really a tree, is a tree-ish in that it talks about one and only
one tree. You could name it HEAD, a sha1sum (like
5a2abc12d64a5e00daa6aebbb673715f365a564a), the name of the branch
(like "master"), ...
> P.S. I have a SuSE installation with everything relating to GIT installed.
> The man pages reference commands like, "git-ls-tree --name-only" except
> that there isn't any such command. Unless you reverse engineer the
> implementation of "git", discover the /usr/lib/git directory and add it
> to your path. That hassle is rather inconvenient. More hints about
> where the git commands get squirreled away would be useful. Thank
> you.
Just type "git ls-tree --name-only". git-ls-tree is the old way to
refer to the command name. Normally, any reference to dashed names
should have been removed from the documentation by now (so most likely
you see it in your distro because it's an old enough version,
otherwise, it's a bug in the doc).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Documentation problems
From: Bruce Korb @ 2009-09-20 18:37 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqvdjdzd6x.fsf@bauges.imag.fr>
Hi Matthieu,
>> I'm trying to figure out what a ``tree-ish''.
>> I need a translation. :( Thank you. Regards, Bruce
>
> tree = directory (with its content).
>
> For example, the last commit in the current branch is a Git object of
> type "commit", which contains mostly a log message, a few headers, and
> a pointer to the tree object corresponding to the content of the
> directory in which you made the commit (modulo what you excluded from
> the commit of course). Therefore, the name of this commit, although
> not really a tree, is a tree-ish in that it talks about one and only
> one tree. You could name it HEAD, a sha1sum (like
> 5a2abc12d64a5e00daa6aebbb673715f365a564a), the name of the branch
> (like "master"), ...
Since I haven't created any any branches (to my knowledge), it seems
that "master" is the magic branch name. My goal was just to get a
list of managed files. Is "master" going to remain my "HEAD" now?
(Assuming I don't do something to make a new branch. One branch
is enough for my little one person project....)
> Just type "git ls-tree --name-only".
Ah. Thank you.
> git-ls-tree is the old way to
> refer to the command name. Normally, any reference to dashed names
> should have been removed from the documentation by now (so most likely
> you see it in your distro because it's an old enough version,
> otherwise, it's a bug in the doc).
$ git --version
git version 1.6.0.2
I guess the man pages and installation were out of sync for that release.
Thank you for the quick reply! Regards, Bruce
^ permalink raw reply
* Re: Documentation problems
From: Matthieu Moy @ 2009-09-20 18:45 UTC (permalink / raw)
To: Bruce Korb; +Cc: git
In-Reply-To: <4AB67665.10402@gmail.com>
Bruce Korb <bruce.korb@gmail.com> writes:
> Since I haven't created any any branches (to my knowledge), it seems
> that "master" is the magic branch name.
I wouldn't say "magic", but surely the default ;-).
> My goal was just to get a list of managed files.
Just cd /where/your/repo/is
git ls-files
> Is "master" going to remain my "HEAD" now?
Yes.
>> git-ls-tree is the old way to
>> refer to the command name. Normally, any reference to dashed names
>> should have been removed from the documentation by now (so most likely
>> you see it in your distro because it's an old enough version,
>> otherwise, it's a bug in the doc).
>
> $ git --version
> git version 1.6.0.2
>
> I guess the man pages and installation were out of sync for that release.
Well, actually, a few more instances of dashed commands were removed
more recently. That said, to get the doc for "git foo", you still have
to type "man git-foo" (or git foo --help indeed), but that's because
"man git foo" means something different to man.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Next problem... (thank you in advance :)
From: Bruce Korb @ 2009-09-20 18:53 UTC (permalink / raw)
To: git
$ git push
fatal: The remote end hung up unexpectedly
Trying to push to Source Forge:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git://autogen.git.sourceforge.net/gitroot/autogen/autogen
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
I did a fresh clone just to be certain that the .git/config file was
formatted correctly. Still "hangs up". What is this trying to
tell me? Thanks again - Bruce
^ permalink raw reply
* Re: Usability question
From: Dmitry Potapov @ 2009-09-20 18:54 UTC (permalink / raw)
To: Rob Barrett; +Cc: Matthieu Moy, git
In-Reply-To: <513ca40e0909191921k1b7b14b5j7cfd8734441397d9@mail.gmail.com>
On Sun, Sep 20, 2009 at 12:21:38PM +1000, Rob Barrett wrote:
> On Thu, Sep 17, 2009 at 8:41 PM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
> > Well, if you want to get rid of subcommands, why not get rid of
> > commands, too?
> >
> > git --commit
> > git --status
> > git --svn --rebase
> >
>
> Well, granted, that's a sort of heavyweight consistency, but all we
> should need to do is to help reduce a _new_ user's confusion about
> when the word after a subcommand gets a '--' prefix and when it
> doesn't.
>
> And do it in a way that's backwards compatible so it doesn't affect
> the usage patterns of seasoned users, existing scripts, crons etc.
>
> Will patch and see how it looks..
It will be horrible broken... Do you realize that there is a bigger
difference between commands and options than just that commands are
written without a '--' prefix? Take a look at the following commands:
$ git -p log
$ git log -p
There are completely difference because in the former case the -p
option modifies 'git' behavior while in the later case 'git log'.
If you change commands to options, you are going to break everything.
Dmitry
^ permalink raw reply
* Re: Next problem... (thank you in advance :)
From: Matthieu Moy @ 2009-09-20 19:03 UTC (permalink / raw)
To: Bruce Korb; +Cc: git
In-Reply-To: <4AB67A22.4010004@gmail.com>
Bruce Korb <bruce.korb@gmail.com> writes:
> $ git push
> fatal: The remote end hung up unexpectedly
>
> Trying to push to Source Forge:
http://www.google.com/search?q=sourceforge+git+push
For me, the answer is in the first link, near "read-only", and even
closer to "read/write" ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] Remove '< >' from [<options>] since it's not necessary.
From: Thiago Farina @ 2009-09-20 19:48 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
builtin-log.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
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,
--
1.6.5.rc1.37.gf5c31.dirty
^ permalink raw reply related
* Re: [PATCH] Remove '< >' from [<options>] since it's not necessary.
From: tom fogal @ 2009-09-20 20:52 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
In-Reply-To: <1253476116-24284-1-git-send-email-tfransosi@gmail.com>
Thiago Farina <tfransosi@gmail.com> writes:
> - "git log [<options>] [<since>..<until>] [[--] <path>...]\n"
> + "git log [options] [<since>..<until>] [[--] <path>...]\n"
> " or: git show [options] <object>...";
To me, "<blah>" implies to me that the other meant, "something which
is sort-of `blah'-ish but is not actually the string literal, `blah'",
whereas `blah' means, "the string literal, `blah'."
-tom
^ permalink raw reply
* Re: Documentation problems
From: Andreas Schwab @ 2009-09-20 20:52 UTC (permalink / raw)
To: Bruce Korb; +Cc: git
In-Reply-To: <4AB66D4C.70301@gmail.com>
Bruce Korb <bruce.korb@gmail.com> writes:
> I'm trying to figure out what a ``tree-ish''.
> I cannot seem to use many of the commands until I know.
>
> <tree-ish>
> Indicates a tree, commit or tag object name. A command that takes a
> <tree-ish> argument ultimately wants to operate on a <tree> object
> but automatically dereferences <commit> and <tag> objects that point at a <tree>.
>
> I need a translation. :( Thank you. Regards, Bruce
See gitglossary(7).
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] Remove '< >' from [<options>] since it's not necessary.
From: tom fogal @ 2009-09-20 21:12 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
In-Reply-To: <auto-000020523806@sci.utah.edu>
tom fogal <tfogal@alumni.unh.edu> writes:
> Thiago Farina <tfransosi@gmail.com> writes:
> > - "git log [<options>] [<since>..<until>] [[--] <path>...]\n"
> > + "git log [options] [<since>..<until>] [[--] <path>...]\n"
> > " or: git show [options] <object>...";
>
> To me, "<blah>" implies to me that the other meant, "something which
^^^^^
... author. sorry.
-tom
^ permalink raw reply
* Re: [PATCH] Trivial fix: Display a more friendly message with git-shell.
From: Tay Ray Chuan @ 2009-09-21 4:21 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <1253466672-21051-1-git-send-email-tfransosi@gmail.com>
Hi,
On Mon, Sep 21, 2009 at 1:11 AM, Thiago Farina <tfransosi@gmail.com> wrote:
> Instead of simply die without give a helpful message, displays the usage
s/give/giving/.
Not sure if the same should be done for die (like die()'ing).
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] Trivial fix: Display a more friendly message with git-shell.
From: Johannes Sixt @ 2009-09-21 6:17 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <1253466672-21051-1-git-send-email-tfransosi@gmail.com>
Thiago Farina schrieb:
> +static const char shell_usage[] = "git shell -c <command> <argument>";
> +
> static int do_generic_cmd(const char *me, char *arg)
> {
> const char *my_argv[4];
> @@ -74,7 +76,7 @@ int main(int argc, char **argv)
> * where "cmd" is a very limited subset of git commands.
> */
> else if (argc != 3 || strcmp(argv[1], "-c"))
> - die("What do you think I am? A shell?");
> + usage(shell_usage);
I don't think this is an improvement.
git-shell has a very limited use: It is to be used as the login-shell of
accounts where the admin will allow ssh access, but only to git repositories.
Every other use of git-shell is an error, and the current error message
says exactly that, although in a very 31337 way (and, BTW, /me likes it :-)
If an naive user runs git-shell from the command line, then your new
message will not be helpful because git-shell will accept only a very
restricted set of commands.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Trivial fix: Display a more friendly message with git-shell.
From: Matthieu Moy @ 2009-09-21 6:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Thiago Farina, git
In-Reply-To: <4AB71A76.5010509@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Every other use of git-shell is an error, and the current error message
> says exactly that, although in a very 31337 way (and, BTW, /me likes
> it :-)
Well, it's funny, but for a newcommer, trying "git shell" hoping to
get, for example what "bzr shell" gives (an interactive shell with
normal shell commands plus bzr ones without the 'bzr' prefix), it's
quite frustrating to be almost insulted by the tool for being curious.
> If an naive user runs git-shell from the command line, then your new
> message will not be helpful because git-shell will accept only a very
> restricted set of commands.
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: ...
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Remove '< >' from [<options>] since it's not necessary.
From: Matthieu Moy @ 2009-09-21 6:50 UTC (permalink / raw)
To: tom fogal; +Cc: git, Thiago Farina
In-Reply-To: <auto-000020523806@sci.utah.edu>
tom fogal <tfogal@alumni.unh.edu> writes:
> Thiago Farina <tfransosi@gmail.com> writes:
>> - "git log [<options>] [<since>..<until>] [[--] <path>...]\n"
>> + "git log [options] [<since>..<until>] [[--] <path>...]\n"
>> " or: git show [options] <object>...";
>
> To me, "<blah>" implies to me that the author meant, "something which
> is sort-of `blah'-ish but is not actually the string literal, `blah'",
> whereas `blah' means, "the string literal, `blah'."
Strictly speaking, you're right, but in the particular case of
[options], it's rather well established that it means "one or several
options", and not the litteral "option". In any case, we should be
consistant:
Documentation$ grep -n '\[<options>\]' *.txt
git-log.txt:11:'git log' [<options>] [<since>..<until>] [[\--] <path>...]
git-stash.txt:11:'git stash' list [<options>]
git-stash.txt:67:list [<options>]::
Documentation$ grep -n '\[options\]' *.txt
git-annotate.txt:10:'git annotate' [options] file [revision]
gitcli.txt:84:usage: git-describe [options] <committish>*
git-cvsserver.txt:25:'git cvsserver' [options] [pserver|server] [<directory> ...]
git-fast-export.txt:11:'git fast-export [options]' | 'git fast-import'
git-fast-import.txt:11:frontend | 'git fast-import' [options]
git-rebase.txt:11:'git rebase' [-i | --interactive] [options] [--onto <newbase>]
git-rebase.txt:13:'git rebase' [-i | --interactive] [options] --onto <newbase>
git-rev-parse.txt:405:some-command [options] <args>...
git-send-email.txt:11:'git send-email' [options] <file|directory|rev-list options>...
git-show.txt:11:'git show' [options] <object>...
git-svn.txt:10:'git svn' <command> [options] [arguments]
=> either get rid of the 3 occurences of [<options>], not just one, or
get rid of all the [options]. My vote goes for the first.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] test-genrandom: ensure stdout is set to _O_BINARY on Windows
From: Johannes Sixt @ 2009-09-21 7:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marius Storm-Olsen, Git Mailing List, Li Frank, msysGit
From: Johannes Sixt <j6t@kdbg.org>
Commit a6ca8c62 (Set _O_BINARY as default fmode for both MinGW and MSVC)
removed the definition of _CRT_fmode from mingw.c. Before this commit,
since test-genrandom is linked against libgit.a, the MinGW process
initialization code would pick up that definition of _CRT_fmode, which was
initialized to _O_BINARY. After this commit, however, text mode is used
for std(in|out|err) because it is the default in absence of _CRT_fmode.
In order to fix that, we must use git-compat-util.h, which overrides
main() to set the mode to binary.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Unfortunately, this change in an updated patch 04/15 of the MSVC series
went to the Big Void. ;)
-- Hannes
test-genrandom.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/test-genrandom.c b/test-genrandom.c
index 8ad276d..b3c28d9 100644
--- a/test-genrandom.c
+++ b/test-genrandom.c
@@ -4,8 +4,7 @@
* Copyright (C) 2007 by Nicolas Pitre, licensed under the GPL version 2.
*/
-#include <stdio.h>
-#include <stdlib.h>
+#include "git-compat-util.h"
int main(int argc, char *argv[])
{
--
1.6.5.rc1.1051.gdc4fd
^ permalink raw reply related
* Re: [PATCH] test-genrandom: ensure stdout is set to _O_BINARY on Windows
From: Junio C Hamano @ 2009-09-21 7:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Marius Storm-Olsen, Git Mailing List, Li Frank, msysGit
In-Reply-To: <4AB72CA2.1020808@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> From: Johannes Sixt <j6t@kdbg.org>
>
> Commit a6ca8c62 (Set _O_BINARY as default fmode for both MinGW and MSVC)
> removed the definition of _CRT_fmode from mingw.c. Before this commit,
> since test-genrandom is linked against libgit.a, the MinGW process
> initialization code would pick up that definition of _CRT_fmode, which was
> initialized to _O_BINARY. After this commit, however, text mode is used
> for std(in|out|err) because it is the default in absence of _CRT_fmode.
> In order to fix that, we must use git-compat-util.h, which overrides
> main() to set the mode to binary.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> Unfortunately, this change in an updated patch 04/15 of the MSVC series
> went to the Big Void. ;)
Thanks.
^ permalink raw reply
* error: insufficient permission
From: Dominic Rose @ 2009-09-21 8:32 UTC (permalink / raw)
To: git
Hi,
may please somebody help me with the following issue. I try to checkin
changes to a repository I created. Seems like I have some permission
problems, but I can't figure out whats going wrong:
$ git commit -m 'test'
Created commit 07b3a4a: test
1 files changed, 1 insertions(+), 1 deletions(-)
$ git push
Counting objects: 8, done.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.56 KiB, done.
Total 6 (delta 4), reused 0 (delta 0)
error: insufficient permission for adding an object to repository
database ./objects
fatal: failed to write object
error: unpack failed: unpacker exited with error code
To /homes/[...]
! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to '/homes/[...]'
Thanks,
Dominic
--
Dominic Rose
Professur für Bioinformatik
Institut für Informatik
Universität Leipzig
Härtelstr. 16-18
D-04107 Leipzig
WWW http://www.bioinf.uni-leipzig.de
Phone: +49 341 97-16698
Fax: +49 341 97-16679
^ permalink raw reply
* Re: error: insufficient permission
From: Johannes Sixt @ 2009-09-21 8:53 UTC (permalink / raw)
To: Dominic Rose; +Cc: git
In-Reply-To: <4AB73A07.3020703@bioinf.uni-leipzig.de>
Dominic Rose schrieb:
> error: insufficient permission for adding an object to repository
> database ./objects
>
> fatal: failed to write object
> error: unpack failed: unpacker exited with error code
> To /homes/[...]
> ! [remote rejected] master -> master (n/a (unpacker error))
> error: failed to push some refs to '/homes/[...]'
Make sure you have permission to create new files and directories in
/homes/[...]/objects and that you have permission to create new files in
all directories that are already in /homes/[...]/objects.
-- Hannes
^ permalink raw reply
* Re: error: insufficient permission
From: Luciano Rocha @ 2009-09-21 8:52 UTC (permalink / raw)
To: Dominic Rose; +Cc: git
In-Reply-To: <4AB73A07.3020703@bioinf.uni-leipzig.de>
[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]
On Mon, Sep 21, 2009 at 10:32:07AM +0200, Dominic Rose wrote:
> Hi,
>
> may please somebody help me with the following issue. I try to
> checkin changes to a repository I created. Seems like I have some
> permission problems, but I can't figure out whats going wrong:
>
> $ git commit -m 'test'
> Created commit 07b3a4a: test
> 1 files changed, 1 insertions(+), 1 deletions(-)
> $ git push
> Counting objects: 8, done.
> Compressing objects: 100% (6/6), done.
> Writing objects: 100% (6/6), 1.56 KiB, done.
> Total 6 (delta 4), reused 0 (delta 0)
> error: insufficient permission for adding an object to repository
> database ./objects
>
> fatal: failed to write object
> error: unpack failed: unpacker exited with error code
> To /homes/[...]
> ! [remote rejected] master -> master (n/a (unpacker error))
> error: failed to push some refs to '/homes/[...]'
That's a filesystem permissions problem on the server side. You'll have
to check if your user has permissions to write to the objects subdir of the
repository.
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] pre-commit.sample: don't use [...] around a tr range
From: Jim Meyering @ 2009-09-21 9:09 UTC (permalink / raw)
To: git list
Using square brackets in tr ranges is risky.
From the documentation of GNU tr:
Ranges
The notation `M-N' expands to all of the characters from M through
N, in ascending order. M should collate before N; if it doesn't,
an error results. As an example, `0-9' is the same as
`0123456789'.
GNU `tr' does not support the System V syntax that uses square
brackets to enclose ranges. Translations specified in that format
sometimes work as expected, since the brackets are often
transliterated to themselves. However, they should be avoided
because they sometimes behave unexpectedly. For example, `tr -d
'[0-9]'' deletes brackets as well as digits.
However, if the use of [] is deliberate, because git still
cares about portability to ancient SYSV versions of tr that
require that notation, then let me know and I'll undo that part
of the change and add a comment to that effect.
>From cd3c17c6a48c67d2a598001272f3283714b1df19 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Mon, 21 Sep 2009 10:58:02 +0200
Subject: [PATCH] pre-commit.sample: don't use [...] around a tr range
Using square brackets around a tr range is especially risky when using
tr's -d (delete) option. In this case, the brackets happen to be harmless,
since the two bracket bytes happen to be included in the desired range.
Correct spelling and grammar.
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
templates/hooks--pre-commit.sample | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/templates/hooks--pre-commit.sample b/templates/hooks--pre-commit.sample
index b11ad6a..06a5afa 100755
--- a/templates/hooks--pre-commit.sample
+++ b/templates/hooks--pre-commit.sample
@@ -15,14 +15,14 @@ allownonascii=$(git config hooks.allownonascii)
# printable range starts at the space character and ends with tilde.
if [ "$allownonascii" != "true" ] &&
test "$(git diff --cached --name-only --diff-filter=A -z |
- LC_ALL=C tr -d '[ -~]\0')"
+ LC_ALL=C tr -d ' -~\0')"
then
- echo "Error: Attempt to add a non-ascii filename."
+ echo "Error: Attempt to add a non-ascii file name."
echo
- echo "This can cause problems if you want to work together"
- echo "with people on other platforms than you."
+ echo "This can cause problems if you want to work"
+ echo "with people on other platforms."
echo
- echo "To be portable it is adviseable to rename the file ..."
+ echo "To be portable it is advisable to rename the file ..."
echo
echo "If you know what you are doing you can disable this"
echo "check using:"
--
1.6.5.rc1.214.g13c5a
^ permalink raw reply related
* Re: [PATCH] pre-commit.sample: don't use [...] around a tr range
From: Alex Riesen @ 2009-09-21 9:43 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list
In-Reply-To: <871vm0k6jm.fsf@meyering.net>
On Mon, Sep 21, 2009 at 11:09, Jim Meyering <jim@meyering.net> wrote:
> However, if the use of [] is deliberate, because git still
> cares about portability to ancient SYSV versions of tr that
> require that notation, then let me know and I'll undo that part
> of the change and add a comment to that effect.
We have (had?) people trying to support Git on HP-UX and SunOS.
Do these count?
^ 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