* Re: [PATCH] git-receive-pack needs to set umask(2)
From: Johannes Schindelin @ 2006-05-29 7:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e5d6i0$rnf$1@sea.gmane.org>
Hi,
On Mon, 29 May 2006, Jakub Narebski wrote:
> Michael Richardson wrote:
>
> > This change adds $GIT_DIR/umask to contain a single line, an integer
> > which will be fed to umask(). This should also work for the git daemon,
> > which I personally do not use, so this may be inappropriate.
>
> Shouldn't it be done rather via $GIT_DIR/config file, and
> git-repo-config? I.e. instead of adding new file to repository layout,
> $GIT_DIR/umask, add core.umask to git configuration?
See also
http://thread.gmane.org/gmane.comp.version-control.git/13856/focus=13876
The essence of the thread: If you want to do anything useful in a non-bare
repository, you are likely using other tools than git, which do not
interpret core.umask or $GIT_DIR/umask.
If you use a bare repository, just make it shared. No need for an umask.
Hth,
Dscho
^ permalink raw reply
* [PATCH] Make update-ref a builtin.
From: Shawn Pearce @ 2006-05-29 7:15 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This is applied on top of `next` and my other reflog changes.
I put it together just to reduce the disk usage - as Linus noted
PowerPC ain't too slim on its executables...
Makefile | 6 +++---
update-ref.c => builtin-update-ref.c | 9 +++++----
builtin.h | 1 +
git.c | 1 +
4 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index 5f8ea18..7dfeb97 100644
--- a/Makefile
+++ b/Makefile
@@ -161,7 +161,7 @@ PROGRAMS = \
git-ssh-upload$X git-unpack-file$X \
git-unpack-objects$X git-update-index$X git-update-server-info$X \
git-upload-pack$X git-verify-pack$X git-write-tree$X \
- git-update-ref$X git-symbolic-ref$X \
+ git-symbolic-ref$X \
git-name-rev$X git-pack-redundant$X git-repo-config$X git-var$X \
git-describe$X git-merge-tree$X git-blame$X git-imap-send$X
@@ -172,7 +172,7 @@ BUILT_INS = git-log$X git-whatchanged$X
git-init-db$X git-tar-tree$X git-upload-tar$X git-format-patch$X \
git-ls-files$X git-ls-tree$X \
git-read-tree$X git-commit-tree$X \
- git-apply$X git-show-branch$X git-diff-files$X \
+ git-update-ref$X git-apply$X git-show-branch$X git-diff-files$X \
git-diff-index$X git-diff-stages$X git-diff-tree$X git-cat-file$X
# what 'all' will build and 'install' will install, in gitexecdir
@@ -228,7 +228,7 @@ BUILTIN_OBJS = \
builtin-read-tree.o builtin-commit-tree.o \
builtin-apply.o builtin-show-branch.o builtin-diff-files.o \
builtin-diff-index.o builtin-diff-stages.o builtin-diff-tree.o \
- builtin-cat-file.o
+ builtin-update-ref.o builtin-cat-file.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
diff --git a/update-ref.c b/builtin-update-ref.c
similarity index 85%
rename from update-ref.c
rename to builtin-update-ref.c
index a1e6bb9..2c62286 100644
--- a/update-ref.c
+++ b/builtin-update-ref.c
@@ -1,10 +1,11 @@
#include "cache.h"
#include "refs.h"
+#include "builtin.h"
-static const char git_update_ref_usage[] =
+static const char builtin_update_ref_usage[] =
"git-update-ref <refname> <value> [<oldval>] [-m <reason>]";
-int main(int argc, char **argv)
+int cmd_update_ref(int argc, const char **argv, char **envp)
{
const char *refname=NULL, *value=NULL, *oldval=NULL, *msg=NULL;
struct ref_lock *lock;
@@ -17,7 +18,7 @@ int main(int argc, char **argv)
for (i = 1; i < argc; i++) {
if (!strcmp("-m", argv[i])) {
if (i+1 >= argc)
- usage(git_update_ref_usage);
+ usage(builtin_update_ref_usage);
msg = argv[++i];
if (!*msg)
die("Refusing to perform update with empty message.");
@@ -39,7 +40,7 @@ int main(int argc, char **argv)
}
}
if (!refname || !value)
- usage(git_update_ref_usage);
+ usage(builtin_update_ref_usage);
if (get_sha1(value, sha1))
die("%s: not a valid SHA1", value);
diff --git a/builtin.h b/builtin.h
index 738ec3d..397b770 100644
--- a/builtin.h
+++ b/builtin.h
@@ -28,6 +28,7 @@ extern int cmd_grep(int argc, const char
extern int cmd_rm(int argc, const char **argv, char **envp);
extern int cmd_add(int argc, const char **argv, char **envp);
extern int cmd_rev_list(int argc, const char **argv, char **envp);
+extern int cmd_update_ref(int argc, const char **argv, char **envp);
extern int cmd_check_ref_format(int argc, const char **argv, char **envp);
extern int cmd_init_db(int argc, const char **argv, char **envp);
extern int cmd_tar_tree(int argc, const char **argv, char **envp);
diff --git a/git.c b/git.c
index 10ea934..f37b020 100644
--- a/git.c
+++ b/git.c
@@ -57,6 +57,7 @@ static void handle_internal_command(int
{ "init-db", cmd_init_db },
{ "tar-tree", cmd_tar_tree },
{ "upload-tar", cmd_upload_tar },
+ { "update-ref", cmd_update_ref },
{ "check-ref-format", cmd_check_ref_format },
{ "ls-files", cmd_ls_files },
{ "ls-tree", cmd_ls_tree },
--
1.3.3.g45d8
^ permalink raw reply related
* [PATCH] Remove unnecessary ouput from t3600-rm.
From: Shawn Pearce @ 2006-05-29 7:16 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Moved the output of the setup commits and the test-file rm check to
file descriptors 3 and 4 hiding their messages unless -v is given.
This makes the test suite look a little cleaner when the rm test-file
setup step fails (and was probably expected to fail).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
t/t3600-rm.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index acaa4d6..5b6bf61 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -10,14 +10,14 @@ test_description='Test of the various op
# Setup some files to be removed, some with funny characters
touch -- foo bar baz 'space embedded' -q
git-add -- foo bar baz 'space embedded' -q
-git-commit -m "add normal files"
+git-commit -m "add normal files" >&3 2>&4
test_tabs=y
if touch -- 'tab embedded' 'newline
embedded'
then
git-add -- 'tab embedded' 'newline
embedded'
-git-commit -m "add files with tabs and newlines"
+git-commit -m "add files with tabs and newlines" >&3 2>&4
else
say 'Your filesystem does not allow tabs in filenames.'
test_tabs=n
@@ -28,7 +28,7 @@ # git-rm barfs, but if the test is run a
# arranged.
: >test-file
chmod a-w .
-rm -f test-file
+rm -f test-file >&3 2>&4
test -f test-file && test_failed_remove=y
chmod 775 .
rm -f test-file
--
1.3.3.g45d8
^ permalink raw reply related
* [PATCH] Improved pack format documentation.
From: Shawn Pearce @ 2006-05-29 7:17 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
While trying to implement a pack reader in Java I was mislead by
some facts listed in this documentation as well as found a few
details to be missing about the pack header.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/technical/pack-format.txt | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt
index ed2decc..0e1ffb2 100644
--- a/Documentation/technical/pack-format.txt
+++ b/Documentation/technical/pack-format.txt
@@ -5,8 +5,13 @@ GIT pack format
- The header appears at the beginning and consists of the following:
- 4-byte signature
- 4-byte version number (network byte order)
+ 4-byte signature:
+ The signature is: {'P', 'A', 'C', 'K'}
+
+ 4-byte version number (network byte order):
+ GIT currently accepts version number 2 or 3 but
+ generates version 2 only.
+
4-byte number of objects contained in the pack (network byte order)
Observation: we cannot have more than 4G versions ;-) and
@@ -41,7 +46,7 @@ GIT pack format
8-byte integers to go beyond 4G objects per pack, but it is
not strictly necessary.
- - The header is followed by sorted 28-byte entries, one entry
+ - The header is followed by sorted 24-byte entries, one entry
per object in the pack. Each entry is:
4-byte network byte order integer, recording where the
--
1.3.3.g45d8
^ permalink raw reply related
* Re: [PATCH] Read configuration also from ~/.gitrc
From: Johannes Schindelin @ 2006-05-29 7:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: Anand Kumria, git
In-Reply-To: <20060528222641.GF10488@pasky.or.cz>
Hi,
On Mon, 29 May 2006, Petr Baudis wrote:
> diff --git a/config.c b/config.c
> index 0248c6d..8a98865 100644
> --- a/config.c
> +++ b/config.c
> @@ -312,7 +312,11 @@ int git_config_from_file(config_fn_t fn,
>
> int git_config(config_fn_t fn)
> {
> - return git_config_from_file(fn, git_path("config"));
> + int ret = 0;
> + if (getenv("HOME"))
> + ret += git_config_from_file(fn, mkpath("%s/.gitrc", getenv("HOME")));
> + ret += git_config_from_file(fn, git_path("config"));
> + return ret;
> }
>
> /*
But would this not break for the normal case? If you override one key in
the repository's config, with this patch, repo-config will barf. The
normal case is that you do not expect multiple values for the same key.
Your patch reads both ~/.gitrc and $GIT_DIR/config, and if a key has a
value in both (even if they are identical), repo-config will error out.
Further, storing a key will no longer work. This is an obscure side
effect of this patch not caring about storing anything in ~/.gitrc: If you
find the key section (or the key) in ~/.gitrc, the offset will be stored,
_and used on $GIT_DIR/config_!
I agree it is nice to have a global git configuration, but I have it: I
use templates.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Remove unnecessary ouput from t3600-rm.
From: Junio C Hamano @ 2006-05-29 7:27 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060529071646.GC6061@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Moved the output of the setup commits and the test-file rm check to
> file descriptors 3 and 4 hiding their messages unless -v is given.
> This makes the test suite look a little cleaner when the rm test-file
> setup step fails (and was probably expected to fail).
I suspect those bare commands _should_ succeed so make them a
separate test step and verify their success return while you are
at it, and their output would not be shown normally, without
your futzing with file descriptors. Wouldn't that be a lot
cleaner approach?
^ permalink raw reply
* Re: [PATCH 3/4] t5500-fetch-pack: remove local (bashism) usage.
From: Herbert Xu @ 2006-05-29 7:31 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20060529052828.GB24077@localdomain>
On Sun, May 28, 2006 at 10:28:28PM -0700, Eric Wong wrote:
>
> Cool. Hmm... pdksh seems to support it here (Debian sid). I'm pretty
> sure local is not part of the POSIX spec, though; and I have seen
> /bin/sh that don't support it.
It is true that the current POSIX spec does not specify it. However,
all useful POSIX-compliant shells on Linux (i.e., excluding those
shells that exist only to test POSIX compliance) support it and it
is used by a large corpus of existing Linux scripts.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] Support for configurable git command aliases
From: Petr Baudis @ 2006-05-29 8:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j45d1wz.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, May 29, 2006 at 04:01:48AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@ucw.cz> writes:
>
> >> I don't like this syntax. What other stuff (beside "cmd") would be under
> >> "[alias "co"]? Why not simply:
> >>
> >> [alias]
> >> co = commit -a
> >> publish = push public.site.com:/pub/scm/my-public-repo
> >
> > Nice, I like this.
>
> Sorry, I don't. The left hand side of '=' does not allow
> anything but alnum and squashes the case.
Does that really matter that much? Perhaps we might support something
like
"!ooOk" = commit -a
(and it will probably not do what the user expects if he sticks
whitespaces in).
> Please stick to [alias "co"] syntax.
That sucks, e.g. because it's alias-specific, and it's inconsistent.
I can't have anything like "cgalias" then.
Let's make some effort to keep the syntax clean...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [PATCH] Remove unnecessary ouput from t3600-rm.
From: Shawn Pearce @ 2006-05-29 8:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wud9tq0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Moved the output of the setup commits and the test-file rm check to
> > file descriptors 3 and 4 hiding their messages unless -v is given.
> > This makes the test suite look a little cleaner when the rm test-file
> > setup step fails (and was probably expected to fail).
>
> I suspect those bare commands _should_ succeed so make them a
> separate test step and verify their success return while you are
> at it, and their output would not be shown normally, without
> your futzing with file descriptors. Wouldn't that be a lot
> cleaner approach?
Yes. :-)
--> -
Remove unnecessary output from t3600-rm.
Moved the setup commands into test_expect_success blocks so their
output is hidden unless -v is used. This makes the test suite look
a little cleaner when the rm test-file setup step fails (and was
expected to fail for most cases).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
t/t3600-rm.sh | 42 +++++++++++++++++++++++-------------------
1 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index acaa4d6..201d164 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -8,30 +8,34 @@ test_description='Test of the various op
. ./test-lib.sh
# Setup some files to be removed, some with funny characters
-touch -- foo bar baz 'space embedded' -q
-git-add -- foo bar baz 'space embedded' -q
-git-commit -m "add normal files"
-test_tabs=y
-if touch -- 'tab embedded' 'newline
-embedded'
-then
-git-add -- 'tab embedded' 'newline
+test_expect_success \
+ 'Initialize test directory' \
+ "touch -- foo bar baz 'space embedded' -q &&
+ git-add -- foo bar baz 'space embedded' -q &&
+ git-commit -m 'add normal files' &&
+ test_tabs=y &&
+ if touch -- 'tab embedded' 'newline
embedded'
-git-commit -m "add files with tabs and newlines"
-else
- say 'Your filesystem does not allow tabs in filenames.'
- test_tabs=n
-fi
+ then
+ git-add -- 'tab embedded' 'newline
+embedded' &&
+ git-commit -m 'add files with tabs and newlines'
+ else
+ say 'Your filesystem does not allow tabs in filenames.'
+ test_tabs=n
+ fi"
# Later we will try removing an unremovable path to make sure
# git-rm barfs, but if the test is run as root that cannot be
# arranged.
-: >test-file
-chmod a-w .
-rm -f test-file
-test -f test-file && test_failed_remove=y
-chmod 775 .
-rm -f test-file
+test_expect_success \
+ 'Determine rm behavior' \
+ ': >test-file
+ chmod a-w .
+ rm -f test-file
+ test -f test-file && test_failed_remove=y
+ chmod 775 .
+ rm -f test-file'
test_expect_success \
'Pre-check that foo exists and is in index before git-rm foo' \
--
1.3.3.g45d8
^ permalink raw reply related
* [PATCH] Allow multiple -m options to git-commit.
From: Shawn Pearce @ 2006-05-29 8:45 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
I find it very convenient to be able to supply multiple paragraphs
of text on the command line with a single git-commit call. This
change permits multiple -m/--message type options to be supplied
to git-commit with each message being added as its own paragraph
of text in the commit message.
The -m option is still not permitted with -c/-C/-F nor are multiple
occurrences of these options permitted.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-commit.sh | 37 ++++++++++++++++++++++++++++++-------
1 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 0a01a0b..a092b72 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -260,20 +260,41 @@ do
-m|--m|--me|--mes|--mess|--messa|--messag|--message)
case "$#" in 1) usage ;; esac
shift
- log_given=t$log_given
- log_message="$1"
+ log_given=m$log_given
+ if test "$log_message" = ''
+ then
+ log_message="$1"
+ else
+ log_message="$log_message
+
+$1"
+ fi
no_edit=t
shift
;;
-m*)
- log_given=t$log_given
- log_message=`expr "$1" : '-m\(.*\)'`
+ log_given=m$log_given
+ if test "$log_message" = ''
+ then
+ log_message=`expr "$1" : '-m\(.*\)'`
+ else
+ log_message="$log_message
+
+`expr "$1" : '-m\(.*\)'`"
+ fi
no_edit=t
shift
;;
--m=*|--me=*|--mes=*|--mess=*|--messa=*|--messag=*|--message=*)
- log_given=t$log_given
- log_message=`expr "$1" : '-[^=]*=\(.*\)'`
+ log_given=m$log_given
+ if test "$log_message" = ''
+ then
+ log_message=`expr "$1" : '-[^=]*=\(.*\)'`
+ else
+ log_message="$log_message
+
+`expr "$1" : '-[^=]*=\(.*\)'`"
+ fi
no_edit=t
shift
;;
@@ -378,7 +399,9 @@ esac
case "$log_given" in
tt*)
- die "Only one of -c/-C/-F/-m can be used." ;;
+ die "Only one of -c/-C/-F can be used." ;;
+*tm*|*mt*)
+ die "Option -m cannot be combined with -c/-C/-F." ;;
esac
case "$#,$also,$only,$amend" in
--
1.3.3.g45d8
^ permalink raw reply related
* [PATCH] Automatically line wrap long commit messages.
From: Shawn Pearce @ 2006-05-29 8:57 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
When using -m on the command line with git-commit it is not uncommon
for a long commit message to be entered without line terminators.
This creates commit objects whose messages are not readable in
'git log' as the line runs off the screen.
So instead reformat log messages if they are supplied on the
command line.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This one might cause some problems for people. It requires
'fmt' in order to use log messages on the command line as well as
some users may not like having their log messages line wrapped.
I'm open to suggestions for how to deal with this but personally
this is one feature which I put into pg's commit tool that I miss
dearly when working with core GIT.
git-commit.sh | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index a092b72..e7aa4b1 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -547,7 +547,12 @@ fi
if test "$log_message" != ''
then
- echo "$log_message"
+ # The message came from the command line. It might contain very
+ # long lines so reformat it with a target of 60. Note that we
+ # don't reformat messages created in an editor by the user as
+ # we should assume they carefully formatted it in some way.
+ #
+ echo "$log_message" | fmt -w 60
elif test "$logfile" != ""
then
if test "$logfile" = -
--
1.3.3.g45d8
^ permalink raw reply related
* Re: [PATCH] Automatically line wrap long commit messages.
From: Jan-Benedict Glaw @ 2006-05-29 9:00 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio Hamano, git
In-Reply-To: <20060529085738.GB29500@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
On Mon, 2006-05-29 04:57:39 -0400, Shawn Pearce <spearce@spearce.org> wrote:
> When using -m on the command line with git-commit it is not uncommon
> for a long commit message to be entered without line terminators.
> This creates commit objects whose messages are not readable in
> 'git log' as the line runs off the screen.
Uh? Just put it in quotes and press the Enter key when applicable.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Automatically line wrap long commit messages.
From: Shawn Pearce @ 2006-05-29 9:14 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Junio Hamano, git
In-Reply-To: <20060529090045.GW13513@lug-owl.de>
Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> On Mon, 2006-05-29 04:57:39 -0400, Shawn Pearce <spearce@spearce.org> wrote:
> > When using -m on the command line with git-commit it is not uncommon
> > for a long commit message to be entered without line terminators.
> > This creates commit objects whose messages are not readable in
> > 'git log' as the line runs off the screen.
>
> Uh? Just put it in quotes and press the Enter key when applicable.
I realize that. But I feel that it looks rather ugly on the command
line, in the resulting message, and is difficult to do well all of
the time.
For one thing the first line is offset due to the stuff preeceding
it on the command line, even if you put the -m" on the next line.
For another it goes nicely with my prior patch of allowing multiple
-m flags on the command line and merging them into a single commit
message by treating each option argument as its own paragraph.
Maybe its just me but I've generally found `fmt` does a nice job
of line wrapping my text. I'm writing this email out in vi with
no thought to line wrapping and will let `fmt` clean it all up for
me before I sent it. I do the same thing with all of my commit
messages; except git-commit won't let me do it from the command line.
This patch was trying to do that... but I suspected some folks
would not like the idea very much. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Automatically line wrap long commit messages.
From: Junio C Hamano @ 2006-05-29 9:16 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060529085738.GB29500@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> When using -m on the command line with git-commit it is not uncommon
> for a long commit message to be entered without line terminators.
> This creates commit objects whose messages are not readable in
> 'git log' as the line runs off the screen.
>
> So instead reformat log messages if they are supplied on the
> command line.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> This one might cause some problems for people.
I am already moderately negative on multiple -m so in the light
of it this one looks totally unneeded. You could do a number of
things:
$ git commit -m 'This is my message.
This is the first line of the message body.'
$ cat >L <<EOF
This is my message.
This is the first line of the message body.'
EOF
$ git commit -F L
$ fmt <<EOF
This is my message.
This is the first line of the message body.'
EOF
$ git commit -F L
We probably should allow "commit -F -" to read from the standard
input if we already don't, but that is about as far as I am
willing to go at this moment.
^ permalink raw reply
* Re: [PATCH] Automatically line wrap long commit messages.
From: Shawn Pearce @ 2006-05-29 9:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virnp8a30.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > When using -m on the command line with git-commit it is not uncommon
> > for a long commit message to be entered without line terminators.
> > This creates commit objects whose messages are not readable in
> > 'git log' as the line runs off the screen.
> >
> > So instead reformat log messages if they are supplied on the
> > command line.
> >
> > Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> > ---
> > This one might cause some problems for people.
>
> I am already moderately negative on multiple -m so in the light
> of it this one looks totally unneeded. You could do a number of
> things:
[snip]
OK. Ignore both patches then. Two negative votes in such a short
time suggests they are probably not generally accepted. ;-)
> We probably should allow "commit -F -" to read from the standard
> input if we already don't, but that is about as far as I am
> willing to go at this moment.
We do. So apparently the solution to my usage issue is:
$ fmt -w 60 | git commit -F-
This is my message.
This is the body. Etc....
EOF
I'm thinking that's too much work for me. Which means either I
learn to format my messages better in a single -m switch (as was
already suggested) or I just deal with git-commit popping open
$EDITOR anytime I want to commit something. In which case then I
might as well also get a diff of what I am about to commit as part
of the temp file buffer.
Or I create my own little wrapper shell script which calls fmt.
Hmm, maybe that would be useful with alias and a promise to not
use ci as a core GIT command name:
[alias "ci"]
command=shawns-commit-wrapper
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-receive-pack needs to set umask(2)
From: Salikh Zakirov @ 2006-05-29 11:28 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0605290910210.8863@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> See also
>
> http://thread.gmane.org/gmane.comp.version-control.git/13856/focus=13876
I've read the thread, but couldn't find a practical solution there.
> The essence of the thread: If you want to do anything useful in a non-bare
> repository, you are likely using other tools than git, which do not
> interpret core.umask or $GIT_DIR/umask.
>
> If you use a bare repository, just make it shared. No need for an umask.
Could you please elaborate on what does it mean "make it shared"?
My setup: I have a bare GIT repository on a machine, where everybody can
SSH into (with full shell access). I've assigned the repo to a special group
where everybody belongs, and done a 'find repo.git -type d | xargs chmod 2775'
The problem: After someone pushed to the repository, the object directories
(i.e repo.git/objects/??)
get created with 755 access rights, and effectively prevent everyone else from pushing
objects starting with the same prefix.
The obvious solution to use umask 002 is not applicable, because
1) It does not seem practical to enforce umask 002 in everyone's rc files,
because just one forgetful or careless person can break access for all others
2) I have 'umask 002' in my ~/.profile. Somehow, it does not help,
because ~/.profile is not read on non-interactive SSH sessions
(to verify that, just try to do 'ssh somehost umask')
The current workaround for the problem is a cron script, which
makes 'find | xargs chmod 2775' every 5 minutes. It works, but is ugly.
Is there any better way to keep correct access rights in a shared repository?
Thanks a lot!
^ permalink raw reply
* Re: [PATCH] git-receive-pack needs to set umask(2)
From: Shawn Pearce @ 2006-05-29 11:33 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: git
In-Reply-To: <447ADAEF.3030806@Intel.com>
Salikh Zakirov <Salikh.Zakirov@Intel.com> wrote:
> Johannes Schindelin wrote:
> > See also
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/13856/focus=13876
>
> I've read the thread, but couldn't find a practical solution there.
>
> > The essence of the thread: If you want to do anything useful in a non-bare
> > repository, you are likely using other tools than git, which do not
> > interpret core.umask or $GIT_DIR/umask.
> >
> > If you use a bare repository, just make it shared. No need for an umask.
>
> Could you please elaborate on what does it mean "make it shared"?
>
> My setup: I have a bare GIT repository on a machine, where everybody can
> SSH into (with full shell access). I've assigned the repo to a special group
> where everybody belongs, and done a 'find repo.git -type d | xargs chmod 2775'
>
> The problem: After someone pushed to the repository, the object directories
> (i.e repo.git/objects/??)
> get created with 755 access rights, and effectively prevent everyone else from pushing
> objects starting with the same prefix.
>
> The obvious solution to use umask 002 is not applicable, because
> 1) It does not seem practical to enforce umask 002 in everyone's rc files,
> because just one forgetful or careless person can break access for all others
> 2) I have 'umask 002' in my ~/.profile. Somehow, it does not help,
> because ~/.profile is not read on non-interactive SSH sessions
> (to verify that, just try to do 'ssh somehost umask')
>
> The current workaround for the problem is a cron script, which
> makes 'find | xargs chmod 2775' every 5 minutes. It works, but is ugly.
>
> Is there any better way to keep correct access rights in a shared repository?
Try setting 'core.sharedRepository' to true:
git repo-config core.sharedRepository true
and running your chmod script one last time. See
Documentation/config.txt for some details on this switch.
--
Shawn.
^ permalink raw reply
* RE: [PATCH] git-receive-pack needs to set umask(2)
From: Zakirov, Salikh @ 2006-05-29 12:07 UTC (permalink / raw)
To: spearce; +Cc: git
Thanks a lot, that works!
Shawn wrote:
>
> > Could you please elaborate on what does it mean "make it shared"?
>
> Try setting 'core.sharedRepository' to true:
>
>
> git repo-config core.sharedRepository true
>
> and running your chmod script one last time. See
> Documentation/config.txt for some details on this switch.
^ permalink raw reply
* [PATCH] Make git-diff-tree indicate when it flushes
From: Paul Mackerras @ 2006-05-29 12:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
There are times when gitk needs to know that the commits it has sent
to git-diff-tree --stdin did not match, and it needs to know in a
timely fashion even if none of them match. At the moment,
git-diff-tree outputs nothing for non-matching commits, so it is
impossible for gitk to distinguish between git-diff-tree being slow
and git-diff-tree saying no.
This makes git-diff-tree output a blank line in response to a blank
line in its input (which already causes git-diff-tree to flush its
output buffers). Gitk, or other users of git-diff-tree --stdin, can
use the blank line to indicate that git-diff-tree has processed all
the commits on its input up to the input blank line, and any commits
that have not been output do not match.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/builtin-diff-tree.c b/builtin-diff-tree.c
index cc53b81..dbe5737 100644
--- a/builtin-diff-tree.c
+++ b/builtin-diff-tree.c
@@ -139,9 +139,10 @@ int cmd_diff_tree(int argc, const char *
opt->diffopt.setup |= (DIFF_SETUP_USE_SIZE_CACHE |
DIFF_SETUP_USE_CACHE);
while (fgets(line, sizeof(line), stdin))
- if (line[0] == '\n')
+ if (line[0] == '\n') {
+ putchar('\n');
fflush(stdout);
- else
+ } else
diff_tree_stdin(line);
return 0;
^ permalink raw reply related
* gitk highlighting descendents/ancestors
From: Paul Mackerras @ 2006-05-29 12:35 UTC (permalink / raw)
To: git
I have implemented a feature in gitk (on the "new" branch) where it
can highlight the commits that are, or are not, descendents or
ancestors of the selected commit. For now it is invoked via a
drop-down menu. Does this look useful to people?
At the moment, if you select "Not descendent" then the selected
commit and all the commits below it will be highlighted (since they
can't be descendents of the selected commit). Similarly if you select
"Not ancestor" then the selected commit and all commits above it are
highlighted. That's technically correct but doesn't seem very useful;
maybe I should suppress those highlights.
Also, whatever matches the string put in the "Find" field will be
highlighted. I have taken out the "Files" and "Pickaxe" options in
the Find function, and put the pickaxe function into a new drop-down
menu for the highlighting function. I have code ready to go for
shift-up and shift-down to move to the previous/next highlighted row,
once Junio applies my tiny patch to builtin-diff-tree.c.
Paul.
^ permalink raw reply
* Re: gitk highlighting descendents/ancestors
From: Matthias Kestenholz @ 2006-05-29 12:55 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17530.60026.636981.60532@cargo.ozlabs.ibm.com>
Hi,
* Paul Mackerras (paulus@samba.org) wrote:
> I have implemented a feature in gitk (on the "new" branch) where it
> can highlight the commits that are, or are not, descendents or
> ancestors of the selected commit. For now it is invoked via a
> drop-down menu. Does this look useful to people?
>
Yes, this is very useful for me. I have a complicated history graph
because I manage the codebase for several websites with one git
repository. It gets very hard to follow the colored lines in gitk
when there are many merges of feature branches.
The most useful feature for me is probably the "ancestor" view; "not
ancestor" could also be interesting if I wanted to visualize which
feature branches were already merged and which are not.
Thanks,
Matthias
^ permalink raw reply
* Re: [PATCH] Read configuration also from ~/.gitrc
From: Jakub Narebski @ 2006-05-29 14:00 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0605290913330.8863@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> But would this not break for the normal case? If you override one key in
> the repository's config, with this patch, repo-config will barf. The
> normal case is that you do not expect multiple values for the same key.
> Your patch reads both ~/.gitrc and $GIT_DIR/config, and if a key has a
> value in both (even if they are identical), repo-config will error out.
So the patch was to simplistic. Values from user's configuration file
~/.gitrc should be marked, to be overridden by $GIT_DIR/config per
repository configuration file.
> Further, storing a key will no longer work. This is an obscure side
> effect of this patch not caring about storing anything in ~/.gitrc: If you
> find the key section (or the key) in ~/.gitrc, the offset will be stored,
> _and used on $GIT_DIR/config_!
I think that storing a key should (unless new option --user-config or
--global is used) should store it in $GIT_DIR/config file; of course index
has to be found there, and if not found it key should be created. Per
configuration file offsets?
> I agree it is nice to have a global git configuration, but I have it: I
> use templates.
There are system-wide templates. git-init-db(1) doesn't show default
directory for _user_ templates...
And I guess that these are the issues why Junio C Hamano wrote:
> * The 'pu' branch, in addition, has these.
>
> - $HOME/.gitrc (Petr Baudis)
> Read configuration also from ~/.gitrc
>
> * I like this but it breaks the tests big time. Not "next"
> material yet, unfortunately.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* [PATCH] git-clean fails on files beginning with a dash
From: Dennis Stosberg @ 2006-05-29 15:06 UTC (permalink / raw)
To: git
Reproducible with:
$ git init-db
$ echo "some text" >-file
$ git clean
Removing -file
rm: invalid option -- l
Try `rm --help' for more information.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
git-clean.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-clean.sh b/git-clean.sh
index bb56264..3834323 100755
--- a/git-clean.sh
+++ b/git-clean.sh
@@ -19,8 +19,8 @@ ignored=
ignoredonly=
cleandir=
quiet=
-rmf="rm -f"
-rmrf="rm -rf"
+rmf="rm -f --"
+rmrf="rm -rf --"
rm_refuse="echo Not removing"
echo1="echo"
--
1.3.3+git20060528-dest1
^ permalink raw reply related
* [PATCH] cg-clean fails on files beginning with a dash
From: Dennis Stosberg @ 2006-05-29 15:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Reproducible with:
$ git init-db
$ echo "some text" >-file
$ cg clean
Removing -file
rm: invalid option -- l
Try `rm --help' for more information.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
cg-clean | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cg-clean b/cg-clean
index 5f438eb..fe611ac 100755
--- a/cg-clean
+++ b/cg-clean
@@ -67,13 +67,13 @@ while read -r file; do
if [ "$cleandirhard" ]; then
chmod -R 700 "$file"
fi
- $rm -rf "$file"
+ $rm -rf -- "$file"
if [ -e "$file" -o -L "$file" ]; then
echo "Cannot remove $file"
fi
elif [ -e "$file" -o -L "$file" ]; then
[ "$quiet" ] || echo "Removing $file"
- "$rm" -f "$file"
+ "$rm" -f -- "$file"
# rm would complain itself on failure
else
echo "File $file has disappeared!"
--
1.3.3+git20060528-dest1
^ permalink raw reply related
* Re: [PATCH] git-receive-pack needs to set umask(2)
From: Michael Richardson @ 2006-05-29 16:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060528220628.GE10488@pasky.or.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Petr" == Petr Baudis <pasky@ucw.cz> writes:
Petr> The object database is considered "append-only" unless you do
Petr> git-prune (and you should better not let anyone do that), thus
Petr> it's enough if you set all directories group-writable. Other
Exactly, you have to do that. And only the owner can change the modes,
thus, unless all users have their umask set up right, someone gets toasted.
Since the directories are created on the fly, they need to be created
with the right permissions.
Petr> than access the object database, the users probably only want
Petr> to update the refs - the solution is to make refs/heads/ and
Petr> refs/tags/ group-writable and setgid. This is also what
Petr> git-init-db --shared (or tools like cg-admin-setuprepo) should
Petr> already set up for you.
Petr> So, what did break?
Never heard of "git-init-db --shared".
> A shared repository allows users belonging to the same group to push
> into that repository. When specifying `--shared` the config variable
> "core.sharedRepository" is set to 'true' so that directories under
> `$GIT_DIR` are made group writable (and g+sx, since the git group may
> be not the primary group of all users).
That would seem to be the right thing.
Seems it was added in December.
- --
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
"The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Finger me for keys
iQEVAwUBRHsbW4CLcPvd0N1lAQKa/gf+MF93+zbNnmqpysWMmYPVhW6HvU6XFyCQ
KyTfA7dxVX3tS9coSAcT73IX659umMz1MkyG7YR4ISFLlhLmdthq6l/ETueTZPVw
SgTSEU9TT2sM+gjtzy6v1wGQJAXJxYw6kJgKOFgCfyIPsb7EZWyQBmZLiNU0omnv
gkV8Ja5pJPTNHcinzzNyg8LIm0j55cS9OG9XQrXm46q+9OX+y39BoxGnz3Guzmry
yzfx1ipDuW54QCzKRyBpwt7/1LBfk/eJAH0wP9IAA4qz39+OA2yz8fTMvHDB1a6V
H18SkBENb6ZllGovu60IUgJCKy2sizGkBGUax9ec2ByAzHL1al3W3g==
=arDu
-----END PGP SIGNATURE-----
^ 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