* 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: 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] 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] 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: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: 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
* [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
* [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
* 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
* 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 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] 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] 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
* [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
* [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] 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
* 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
* What's in git.git
From: Junio C Hamano @ 2006-05-29 6:44 UTC (permalink / raw)
To: git; +Cc: linux-kernel
* The 'master' branch has these since the last announcement.
This is a fairly big update.
- git-apply takes notice of beginning and end of file as
context (Catalin Marinas, Linus and me)
apply: treat EOF as proper context.
apply: force matching at the beginning.
- gitview updates (Aneesh Kumar K.V)
- git-mailinfo updates (Eric W. Biederman and me)
Make read_one_header_line return a flag not a length.
Move B and Q decoding into check header.
Refactor commit messge handling.
In handle_body only read a line if we don't already have one.
More accurately detect header lines in read_one_header_line
Allow in body headers beyond the in body header prefix.
mailinfo: skip bogus UNIX From line inside body
mailinfo: More carefully parse header lines in read_one_header_line()
- format-patch --start-number (Johannes Schindelin and me)
cache-tree: replace a sscanf() by two strtol() calls
Fix crash when reading the empty tree
git-format-patch --start-number <n>
built-in format-patch: various fixups.
format-patch: -n and -k are mutually exclusive.
- ls-remote rsync:// fix (me)
ls-remote: fix rsync:// to report HEAD
* This should fix clone over rsync:// (which is deprecated
but anyway).
- cache-tree optimization for apply & write-tree sequence (me,
Johannes, Dennis Stosberg)
read-cache/write-cache: optionally return cache checksum SHA1.
Add cache-tree.
Update write-tree to use cache-tree.
Invalidate cache-tree entries for touched paths in git-apply.
Use cache-tree in update-index.
Add test-dump-cache-tree
cache-tree: protect against "git prune".
index: make the index file format extensible.
Teach fsck-objects about cache-tree.
cache-tree: sort the subtree entries.
test-dump-cache-tree: report number of subtrees.
update-index: when --unresolve, smudge the relevant cache-tree entries.
read-tree: teach 1 and 2 way merges about cache-tree.
read-tree: teach 1-way merege and plain read to prime cache-tree.
cache_tree_update: give an option to update cache-tree only.
test-dump-cache-tree: validate the cached data as well.
cache-tree.c: typefix
fsck-objects: mark objects reachable from cache-tree
Fix test-dump-cache-tree in one-tree disappeared case.
read-tree: invalidate cache-tree entry when a new index entry is added.
cache-tree: a bit more debugging support.
fsck-objects: do not segfault on missing tree in cache-tree
fix git-write-tree with cache-tree on BE64
* I've held onto this too long but haven't seen breakage.
This should make cycles of "apply & write-tree" faster by
15-20%.
- documentation (Jeff King)
cat-file: document -p option
- cvsimport Perl backward compatibility (Jeff King)
cvsimport: avoid "use" with :tag
- build fixes (Jim Meyering, Martin Waitz)
Don't write directly to a make target ($@).
Documentation/Makefile: remove extra /
Add instructions to commit template.
- "git-clone --template" (me)
Let git-clone to pass --template=dir option to git-init-db.
- various fixes and cleanups (Linus, Martin Waitz, Petr Baudis,
Shawn Pearce, me)
builtin-rm: squelch compiler warnings.
fetch.c: remove an unused variable and dead code.
git-fetch: avoid using "case ... in (arm)"
bogus "fatal: Not a git repository"
t1002: use -U0 instead of --unified=0
Fix "--abbrev=xyz" for revision listing
Don't use "sscanf()" for tree mode scanning
Call builtin ls-tree in git-cat-file -p
Built git-upload-tar should be ignored.
- rev-list --objects memory leak fix (Linus)
Fix memory leak in "git rev-list --objects"
- cvsexportcommit fixups (Yann Dirson)
Do not call 'cmp' with non-existant -q flag.
Document current cvsexportcommit limitations.
Make cvsexportcommit create parent directories as needed.
* The 'next' branch, in addition, has these.
- portability of tests across different bourne flavors (Eric Wong)
t3300-funny-names: shell portability fixes
tests: Remove heredoc usage inside quotes
t5500-fetch-pack: remove local (bashism) usage.
t6000lib: workaround a possible dash bug
* I think these are OK to push out to "master".
- read-tree/write-tree --prefix from bind commit series (me)
read-tree: --prefix=<path>/ option.
write-tree: --prefix=<path>
read-tree: reorganize bind_merge code.
* I think these are OK to push out to "master".
- avoid wasted work in fetch-pack when receiving side has more
roots than the sender (me).
fetch-pack: give up after getting too many "ack continue"
* While this would not hurt, it is a client-side hack. To
fix the problem properly, the server side needs to become a
bit smarter.
- tree parser reorganization (Linus)
Add raw tree buffer info to "struct tree"
Make "tree_entry" have a SHA1 instead of a union of object pointers
Switch "read_tree_recursive()" over to tree-walk functionality
Remove "tree->entries" tree-entry list from tree parser
* This looks good; I would like to cook this for a while in
"next", and mark its graduation with 1.4.0 release.
- test fix for http-fetch segfault (Sean Estabrooks)
* Status?
- ref-log (Shawn Pearce)
Improve abstraction of ref lock/write.
Convert update-ref to use ref_lock API.
Log ref updates to logs/refs/<ref>
Support 'master@2 hours ago' syntax
Fix ref log parsing so it works properly.
General ref log reading improvements.
Added logs/ directory to repository layout.
Force writing ref if it doesn't exist.
Log ref updates made by fetch.
Change 'master@noon' syntax to 'master@{noon}'.
Correct force_write bug in refs.c
Change order of -m option to update-ref.
Include ref log detail in commit, reset, etc.
Create/delete branch ref logs.
Enable ref log creation in git checkout -b.
Verify git-commit provides a reflog message.
Test that git-branch -l works.
* I think these are OK to push out to "master" in that it
does not seem to cause regression, but I haven't used this
change for real work. Impressions?
* 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.
^ permalink raw reply
* Re: [PATCH 1/1] Tried to fix git-svn's handling of filenames with embedded '@'.
From: Eric Wong @ 2006-05-29 6:35 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m2verqkobr.fsf@ziti.fhcrc.org>
Seth: how does this work?
Ick, I just found out keyword killing tests don't pass with
svn 1.1, though...
---
svn has trouble parsing files with embedded '@' characters. For
example,
svn propget svn:keywords foo@bar.c
svn: Syntax error parsing revision 'bar.c'
I asked about this on #svn and the workaround suggested was to append
an explicit revision specifier:
svn propget svn:keywords foo@bar.c@BASE
This patch appends '@BASE' to the filename in all calls to 'svn
propget'.
Patch originally by Seth Falcon <sethfalcon@gmail.com>
Seth: signoff?
[ew: Made to work with older svn that don't support peg revisions]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 17 +++++++++++++----
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index b3e0684..54b93f4 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -34,7 +34,7 @@ my $sha1_short = qr/[a-f\d]{4,40}/;
my ($_revision,$_stdin,$_no_ignore_ext,$_no_stop_copy,$_help,$_rmdir,$_edit,
$_find_copies_harder, $_l, $_version, $_upgrade, $_authors);
my (@_branch_from, %tree_map, %users);
-my $_svn_co_url_revs;
+my ($_svn_co_url_revs, $_svn_pg_peg_revs);
my %fc_opts = ( 'no-ignore-externals' => \$_no_ignore_ext,
'branch|b=s' => \@_branch_from,
@@ -336,7 +336,7 @@ sub show_ignore {
my %ign;
File::Find::find({wanted=>sub{if(lstat $_ && -d _ && -d "$_/.svn"){
s#^\./##;
- @{$ign{$_}} = safe_qx(qw(svn propget svn:ignore),$_);
+ @{$ign{$_}} = svn_propget_base('svn:ignore', $_);
}}, no_chdir=>1},'.');
print "\n# /\n";
@@ -860,7 +860,7 @@ sub sys { system(@_) == 0 or croak $? }
sub eol_cp {
my ($from, $to) = @_;
- my $es = safe_qx(qw/svn propget svn:eol-style/, $to);
+ my $es = svn_propget_base('svn:eol-style', $to);
open my $rfd, '<', $from or croak $!;
binmode $rfd or croak $!;
open my $wfd, '>', $to or croak $!;
@@ -898,7 +898,7 @@ sub do_update_index {
while (my $x = <$p>) {
chomp $x;
if (!$no_text_base && lstat $x && ! -l _ &&
- safe_qx(qw/svn propget svn:keywords/,$x)) {
+ svn_propget_base('svn:keywords', $x)) {
my $mode = -x _ ? 0755 : 0644;
my ($v,$d,$f) = File::Spec->splitpath($x);
my $tb = File::Spec->catfile($d, '.svn', 'tmp',
@@ -1136,6 +1136,9 @@ sub svn_compat_check {
if (grep /usage: checkout URL\[\@REV\]/,@co_help) {
$_svn_co_url_revs = 1;
}
+ if (grep /\[TARGET\[\@REV\]\.\.\.\]/, `svn propget -h`) {
+ $_svn_pg_peg_revs = 1;
+ }
# I really, really hope nobody hits this...
unless (grep /stop-on-copy/, (safe_qx(qw(svn log -h)))) {
@@ -1215,6 +1218,12 @@ sub load_authors {
close $authors or croak $!;
}
+sub svn_propget_base {
+ my ($p, $f) = @_;
+ $f .= '@BASE' if $_svn_pg_peg_revs;
+ return safe_qx(qw/svn propget/, $p, $f);
+}
+
__END__
Data structures:
--
1.3.3.gef0f
^ permalink raw reply related
* Re: Commands Mismatch in tutorial and the actual binaries.
From: Jakub Narebski @ 2006-05-29 6:07 UTC (permalink / raw)
To: git
In-Reply-To: <1148880611.7193.12.camel@localhost.localdomain>
kandagatla.Srinivas wrote:
> Hi All
> Im very new to GIT Stuff. But by installing the latest version (git-1.3.3)
> of GIT and going thru the tutorial, I am unable to understand why
> there is a mismatch in the commmands.
> Tutorial says use commands like git init-db but actually these are
> installed as git-init-db. Is this OK.. or NOT.
>
> One more doubt is .. I was unable to locate a command like git-add ..
>
> Can some one help me.
Actually, in properly installed git both versions should work,
and 'git command' is preferred version, at least for the ordinary
user level commands; "plumbing" commands are usually spelled 'git-command'.
Usually 'git command' is just a wrapper calling git-command.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH 0/4] fix tests so they run without needing bash
From: Eric Wong @ 2006-05-29 5:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu07dqyk8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> You are my hero.
:)
You and Linus have already been my heroes for a while.
I was very pleasantly surprised that all the git-*.sh files work fine
(for me, at least) and only the tests needed modification.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 3/4] t5500-fetch-pack: remove local (bashism) usage.
From: Junio C Hamano @ 2006-05-29 5:36 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060529052828.GB24077@localdomain>
Eric Wong <normalperson@yhbt.net> writes:
> Herbert Xu <herbert@gondor.apana.org.au> wrote:
>> On Thu, May 25, 2006 at 07:06:17PM -0700, Eric Wong wrote:
>> > None of the variables seem to conflict, so local was unnecessary.
>>
>> BTW, dash supports (and has always supported) local which is a quite
>> useful feature.
>
> 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.
Concurred. There are things Herbert said are clearly dash bugs,
but this one is outside POSIX, so lets leave your changes to the
test for it.
^ permalink raw reply
* Re: [PATCH 2/4] tests: Remove heredoc usage inside quotes
From: Eric Wong @ 2006-05-29 5:30 UTC (permalink / raw)
To: Herbert Xu; +Cc: Junio C Hamano, git
In-Reply-To: <20060526122231.GB5372@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Thu, May 25, 2006 at 07:06:16PM -0700, Eric Wong wrote:
> > The use of heredoc inside quoted strings doesn't seem to be
> > supported by dash. pdksh seems to handle it fine, however.
>
> This is a bug in dash and should be fixed there instead.
> Thanks for drawing my attention to it.
No problem. I think these dash bugs should be fixed in dash, but
continue to be worked around in git as old versions of dash will
probably continue to exist for a long time.
--
Eric Wong
^ permalink raw reply
* Commands Mismatch in tutorial and the actual binaries.
From: kandagatla.Srinivas @ 2006-05-29 5:30 UTC (permalink / raw)
To: git
Hi All
Im very new to GIT Stuff. But by installing the latest version<git-1.3.3
> of GIT and going thru the tutorial, I am unable to understand why
there is a mismatch in the commmands.
Tutorial says use commands like git init-db but actually these are
installed as git-init-db. Is this OK.. or NOT.
One more doubt is .. I was unable to locate a command like git-add ..
Can some one help me.
Regards
Srinivas.Kandagatla
Celuinte Soft Systems.
^ permalink raw reply
* Re: [PATCH 3/4] t5500-fetch-pack: remove local (bashism) usage.
From: Eric Wong @ 2006-05-29 5:28 UTC (permalink / raw)
To: Herbert Xu; +Cc: Junio C Hamano, git
In-Reply-To: <20060526122317.GC5372@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Thu, May 25, 2006 at 07:06:17PM -0700, Eric Wong wrote:
> > None of the variables seem to conflict, so local was unnecessary.
>
> BTW, dash supports (and has always supported) local which is a quite
> useful feature.
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.
--
Eric Wong
^ 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