* [PATCH 2/2] update-hook-example: optionally allow non-fast-forward
From: Dmitry Potapov @ 2008-06-25 8:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Dmitry Potapov
In-Reply-To: <1214382416-6687-1-git-send-email-dpotapov@gmail.com>
Sometimes it is desirable to have non-fast-forward branches in a
shared repository. A typical example of that is the 'pu' branch.
This patch extends the format of allowed-users and allow-groups
files by using the '+' sign at the beginning as the mark that
non-fast-forward pushes are permitted to the branch.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
Documentation/howto/update-hook-example.txt | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt
index a8d3bae..e1e2889 100644
--- a/Documentation/howto/update-hook-example.txt
+++ b/Documentation/howto/update-hook-example.txt
@@ -65,7 +65,7 @@ function info {
# Implement generic branch and tag policies.
# - Tags should not be updated once created.
-# - Branches should only be fast-forwarded.
+# - Branches should only be fast-forwarded unless their pattern starts with '+'
case "$1" in
refs/tags/*)
git rev-parse --verify -q "$1" &&
@@ -80,7 +80,7 @@ case "$1" in
mb=$(git-merge-base "$2" "$3")
case "$mb,$2" in
"$2,$mb") info "Update is fast-forward" ;;
- *) deny >/dev/null "This is not a fast-forward update." ;;
+ *) noff=y; info "This is not a fast-forward update.";;
esac
fi
;;
@@ -98,8 +98,9 @@ info "The user is: '$username'"
if [ -f "$allowed_users_file" ]; then
rc=$(cat $allowed_users_file | grep -v '^#' | grep -v '^$' |
while read head_pattern user_patterns; do
- matchlen=$(expr "$1" : "$head_pattern")
- if [ "$matchlen" == "${#1}" ]; then
+ matchlen=$(expr "$1" : "${head_pattern#+}")
+ allow_noff=$(expr substr "$head_pattern" 1 1)
+ if [ "$matchlen" = "${#1}" -a \( -z "$noff" -o "$allow_noff" = '+' \) ]; then
info "Found matching head pattern: '$head_pattern'"
for user_pattern in $user_patterns; do
info "Checking user: '$username' against pattern: '$user_pattern'"
@@ -127,8 +128,9 @@ info "'$groups'"
if [ -f "$allowed_groups_file" ]; then
rc=$(cat $allowed_groups_file | grep -v '^#' | grep -v '^$' |
while read head_pattern group_patterns; do
- matchlen=$(expr "$1" : "$head_pattern")
- if [ "$matchlen" == "${#1}" ]; then
+ matchlen=$(expr "$1" : "${head_pattern#+}")
+ allow_noff=$(expr substr "$head_pattern" 1 1)
+ if [ "$matchlen" = "${#1}" -a \( -z "$noff" -o "$allow_noff" = '+' \) ]; then
info "Found matching head pattern: '$head_pattern'"
for group_pattern in $group_patterns; do
for groupname in $groups; do
@@ -159,6 +161,7 @@ allowed-groups, to describe which heads can be pushed into by
whom. The format of each file would look like this:
refs/heads/master junio
+ +refs/heads/pu junio
refs/heads/cogito$ pasky
refs/heads/bw/.* linus
refs/heads/tmp/.* .*
@@ -166,7 +169,8 @@ whom. The format of each file would look like this:
With this, Linus can push or create "bw/penguin" or "bw/zebra"
or "bw/panda" branches, Pasky can do only "cogito", and JC can
-do master branch and make versioned tags. And anybody can do
-tmp/blah branches.
+do master and pu branches and make versioned tags. And anybody
+can do tmp/blah branches. The '+' sign at the pu record means
+that JC can make non-fast-forward pushes on it.
------------
--
1.5.6
^ permalink raw reply related
* [PATCH 1/2] fix update-hook-example to work with packed tag references
From: Dmitry Potapov @ 2008-06-25 8:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Dmitry Potapov
The update-hook-example used 'test -f' to check the tag present, which
does not work if the checked reference is packed. This check has been
changed to use 'git rev-parse $tag' instead.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
Documentation/howto/update-hook-example.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt
index 88765b5..a8d3bae 100644
--- a/Documentation/howto/update-hook-example.txt
+++ b/Documentation/howto/update-hook-example.txt
@@ -68,7 +68,7 @@ function info {
# - Branches should only be fast-forwarded.
case "$1" in
refs/tags/*)
- [ -f "$GIT_DIR/$1" ] &&
+ git rev-parse --verify -q "$1" &&
deny >/dev/null "You can't overwrite an existing tag"
;;
refs/heads/*)
--
1.5.6
^ permalink raw reply related
* Re: [PATCH] Ship sample hooks with .sample suffix
From: Junio C Hamano @ 2008-06-25 8:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <1214376700.4861eafc43b36@webmail.eunet.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> I am very confident in the series as far as using it on Windows is concerned.
> But I must admit that I have started to use it on Linux only recently.
> Therefore, cooking it in 'next' for a few days is probably not a mistake.
The question obviously was about using outside Windows context as we have
been talking about merging it into my history ;-)
I'll push out the master with the *.sample patch hopefully soon.
^ permalink raw reply
* Re: [PATCH/RFC] git-svn: sanitize_remote_name should accept underscores.
From: Eric Wong @ 2008-06-25 7:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Avery Pennarun, git
In-Reply-To: <7vfxr23s6m.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Wait, nevermind, this is for remotes, not remote *branches*.
> >
> > Umm... are underscores now allowed in git config files?
>
> In
>
> [foo "bar"] baz = value
>
> foo and baz must be config.c::iskeychar() (and baz must be isalpha()), but
> "bar" can be almost anything.
>
> Isn't "not underscore" coming from DNS hostname part restriction?
No, nothing to do with DNS hostnames in the remote names. I think I
just looked at remotes2config.sh one day and used it as a reference :x
It's late and I've had a rough few days, but shouldn't
sanitize_remote_name() just escape . and "? Right now it's converting
stuff to . which has me very confused...
--
Eric Wong (in need of sleep and sanity atm...)
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Miklos Vajna @ 2008-06-25 7:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <m3fxr2jruy.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 297 bytes --]
On Tue, Jun 24, 2008 at 05:11:44PM -0700, Jakub Narebski <jnareb@gmail.com> wrote:
> What does "git ls-remote server:/home/vmiklos/git/test" invoke on server?
$ git ls-remote server:/home/vmiklos/git/test
bash: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: Karl Hasselström @ 2008-06-25 7:27 UTC (permalink / raw)
To: A Large Angry SCM
Cc: Lea Wiemann, Michael Haggerty, Johannes Schindelin, Jeff King,
git
In-Reply-To: <486188E3.10803@gmail.com>
On 2008-06-24 19:53:07 -0400, A Large Angry SCM wrote:
> Lea Wiemann wrote:
>
> > I think this is a good suggestion (though I haven't thought things
> > through). Another idea is to add "old" and "new" (or something
> > like that) as aliases to "good" and "bad", since that's the only
> > semantics that the bisect labels actually seem to have.
>
> "Before" and "After" the "Change" maybe?
Ha. It would not be hard to make it accept any two tags the user
happens to use. fast/slow, works/broken, fina-fisken/totalkvaddad, ...
it even comes with built-in internationalization!
/me ducks.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] factorize pack structure allocation
From: Teemu Likonen @ 2008-06-25 7:19 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.1.10.0806241851420.2979@xanadu.home>
Nicolas Pitre wrote (2008-06-24 18:58 -0400):
> New pack structures are currently allocated in 2 different places
> and all members have to be initialized explicitly. This is prone
> to errors leading to segmentation faults as found by Teemu Likonen.
>
> Let's have a common place where this structure is allocated, and have
> all members implicitly initialized to zero.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
Because of time zone issues I didn't get a chance to check this until
now. This fixes the segfault issue for me. Thanks!
^ permalink raw reply
* Re: [PATCH/RFC] git-svn: sanitize_remote_name should accept underscores.
From: Junio C Hamano @ 2008-06-25 7:11 UTC (permalink / raw)
To: Eric Wong; +Cc: Avery Pennarun, git
In-Reply-To: <20080625065556.GM21299@hand.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Wait, nevermind, this is for remotes, not remote *branches*.
>
> Umm... are underscores now allowed in git config files?
In
[foo "bar"] baz = value
foo and baz must be config.c::iskeychar() (and baz must be isalpha()), but
"bar" can be almost anything.
Isn't "not underscore" coming from DNS hostname part restriction?
^ permalink raw reply
* Re: git-clone works with ssh but not with http/https/git
From: Erez Zilber @ 2008-06-25 6:56 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Robert Haines, Matthias Kestenholz, git
In-Reply-To: <alpine.LNX.1.00.0806241305150.19665@iabervon.org>
On Tue, Jun 24, 2008 at 8:10 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 24 Jun 2008, Erez Zilber wrote:
>
>> BTW - I'm currently running git-daemon in the following way:
>>
>> sudo git-daemon --base-path=/pub/git/ --export-all
>>
>> Is there any advantage to run it through xinetd? How do you run it?
>
> You probably want to run it from something that init runs, or you'll have
> to figure it out again when you reboot the server in a while. So you
> either want a suitable init script (Gentoo, for example, has one in their
> git package), or to run it through xinetd (which you almost certainly have
> an init script for).
>
> -Daniel
> *This .sig left intentionally blank*
>
Thanks. I was able to config xinetd, and everything seems to work now.
I would like to thank everyone here for the quick and very useful
help.
Erez
^ permalink raw reply
* Re: [PATCH/RFC] git-svn: sanitize_remote_name should accept underscores.
From: Eric Wong @ 2008-06-25 6:55 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git, gitster
In-Reply-To: <20080625064435.GL21299@hand.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> Avery Pennarun <apenwarr@gmail.com> wrote:
> > Without this patch, git-svn failed with the error:
> > config --get svn-remote.D2007.Win32.url: command returned error: 1
> >
> > ...upon trying to automatically follow a link from a child branch back to
> > its parent branch D2007_Win32 (note the underscore, not dot, separating the
> > two words).
> >
> > Note that I have each of my branches defined (by hand) as separate
> > svn-remote entries in .git/config since my svn repository layout is
> > nonstandard.
> >
> > Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
>
> Thanks,
>
> Acked-by: Eric Wong <normalperson@yhbt.net>
>
> > ---
> > I'm not sure why sanitize_remote_name is so picky about allowed characters,
> > but underscore should certainly be allowed. I'm worried that this has
> > revealed a more serious problem, since presumably sanitizing the name
> > shouldn't break anything in any case.
>
> Weird. It looks like a stupid bug on my part. I'm surprised
> it took this long to find, since underscore is pretty common...
Wait, nevermind, this is for remotes, not remote *branches*.
Umm... are underscores now allowed in git config files?
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Ship sample hooks with .sample suffix
From: Johannes Sixt @ 2008-06-25 6:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vod5q8c25.fsf@gitster.siamese.dyndns.org>
Zitat von Junio C Hamano <gitster@pobox.com>:
> I am very tempted to pull MinGW series directly to 'master', or at least
> to 'next', perhaps after dropping 31d6632. What's your confidence level
> on the series? I think we should give this series extra priority so that
> any potential issues with other series (like dr/ceil) that do pathname
> traversal will become more apparent sooner rather than later.
I am very confident in the series as far as using it on Windows is concerned.
But I must admit that I have started to use it on Linux only recently.
Therefore, cooking it in 'next' for a few days is probably not a mistake.
-- Hannes
^ permalink raw reply
* Re: [PATCH/RFC] git-svn: sanitize_remote_name should accept underscores.
From: Eric Wong @ 2008-06-25 6:44 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git, gitster
In-Reply-To: <1214322898-9272-1-git-send-email-apenwarr@gmail.com>
Avery Pennarun <apenwarr@gmail.com> wrote:
> Without this patch, git-svn failed with the error:
> config --get svn-remote.D2007.Win32.url: command returned error: 1
>
> ...upon trying to automatically follow a link from a child branch back to
> its parent branch D2007_Win32 (note the underscore, not dot, separating the
> two words).
>
> Note that I have each of my branches defined (by hand) as separate
> svn-remote entries in .git/config since my svn repository layout is
> nonstandard.
>
> Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Thanks,
Acked-by: Eric Wong <normalperson@yhbt.net>
> ---
> I'm not sure why sanitize_remote_name is so picky about allowed characters,
> but underscore should certainly be allowed. I'm worried that this has
> revealed a more serious problem, since presumably sanitizing the name
> shouldn't break anything in any case.
Weird. It looks like a stupid bug on my part. I'm surprised
it took this long to find, since underscore is pretty common...
> ---
> git-svn.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 4c9c59b..263d66c 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -1465,7 +1465,7 @@ sub verify_remotes_sanity {
> # we allow more chars than remotes2config.sh...
> sub sanitize_remote_name {
> my ($name) = @_;
> - $name =~ tr{A-Za-z0-9:,/+-}{.}c;
> + $name =~ tr{A-Za-z0-9:,_/+-}{.}c;
> $name;
> }
>
> --
> 1.5.6.56.g29b0d
^ permalink raw reply
* Re: [PATCH] pack.indexversion config option now defaults to 2
From: Mike Hommey @ 2008-06-25 6:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Nicolas Pitre, git
In-Reply-To: <7viqvy59qr.fsf@gitster.siamese.dyndns.org>
On Tue, Jun 24, 2008 at 11:06:36PM -0700, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
>
> > Wouldn't it be a good idea to add a warning in git update-server-info
> > when it detects pack.indexVersion is not 1, too ?
>
> Can you describe how that warning will help whom in the bigger picture?
>
> The way as I understand everybody runs "git update-server-info" is:
>
> * "git push" pushes into a publishing repository, then
> * "post-receive" (or "post-update") hook triggers "update-server-info".
>
> If you spit out a warning from update-server-info, it will be shown to the
> pusher over sideband, but this will not necessarily help the pusher, who
> may or may not have shell access to the repository.
There are also those that get the message to run update-server-info when
trying to clone over dumb protocol when the info/refs file is not
there... I actually didn't think about the post-receive hook.
Well, then, update-server-info could output the warning only if stderr
is a tty.
Mike
^ permalink raw reply
* Re: [PATCH] clone: create intermediate directories of destination repo
From: Daniel Barkalow @ 2008-06-25 6:11 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Brandon Casey, zuh, git
In-Reply-To: <20080625054134.GB2209@sigill.intra.peff.net>
On Wed, 25 Jun 2008, Jeff King wrote:
> On Tue, Jun 24, 2008 at 11:20:07AM -0400, Daniel Barkalow wrote:
>
> > > I am worried that it is too clever. I didn't see an obvious way for
> > > work_tree and git_dir to not have that property, but I think it is still
> > > worth somebody double-checking.
> >
> > I think you can specify git_dir and work_tree on the command line, and set
> > them to whatever you want, although I now don't remember whether they're
> > actually both followed for clone (I tried to match the shell version,
> > whose behavior didn't make too much sense to me).
>
> The git_dir variable is always set from the directory provided on the
> command line. However, the work_tree can be overridden by the
> environment. For some reason I missed the giant 'work_tree =
> getenv("GIT_WORK_TREE")' when I looked before. But that means that they
> are not necessarily related.
>
> So my original patch was too clever. Here is the less clever patch, with
> an extra test that would break with the clever version.
Looks good, thanks.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Re: Convert 'git blame' to parse_options()
From: Johannes Sixt @ 2008-06-25 6:09 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Linus Torvalds, Junio C Hamano, Jeff King, Johannes Schindelin,
Git Mailing List
In-Reply-To: <20080624193028.GC9189@artemis.madism.org>
Pierre Habouzit schrieb:
> Though for the win32 port where fork is replaced with threads, well,
> it may cause some issues, so I was reluctant wrt them. Of course it's
> unlikely that it will cause problems, but one never knows ;)
We use threads only for those fork()s that are not followed by an exec().
So this is not a reason to worry about memory leaks in the option parser.
-- Hannes
^ permalink raw reply
* Re: [PATCH] pack.indexversion config option now defaults to 2
From: Junio C Hamano @ 2008-06-25 6:06 UTC (permalink / raw)
To: Mike Hommey; +Cc: Linus Torvalds, Nicolas Pitre, git
In-Reply-To: <20080625055605.GD28563@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> Wouldn't it be a good idea to add a warning in git update-server-info
> when it detects pack.indexVersion is not 1, too ?
Can you describe how that warning will help whom in the bigger picture?
The way as I understand everybody runs "git update-server-info" is:
* "git push" pushes into a publishing repository, then
* "post-receive" (or "post-update") hook triggers "update-server-info".
If you spit out a warning from update-server-info, it will be shown to the
pusher over sideband, but this will not necessarily help the pusher, who
may or may not have shell access to the repository.
^ permalink raw reply
* Re: [PATCH] pack.indexversion config option now defaults to 2
From: Mike Hommey @ 2008-06-25 5:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Nicolas Pitre, git
In-Reply-To: <7vd4m66rfp.fsf@gitster.siamese.dyndns.org>
On Tue, Jun 24, 2008 at 09:59:06PM -0700, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > On Wed, 25 Jun 2008, Nicolas Pitre wrote:
> >>
> >> Git older than version 1.5.2 (or any other git version with this option
> >> set to 1) may revert to version 1 of the pack index by manually deleting
> >> all .idx files and recreating them using 'git index-pack'. Communication
> >> over the git native protocol is unaffected since the pack index is never
> >> transferred.
> >
> > Rather than talk about when it does _not_ matter, wouldn't it be better to
> > talk about when it _can_ matter?
> >
> > Namely when using dumb protocols, either http or rsync, with the other end
> > being some ancient git thing (and it is worth mentioning version of what
> > counts as 'ancient' too, I can't remember, probably means that pretty much
> > nobody else can either).
>
> I agree with you that the description of the change (in the commit log)
> and the instruction (in the documentation) could be more helpful and
> explicit.
(...)
Wouldn't it be a good idea to add a warning in git update-server-info
when it detects pack.indexVersion is not 1, too ?
Mike
^ permalink raw reply
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection
From: Junio C Hamano @ 2008-06-25 5:53 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <20080625053452.GI11793@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>> > "Shawn O. Pearce" <spearce@spearce.org> writes:
>> >
>> >>> Any other suggestions that is workable?
>> >>
>> >> diff --git a/builtin-clone.c b/builtin-clone.c
>> >> index 5c5acb4..98d0f0f 100644
>> >> --- a/builtin-clone.c
>> >> +++ b/builtin-clone.c
>> >> @@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare;
>> >
>> > << a patch to conditionally change "git-program" default to "git program"
>> > snipped >>
>
> Shouldn't "git upload-pack" work on the server side as far back as
> 0.99.9k?
Yeah, I missed the patch to connect.c that was buried among other changes.
Sorry.
^ permalink raw reply
* Re: [PATCH 1/3] Allow git-apply to ignore the hunk headers (AKA recountdiff)
From: Jeff King @ 2008-06-25 5:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Johannes Schindelin
In-Reply-To: <7vfxr29zju.fsf@gitster.siamese.dyndns.org>
On Tue, Jun 24, 2008 at 04:35:33PM -0700, Junio C Hamano wrote:
> I think I've already mentioned the above two points when this was
> originally posted.
>
> Somewhat disgusted...
Sorry, this is my fault. I hadn't looked at the recount patches closely,
but I had thought they were submit-worthy, so I encouraged Thomas to
include them in his series (since his patch depends on them).
I'll try to look them over more closely in the next day or two.
-Peff
^ permalink raw reply
* Re: [PATCH] clone: create intermediate directories of destination repo
From: Jeff King @ 2008-06-25 5:41 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Brandon Casey, zuh, git
In-Reply-To: <alpine.LNX.1.00.0806241113360.19665@iabervon.org>
On Tue, Jun 24, 2008 at 11:20:07AM -0400, Daniel Barkalow wrote:
> > I am worried that it is too clever. I didn't see an obvious way for
> > work_tree and git_dir to not have that property, but I think it is still
> > worth somebody double-checking.
>
> I think you can specify git_dir and work_tree on the command line, and set
> them to whatever you want, although I now don't remember whether they're
> actually both followed for clone (I tried to match the shell version,
> whose behavior didn't make too much sense to me).
The git_dir variable is always set from the directory provided on the
command line. However, the work_tree can be overridden by the
environment. For some reason I missed the giant 'work_tree =
getenv("GIT_WORK_TREE")' when I looked before. But that means that they
are not necessarily related.
So my original patch was too clever. Here is the less clever patch, with
an extra test that would break with the clever version.
-- >8 --
clone: create intermediate directories of destination repo
The shell version used to use "mkdir -p" to create the repo
path, but the C version just calls "mkdir". Let's replicate
the old behavior. We have to create the git and worktree
leading dirs separately; while most of the time, the
worktree dir contains the git dir (as .git), the user can
override this using GIT_WORK_TREE.
We can reuse safe_create_leading_directories, but we need to
make a copy of our const buffer to do so. Since
merge-recursive uses the same pattern, we can factor this
out into a global function. This has two other cleanup
advantages for merge-recursive:
1. mkdir_p wasn't a very good name. "mkdir -p foo/bar" actually
creates bar, but this function just creates the leading
directories.
2. mkdir_p took a mode argument, but it was completely
ignored.
---
builtin-clone.c | 5 +++++
builtin-merge-recursive.c | 13 ++-----------
cache.h | 1 +
sha1_file.c | 9 +++++++++
t/t5601-clone.sh | 22 ++++++++++++++++++++++
5 files changed, 39 insertions(+), 11 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 7190952..b2dfe1a 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -400,6 +400,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (!option_bare) {
junk_work_tree = work_tree;
+ if (safe_create_leading_directories_const(work_tree) < 0)
+ die("could not create leading directories of '%s'",
+ work_tree);
if (mkdir(work_tree, 0755))
die("could not create work tree dir '%s'.", work_tree);
set_git_work_tree(work_tree);
@@ -410,6 +413,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
setenv(CONFIG_ENVIRONMENT, xstrdup(mkpath("%s/config", git_dir)), 1);
+ if (safe_create_leading_directories_const(git_dir) < 0)
+ die("could not create leading directories of '%s'", git_dir);
set_git_dir(make_absolute_path(git_dir));
fprintf(stderr, "Initialize %s\n", git_dir);
diff --git a/builtin-merge-recursive.c b/builtin-merge-recursive.c
index 4aa28a1..43bf6aa 100644
--- a/builtin-merge-recursive.c
+++ b/builtin-merge-recursive.c
@@ -481,15 +481,6 @@ static char *unique_path(const char *path, const char *branch)
return newpath;
}
-static int mkdir_p(const char *path, unsigned long mode)
-{
- /* path points to cache entries, so xstrdup before messing with it */
- char *buf = xstrdup(path);
- int result = safe_create_leading_directories(buf);
- free(buf);
- return result;
-}
-
static void flush_buffer(int fd, const char *buf, unsigned long size)
{
while (size > 0) {
@@ -512,7 +503,7 @@ static int make_room_for_path(const char *path)
int status;
const char *msg = "failed to create path '%s'%s";
- status = mkdir_p(path, 0777);
+ status = safe_create_leading_directories_const(path);
if (status) {
if (status == -3) {
/* something else exists */
@@ -583,7 +574,7 @@ static void update_file_flags(const unsigned char *sha,
close(fd);
} else if (S_ISLNK(mode)) {
char *lnk = xmemdupz(buf, size);
- mkdir_p(path, 0777);
+ safe_create_leading_directories_const(path);
unlink(path);
symlink(lnk, path);
free(lnk);
diff --git a/cache.h b/cache.h
index a68866c..a9c14da 100644
--- a/cache.h
+++ b/cache.h
@@ -517,6 +517,7 @@ enum sharedrepo {
int git_config_perm(const char *var, const char *value);
int adjust_shared_perm(const char *path);
int safe_create_leading_directories(char *path);
+int safe_create_leading_directories_const(const char *path);
char *enter_repo(char *path, int strict);
static inline int is_absolute_path(const char *path)
{
diff --git a/sha1_file.c b/sha1_file.c
index 9330bc4..0d52e59 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -116,6 +116,15 @@ int safe_create_leading_directories(char *path)
return 0;
}
+int safe_create_leading_directories_const(const char *path)
+{
+ /* path points to cache entries, so xstrdup before messing with it */
+ char *buf = xstrdup(path);
+ int result = safe_create_leading_directories(buf);
+ free(buf);
+ return result;
+}
+
char *sha1_to_hex(const unsigned char *sha1)
{
static int bufno;
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 593d1a3..b642fb2 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -30,4 +30,26 @@ test_expect_success 'clone checks out files' '
'
+test_expect_success 'clone respects GIT_WORK_TREE' '
+
+ GIT_WORK_TREE=worktree git clone src bare &&
+ test -f bare/config &&
+ test -f worktree/file
+
+'
+
+test_expect_success 'clone creates intermediate directories' '
+
+ git clone src long/path/to/dst &&
+ test -f long/path/to/dst/file
+
+'
+
+test_expect_success 'clone creates intermediate directories for bare repo' '
+
+ git clone --bare src long/path/to/bare/dst &&
+ test -f long/path/to/bare/dst/config
+
+'
+
test_done
--
1.5.6.57.g56b3.dirty
^ permalink raw reply related
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection
From: Shawn O. Pearce @ 2008-06-25 5:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <7vy74u5bkk.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > If we force --upload-pack workaround to _everybody_ we are already lost.
> >
> > Also I think the previous one still lets you work it around by giving a
> > full path, like "/usr/local/bin/git-upload-pack", because "/usr" does not
> > match "git-" ;-)
>
> Ok, let's map this out seriously.
This plan makes a lot of sense to me. I'm behind it. For whatever
that means. At least I'll shutup and stop making noise about this
issue if you take this approach. :-)
> * 1.6.0 will install the server-side programs in $(bindir) so that
> people coming over ssh will find them on the $PATH
>
> * In 1.6.0 (and 1.5.6.1), we will change "git daemon" to accept both
> "git-program" and "git program" forms. When the spaced form is used, it
> will behave as if the dashed form is requested. This is a prerequisite
> for client side change to start asking for "git program".
>
> * In the near future, there will no client-side change. "git-program"
> will be asked for.
>
> * 6 months after 1.6.0 ships, hopefully all the deployed server side will
> be running that version or newer. Client side will start asking for
> "git program" by default, but we can still override with --upload-pack
> and friends.
>
> * 12 months after client side changes, everybody will be running that
> version or newer. We stop installing the server side programs in
> $(bindir) but people coming over ssh will be asking for "git program"
> and "git" will be on the $PATH so there is no issue.
>
> The above 6 and 12 are yanked out of thin air and I am of course open to
> tweaking them, but I think the above order of events would be workable.
Yea, 6 and 12 seem like a good idea. Its a couple of releases and
gives people time to migrate their server installations.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection
From: Shawn O. Pearce @ 2008-06-25 5:34 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <7v4p7i6qs1.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> > "Shawn O. Pearce" <spearce@spearce.org> writes:
> >
> >>> Any other suggestions that is workable?
> >>
> >> diff --git a/builtin-clone.c b/builtin-clone.c
> >> index 5c5acb4..98d0f0f 100644
> >> --- a/builtin-clone.c
> >> +++ b/builtin-clone.c
> >> @@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare;
> >
> > << a patch to conditionally change "git-program" default to "git program"
> > snipped >>
Shouldn't "git upload-pack" work on the server side as far back as
0.99.9k? That's back really old. And my patch fixed "git " to be
"git-" when talking to git-daemon, thus keeping clients compatible
with all current git:// servers.
For SSH servers that can't handle "git upload-pack" the user can
change it to --upload-pack=git-upload-pack and get back to the
old behavior, until the server operator can upgrade.
Your patch doesn't offer that work around on the client side.
> Typofix: s/cond/uncond/;
>
> > How would that help client that talk with git-daemon, unlike what I sent
> > earlier?
Check my change in git_connect again:
diff --git a/connect.c b/connect.c
index e92af29..dbabd93 100644
--- a/connect.c
+++ b/connect.c
@@ -576,8 +576,8 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
* from extended components with a NUL byte.
*/
packet_write(fd[1],
- "%s %s%chost=%s%c",
- prog, path, 0,
+ "git-%s %s%chost=%s%c",
+ prog + 4, path, 0,
target_host, 0);
free(target_host);
free(url);
Its buggy if the user tried to do "git ls-remote --upload-pack=crp git://"
but if this is the direction we want to go we can obviously work out a
better method of forcing "git " to be "git-" when talking to git-daemon.
> If we force --upload-pack workaround to _everybody_ we are already lost.
>
> Also I think the previous one still lets you work it around by giving a
> full path, like "/usr/local/bin/git-upload-pack", because "/usr" does not
> match "git-" ;-)
Please tell me, where is git-upload-pack on repo.or.cz?
$ ssh repo.or.cz which git-upload-pack
fatal: unrecognized command 'which git-upload-pack'
I doubt I can pass it '/usr/local/bin/git-upload-pack' and get it
to work too. So I don't think this is a good work around.
Obviously pasky will fix repo.or.cz to accept both at some point
in the near future, likely before 1.6.0 releases, because he's cool
like that. Not everyone is.
Please don't make 1.6.0 unavailable to end-users because their
server operator can't currently accept "git upload-pack" without
giving them a workaround to force "git-upload-pack" over SSH.
--
Shawn.
^ permalink raw reply related
* Re: policy and mechanism for less-connected clients
From: David Jeske @ 2008-06-25 5:20 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20080625023352.GC20361@mit.edu>
-- Theodore Tso wrote:
> Up to here, you can do this all with repo.or.cz, and/or github; you
> just give each developer their own repository, which they are allowed
> to push to, and no once else. Within their own repository they can
> make changes to their branches, so that all works just fine.
Yup. That's one of the reasons git is so attractive. There is some good stuff
under "here" though....
> > (a) safely "share" every DAG, branch, and tag data in their
> > repository to a well-connected server, into an established
> > namespace, while only changing branches and tags in their
> > namespace. This will allow all users to see the changes of other
> > users, without needing direct access to their trees (which are
> > inaccessible behind firewalls). [1]
>
> Right, so thats github and/or git.or.cz. Each user gets his/her own
> repository, but thats a very minor change. Not a big deal.
...most notably, all their DAGs in a single repository to save space is
important. Thousands of copies of thousands of repositories adds up. Especially
when most of the users who want to commit something probably commit <1-10k of
unique stuff. Seems pretty easy to change though. git.or.cz and github will
both be wanting this eventually.
The other big one is ACLs in 'well named' repositories, so multiple people can
safely be allowed to add changes to them, without giving them ability to blow
away the repository. I can see this isn't the way all git users work, but at
least a few users working this way now with shared push repositories. This is
just making it 'safer'. Also seems pretty easy to do.
> > (b) fetch selected DAG, branch, and tag data of others to their tree, to
see
> > the changes of others (whether merged with head or not) while disconnected
or
> > remote.
>
> This is also easy; you just establish remote tracking branches. I
> have a single shell scripted command, git-get-all, which pulls from
> all of the repositories I am interested in into various remote
> tracking branches so while I am disconnected, I can see what other
> folks have done on their trees.
Yes, so I'd have the same thing, except instead of a remote repository, it
would be a pattern of the branch namespace, such as /origin/users/jeske/*. It
doesn't seem like the current remote tracking branch stuff can do this, but it
would be easy to provide a client wrapper that would. Users who tracked the
whole repository would just get everything, which is also fine. Maybe a client
patch to make this better would be accepted.
> > (c) grant and enforce permission for certain users to submit _merges
> > only_ onto certain sub-portions of the "well-named branches"
>
> This is the wierd one. *** Why ***? There is nothing magical about
> merges; all a merge is a commit that contains more than one parent.
> You can put anything into a merge, and in theory the result of a merge
> could have nothing to do with either parent. It would be a very
> perverse merge, but it's certainly possible. So what's the point of
> trying to enforce rules about "merges only"?
I'll explain why I wrote this, but I admit it's a strange roundabout way to get
what I was hoping for. I hope there is a better way. One better way is to just
change the client, but I was hoping not to have to do that. let me explain..
Think about using CVS. user does "cvs up; hack hack hack; cvs commit (to
server)". In git, this workflow is "git pull; hack; commit; hack; commit; git
push (to server)". I want those interum "commits" to share the changes with the
server. I want to change this to "git pull; hack; commit-and-share; hack;
commit-and-share; git-push (to shared branch tag)"
It would be nice if "commit-and-share" could just use "git-push". However,
because users are going to do this habitually every commit, probably through a
script or merged command, I didn't want users who are accidentally working
directly in the master to accidentally fast-forward origin/master. (everyone
seems to discourage working on master anyhow). I was hoping to enforce this
only with server policy, so any git client works. That leaves me with the
challenge of figuring out which commits on origin/master are actually intended
to move the pointer, and which are accidents because someone forgot to branch
before hacking in their client. One simple way to do this is to require any
origin/master commit to have two children, one on the master, one somewhere
else. If you have a commit that is directly hanging off of master in this
design, you are doing the wrong thing. The server would tell you to "git
checkout master; git branch -b mymaster; git reset origin/master; git push".
This would put their local changes onto their private branch where they should
be. When they wanted to do the equivilant of "cvs commit;" or current "git
push;", they would do a merge to the master, and push again. The server would
allow it, because it sees the merge.
I recognize this is a bit strange. I'd love to have a better solution, but this
is the solution I can think of which only involves server enforcement. Other
solutions I thought of would all require client changes that would change
everyone's behavior. The candidate I liked best was: disallowing changes to
tracking branches, including master, probably by implicitly creating a branch
on commit to a tracking branch... However, I don't get the impression this will
fit into current git very well, because users would need to turn their current
"git push", into a "git merge master;git push"
I'm interested in other ideas to address this.
I know that all of what I wrote above seems strange if you don't buy into the
design assumptions. That it's critical to share a single server-repository,
that it's critical to have a shared 'well known' branch that only trusts
clients to add new changes to, etc.. However, these are important.
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: David Jeske @ 2008-06-25 5:20 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20080625023352.GC20361@mit.edu>
-- Theodore Tso wrote:
> Up to here, you can do this all with repo.or.cz, and/or github; you
> just give each developer their own repository, which they are allowed
> to push to, and no once else. Within their own repository they can
> make changes to their branches, so that all works just fine.
Yup. That's one of the reasons git is so attractive. There is some good stuff
under "here" though....
> > (a) safely "share" every DAG, branch, and tag data in their
> > repository to a well-connected server, into an established
> > namespace, while only changing branches and tags in their
> > namespace. This will allow all users to see the changes of other
> > users, without needing direct access to their trees (which are
> > inaccessible behind firewalls). [1]
>
> Right, so thats github and/or git.or.cz. Each user gets his/her own
> repository, but thats a very minor change. Not a big deal.
...most notably, all their DAGs in a single repository to save space is
important. Thousands of copies of thousands of repositories adds up. Especially
when most of the users who want to commit something probably commit <1-10k of
unique stuff. Seems pretty easy to change though. git.or.cz and github will
both be wanting this eventually.
The other big one is ACLs in 'well named' repositories, so multiple people can
safely be allowed to add changes to them, without giving them ability to blow
away the repository. I can see this isn't the way all git users work, but at
least a few users working this way now with shared push repositories. This is
just making it 'safer'. Also seems pretty easy to do.
> > (b) fetch selected DAG, branch, and tag data of others to their tree, to
see
> > the changes of others (whether merged with head or not) while disconnected
or
> > remote.
>
> This is also easy; you just establish remote tracking branches. I
> have a single shell scripted command, git-get-all, which pulls from
> all of the repositories I am interested in into various remote
> tracking branches so while I am disconnected, I can see what other
> folks have done on their trees.
Yes, so I'd have the same thing, except instead of a remote repository, it
would be a pattern of the branch namespace, such as /origin/users/jeske/*. It
doesn't seem like the current remote tracking branch stuff can do this, but it
would be easy to provide a client wrapper that would. Users who tracked the
whole repository would just get everything, which is also fine. Maybe a client
patch to make this better would be accepted.
> > (c) grant and enforce permission for certain users to submit _merges
> > only_ onto certain sub-portions of the "well-named branches"
>
> This is the wierd one. *** Why ***? There is nothing magical about
> merges; all a merge is a commit that contains more than one parent.
> You can put anything into a merge, and in theory the result of a merge
> could have nothing to do with either parent. It would be a very
> perverse merge, but it's certainly possible. So what's the point of
> trying to enforce rules about "merges only"?
I'll explain why I wrote this, but I admit it's a strange roundabout way to get
what I was hoping for. I hope there is a better way. One better way is to just
change the client, but I was hoping not to have to do that. let me explain..
Think about using CVS. user does "cvs up; hack hack hack; cvs commit (to
server)". In git, this workflow is "git pull; hack; commit; hack; commit; git
push (to server)". I want those interum "commits" to share the changes with the
server. I want to change this to "git pull; hack; commit-and-share; hack;
commit-and-share; git-push (to shared branch tag)"
It would be nice if "commit-and-share" could just use "git-push". However,
because users are going to do this habitually every commit, probably through a
script or merged command, I didn't want users who are accidentally working
directly in the master to accidentally fast-forward origin/master. (everyone
seems to discourage working on master anyhow). I was hoping to enforce this
only with server policy, so any git client works. That leaves me with the
challenge of figuring out which commits on origin/master are actually intended
to move the pointer, and which are accidents because someone forgot to branch
before hacking in their client. One simple way to do this is to require any
origin/master commit to have two children, one on the master, one somewhere
else. If you have a commit that is directly hanging off of master in this
design, you are doing the wrong thing. The server would tell you to "git
checkout master; git branch -b mymaster; git reset origin/master; git push".
This would put their local changes onto their private branch where they should
be. When they wanted to do the equivilant of "cvs commit;" or current "git
push;", they would do a merge to the master, and push again. The server would
allow it, because it sees the merge.
I recognize this is a bit strange. I'd love to have a better solution, but this
is the solution I can think of which only involves server enforcement. Other
solutions I thought of would all require client changes that would change
everyone's behavior. The candidate I liked best was: disallowing changes to
tracking branches, including master, probably by implicitly creating a branch
on commit to a tracking branch... However, I don't get the impression this will
fit into current git very well, because users would need to turn their current
"git push", into a "git merge master;git push"
I'm interested in other ideas to address this.
I know that all of what I wrote above seems strange if you don't buy into the
design assumptions. That it's critical to share a single server-repository,
that it's critical to have a shared 'well known' branch that only trusts
clients to add new changes to, etc.. However, these are important.
^ permalink raw reply
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection
From: Junio C Hamano @ 2008-06-25 5:30 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <20080625044409.GE11793@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Pasky also has to update:
>
> $ git ls-remote --upload-pack='git upload-pack' repo.or.cz:/srv/git/egit.git
> fatal: unrecognized command 'git upload-pack '/srv/git/egit.git''
> fatal: The remote end hung up unexpectedly
Of course. I am assuming that he runs git-shell for user account, and
that's what the change in 'next' is about.
^ 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