* [PATCH 5/5] Avoid "test -o" and "test -a" which are not POSIX, only XSI.
From: Ralf Wildenhues @ 2007-11-06 20:20 UTC (permalink / raw)
To: git
In-Reply-To: <20071106201518.GA6361@ins.uni-bonn.de>
---
git-clone.sh | 2 +-
git-commit.sh | 4 ++--
git-merge-stupid.sh | 2 +-
git-merge.sh | 4 ++--
git-mergetool.sh | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 3f00693..1ae137a 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -462,7 +462,7 @@ then
case "$no_checkout" in
'')
- test "z$quiet" = z -a "z$no_progress" = z && v=-v || v=
+ test "z$quiet" = z && test "z$no_progress" = z && v=-v || v=
git read-tree -m -u $v HEAD HEAD
esac
fi
diff --git a/git-commit.sh b/git-commit.sh
index fcb8443..78fe518 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -50,7 +50,7 @@ run_status () {
export GIT_INDEX_FILE
fi
- if test "$status_only" = "t" -o "$use_status_color" = "t"; then
+ if test "$status_only" = "t" || test "$use_status_color" = "t"; then
color=
else
color=--nocolor
@@ -290,7 +290,7 @@ t,,[1-9]*)
die "No paths with -i does not make sense." ;;
esac
-if test ! -z "$templatefile" -a -z "$log_given"
+if test ! -z "$templatefile" && test -z "$log_given"
then
if test ! -f "$templatefile"
then
diff --git a/git-merge-stupid.sh b/git-merge-stupid.sh
index f612d47..95adbb3 100755
--- a/git-merge-stupid.sh
+++ b/git-merge-stupid.sh
@@ -44,7 +44,7 @@ case "$bases" in
2>/dev/null || continue
# Count the paths that are unmerged.
cnt=`GIT_INDEX_FILE=$G git ls-files --unmerged | wc -l`
- if test $best_cnt -le 0 -o $cnt -le $best_cnt
+ if test $best_cnt -le 0 || test $cnt -le $best_cnt
then
best=$c
best_cnt=$cnt
diff --git a/git-merge.sh b/git-merge.sh
index c2092a2..b6a35d4 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -124,7 +124,7 @@ merge_name () {
git show-ref -q --verify "refs/heads/$truname" 2>/dev/null
then
echo "$rh branch '$truname' (early part) of ."
- elif test "$remote" = "FETCH_HEAD" -a -r "$GIT_DIR/FETCH_HEAD"
+ elif test "$remote" = "FETCH_HEAD" && test -r "$GIT_DIR/FETCH_HEAD"
then
sed -e 's/ not-for-merge / /' -e 1q \
"$GIT_DIR/FETCH_HEAD"
@@ -478,7 +478,7 @@ do
git diff-files --name-only
git ls-files --unmerged
} | wc -l`
- if test $best_cnt -le 0 -o $cnt -le $best_cnt
+ if test $best_cnt -le 0 || test $cnt -le $best_cnt
then
best_strategy=$strategy
best_cnt=$cnt
diff --git a/git-mergetool.sh b/git-mergetool.sh
index a68b403..9f7386b 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -167,7 +167,7 @@ merge_file () {
local_present && git cat-file blob ":2:$prefix$path" >"$LOCAL" 2>/dev/null
remote_present && git cat-file blob ":3:$prefix$path" >"$REMOTE" 2>/dev/null
- if test -z "$local_mode" -o -z "$remote_mode"; then
+ if test -z "$local_mode" || test -z "$remote_mode"; then
echo "Deleted merge conflict for '$path':"
describe_file "$local_mode" "local" "$LOCAL"
describe_file "$remote_mode" "remote" "$REMOTE"
--
1.5.3.5.561.g140d
^ permalink raw reply related
* Re: git pull opinion
From: Ralf Wildenhues @ 2007-11-06 20:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Benoit Sigoure, Aghiles, git list
In-Reply-To: <Pine.LNX.4.64.0711061154310.4362@racer.site>
* Johannes Schindelin wrote on Tue, Nov 06, 2007 at 12:59:07PM CET:
> On Tue, 6 Nov 2007, Ralf Wildenhues wrote:
> >
> > Since I simply don't have the time resources to just implement that,
> > I'll thank you for your attention and go back to lurking mode now.
>
> You might as well be honest, and say that they are not time constraints,
> but lack of motivation.
No. I will not do it, because the marginal cost of getting to
know not only git but also its source is too high for my precious
time ATM. Maybe next year.
Will you do it for me if I buy you some beer? If I promise to
(continue to) proofread git documentation for a couple of months?
If I do more audit of git's shell code, searching for nonportable
constructs? Or if I promise to try to help you with any autotools
issue you might have? Or would money be needed? This:
> Implementing that feature would be a piece of cake [...]
doesn't sound like it, but I would understand very well if it
needed that.
Please consider that division of work really can be advantageous
and that not all git users want to be or can be developers at all
times.
Cheers,
Ralf
^ permalink raw reply
* Re: [PATCH 3/5] Replace $((...)) with expr invocations.
From: Ralf Wildenhues @ 2007-11-06 20:26 UTC (permalink / raw)
To: git
In-Reply-To: <20071106201809.GD6361@ins.uni-bonn.de>
* Ralf Wildenhues wrote on Tue, Nov 06, 2007 at 09:18:09PM CET:
> ---
> git-filter-branch.sh | 4 ++--
> git-rebase--interactive.sh | 8 ++++----
> git-rebase.sh | 8 ++++----
> 3 files changed, 10 insertions(+), 10 deletions(-)
Hmm, maybe this one is overkill. $((...)) is POSIX, I temporarily
forgot (thanks Benoît!).
I'm unsure whether git targets non-POSIX Bourne shells like Solaris
/bin/sh. That would however mean replacing stuff like $(cmd) with
`cmd` as well, and from grepping the source it looks like you'd rather
avoid that.
Cheers,
Ralf
^ permalink raw reply
* [PATCH] Give git-am back the ability to add Signed-off-by lines.
From: Johannes Sixt @ 2007-11-06 20:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pierre Habouzit
This was lost in the migration to git-rev-parse --parseopt by commit
78443d90491c1b82afdffc3d5d2ab8c1a58928b5.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git-am.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 876b973..e5af955 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -131,7 +131,7 @@ do
binary=t ;;
-3|--3way)
threeway=t ;;
- -s--signoff)
+ -s|--signoff)
sign=t ;;
-u|--utf8)
utf8=t ;; # this is now default
--
1.5.3.4.315.g2ce38
^ permalink raw reply related
* Re: [PATCH 0/5] some shell portability fixes
From: Junio C Hamano @ 2007-11-06 20:46 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20071106201518.GA6361@ins.uni-bonn.de>
All missing Signed-off-by: lines.
[1/5] In addition to take advantage of the fact that the RHS of
assignment is not split, I'd prefer replacing `` with $()
with these cases. Much easier to read if your shell
supports it (and all the modern ones do).
[2/5] Gaah, AIX sed X-<. I am not opposed to this patch but
would want to get Yays from people with non GNU sed. Is
busybox sed good enough to grok our scripts these days?
Please ask help and collect Acks at least from folks on
Solaris, MacOS, FBSD, and OBSD.
[3/5] Arithmetic expansion. Have you caught _all_ of them, or
is this patch about only the ones you noticed?
We used to have expr all over the place as I was one of
the primary authors of our shell scripts, and I am
"80-ish" old fashioned. There was a long discussion on
scripts in the past and we ruled that $(( ... )) is easier
to read and supported widely enough to be acceptable.
This patch goes backwards. Will drop, unless you can
demonstrate that an implementation does not support it and
convince people that the implementation is important.
/bin/sh on Solaris does not count as you can configure
SHELL_PATH to point at xpg4 shell or ksh on that platform.
[4/5] I wonder if use of fgrep would be easier to read and more
portable with this one:
name=$( GIT_CONFIG=.gitmodules \
git config --get-regexp '^submodule\..*\.path$' |
fgrep "submodule.$1.path" |
sed -e 's/^submodule\.\(.*\)\.path$/\1/'
)
[5/5] Again, have you covered all of them? I am not opposed to
this one, although I am a bit curious who lacks -a/-o in
practice.
^ permalink raw reply
* Re: [PATCH 0/5] some shell portability fixes
From: Mike Hommey @ 2007-11-06 21:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ralf Wildenhues, git
In-Reply-To: <7v8x5bgl04.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 06, 2007 at 12:46:35PM -0800, Junio C Hamano wrote:
> [5/5] Again, have you covered all of them? I am not opposed to
> this one, although I am a bit curious who lacks -a/-o in
> practice.
Solaris's /bin/sh, but it already doesn't support $() and other stuff
used all over the place in git, so it's not like it's changing anything.
Maybe some other obscure old crappy shell ?
Mike
^ permalink raw reply
* Re: [PATCH 3/5] Replace $((...)) with expr invocations.
From: Junio C Hamano @ 2007-11-06 21:06 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20071106202600.GH6361@ins.uni-bonn.de>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> * Ralf Wildenhues wrote on Tue, Nov 06, 2007 at 09:18:09PM CET:
>> ---
>> git-filter-branch.sh | 4 ++--
>> git-rebase--interactive.sh | 8 ++++----
>> git-rebase.sh | 8 ++++----
>> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> Hmm, maybe this one is overkill. $((...)) is POSIX, I temporarily
> forgot (thanks Benoît!).
>
> I'm unsure whether git targets non-POSIX Bourne shells like Solaris
> /bin/sh. That would however mean replacing stuff like $(cmd) with
> `cmd` as well, and from grepping the source it looks like you'd rather
> avoid that.
For git, two rough rules are:
- Most importantly, we never say "It's in POSIX; we'll happily
screw your system that does not conform." We live in the
real world.
- However, we often say "Let's stay away from that construct,
it's not even in POSIX".
For shell scripts specifically (not exhaustive):
- We prefer $( ... ) for command substitution; unlike ``, it
properly nests. It should have been the way Bourne spelled
it from day one, but unfortunately isn't.
- We use ${parameter-word} and its [-=?+] siblings, and their
colon'ed "unset or null" form.
- We use ${parameter#word} and its [#%] siblings, and their
doubled "longest matching" form.
- We use Arithmetic Expansion $(( ... )).
- No "Substring Expansion" ${parameter:offset:length}.
- No shell arrays.
- No strlen ${#parameter}.
- No regexp ${parameter/pattern/string}.
- We do not use Process Substitution <(list) or >(list).
- We prefer "test" over "[ ... ]".
- We do not write noiseword "function" in front of shell
functions.
^ permalink raw reply
* Re: [PATCH] Give git-am back the ability to add Signed-off-by lines.
From: Junio C Hamano @ 2007-11-06 21:07 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Pierre Habouzit
In-Reply-To: <200711062133.58903.johannes.sixt@telecom.at>
Good eyes, thanks.
^ permalink raw reply
* Re: [PATCH] Rearrange git-format-patch synopsis to improve clarity.
From: David Symonds @ 2007-11-06 21:08 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Junio C Hamano, git
In-Reply-To: <473081C2.7060106@freescale.com>
On 11/7/07, Jon Loeliger <jdl@freescale.com> wrote:
> David Symonds wrote:
> > Now that I look at it again, it seems the long options look quite
> > inconsistent. I think it should be either
> > --numbered-files/--no-numbered-files or --numbered/--no-numbered. My
> > preference is with the latter (for brevity), but that breaks
> > backward-compatibility.
> >
> > Would you accept a patch that changed --numbered-files to --numbered,
> > and kept the former as a synonym?
>
> There are two forms of numbered file output names:
> the traditional "0001-Foo-the-bar" and just "1" styles.
> Please don't break that. Both are needed.
Oh, I certainly wasn't proposing removing any functionality; merely
renaming the option to select it so as to be consistent.
Dave.
^ permalink raw reply
* Re: [PATCH 0/5] some shell portability fixes
From: Ralf Wildenhues @ 2007-11-06 21:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x5bgl04.fsf@gitster.siamese.dyndns.org>
Hello Junio,
* Junio C Hamano wrote on Tue, Nov 06, 2007 at 09:46:35PM CET:
> All missing Signed-off-by: lines.
Oops. Sorry.
> [1/5] In addition to take advantage of the fact that the RHS of
> assignment is not split, I'd prefer replacing `` with $()
> with these cases. Much easier to read if your shell
> supports it (and all the modern ones do).
OK.
> [2/5] Gaah, AIX sed X-<. I am not opposed to this patch but
> would want to get Yays from people with non GNU sed. Is
> busybox sed good enough to grok our scripts these days?
> Please ask help and collect Acks at least from folks on
> Solaris, MacOS, FBSD, and OBSD.
FWIW, I have little experience with busybox sed, but for the others here
you go: With
echo axbyc | sed 's,x,\n,; s,y,\
,'
I get on OpenBSD, FreeBSD, Solaris, and Darwin (minus indentation):
anb
c
GNU sed gives
a
b
c
> [3/5] Arithmetic expansion. Have you caught _all_ of them, or
> is this patch about only the ones you noticed?
I have grepped *.sh. But let's drop that, I see that it goes backwards.
> [4/5] I wonder if use of fgrep would be easier to read and more
> portable with this one:
>
> name=$( GIT_CONFIG=.gitmodules \
> git config --get-regexp '^submodule\..*\.path$' |
> fgrep "submodule.$1.path" |
> sed -e 's/^submodule\.\(.*\)\.path$/\1/'
> )
Certainly easier to read. But fgrep itself is not portable (it could be
grep -F). Also, isn't the $1 to be matched at the end, after a "="
here? FWIW the pattern I posted has survived a few years in Automake,
so there is some hope that it works.
> [5/5] Again, have you covered all of them?
No, oops again. As I searched for `test.*-[oa]' I have missed line
wraps and [ ... -o ... ].
> I am not opposed to
> this one, although I am a bit curious who lacks -a/-o in
> practice.
Hmm, good question. I actually don't know whether there is a shell
that isn't ruled out by $() anyway. Let's drop that one, too, then.
Cheers,
Ralf
^ permalink raw reply
* git-bundle questions
From: Matthew Booth @ 2007-11-06 20:54 UTC (permalink / raw)
To: git
First a question: when creating a git bundle, is it possible to include
tags?
Secondly, has anybody given any thought to allowing a user to create a
bundle from any of the web front-ends? The reason for this request is
that I've been doing some work for a company where only corporate
standard desktops have internet access. They run Windows, and you can't
install additional software on them. This makes interacting with an
external git repository from my development servers problematic. Git
bundles do at least make this possible, but I have to create a bundle on
my laptop when I'm at home and transfer it to a server when I get to the
office. This would be a whole lot easier if I could just download the
bundle at the office.
Thanks,
Matt
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Robin Rosenberg @ 2007-11-06 21:21 UTC (permalink / raw)
To: Mike Hommey
Cc: Johannes Schindelin, Junio C Hamano, Steven Grimm,
Pierre Habouzit, git
In-Reply-To: <20071106201324.GA30262@glandium.org>
tisdag 06 november 2007 skrev Mike Hommey:
> Maybe the documentation could emphasise on how to undo things when the
> user makes mistakes.
> Sometimes, saving your repo can be as simple as git reset --hard HEAD@{1}.
> This is not, unfortunately, a works-for-all-cases command.
Yea, git-undo(7).
-- robin
^ permalink raw reply
* [PATCH] make display of total transferred fully accurate
From: Nicolas Pitre @ 2007-11-06 21:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The minimum delay of 1/2 sec between successive throughput updates might
not have been elapsed when display_throughput() is called for the last
time, potentially making the display of total transferred bytes not
right when progress is said to be done.
Let's force an update of the throughput display as well when the
progress is complete. As a side effect, the total transferred will
always be displayed even if the actual transfer rate doesn't have time
to kickin.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
It was seriously bugging me that the total still didn't match the size
of received packs exactly, even after my previous attempt at fixing it.
diff --git a/progress.c b/progress.c
index a963bd8..2a5a2da 100644
--- a/progress.c
+++ b/progress.c
@@ -14,11 +14,12 @@
#define TP_IDX_MAX 8
struct throughput {
+ off_t curr_total;
off_t prev_total;
struct timeval prev_tv;
unsigned int avg_bytes;
- unsigned int last_bytes[TP_IDX_MAX];
unsigned int avg_misecs;
+ unsigned int last_bytes[TP_IDX_MAX];
unsigned int last_misecs[TP_IDX_MAX];
unsigned int idx;
char display[32];
@@ -109,6 +110,30 @@ static int display(struct progress *progress, unsigned n, int done)
return 0;
}
+static void throughput_string(struct throughput *tp, off_t total,
+ unsigned int rate)
+{
+ int l = sizeof(tp->display);
+ if (total > 1 << 30) {
+ l -= snprintf(tp->display, l, ", %u.%2.2u GiB",
+ (int)(total >> 30),
+ (int)(total & ((1 << 30) - 1)) / 10737419);
+ } else if (total > 1 << 20) {
+ l -= snprintf(tp->display, l, ", %u.%2.2u MiB",
+ (int)(total >> 20),
+ ((int)(total & ((1 << 20) - 1)) * 100) >> 20);
+ } else if (total > 1 << 10) {
+ l -= snprintf(tp->display, l, ", %u.%2.2u KiB",
+ (int)(total >> 10),
+ ((int)(total & ((1 << 10) - 1)) * 100) >> 10);
+ } else {
+ l -= snprintf(tp->display, l, ", %u bytes", (int)total);
+ }
+ if (rate)
+ snprintf(tp->display + sizeof(tp->display) - l, l,
+ " | %u KiB/s", rate);
+}
+
void display_throughput(struct progress *progress, off_t total)
{
struct throughput *tp;
@@ -124,11 +149,12 @@ void display_throughput(struct progress *progress, off_t total)
if (!tp) {
progress->throughput = tp = calloc(1, sizeof(*tp));
if (tp) {
- tp->prev_total = total;
+ tp->prev_total = tp->curr_total = total;
tp->prev_tv = tv;
}
return;
}
+ tp->curr_total = total;
/*
* We have x = bytes and y = microsecs. We want z = KiB/s:
@@ -149,39 +175,21 @@ void display_throughput(struct progress *progress, off_t total)
misecs += (int)(tv.tv_usec - tp->prev_tv.tv_usec) / 977;
if (misecs > 512) {
- int l = sizeof(tp->display);
- unsigned int count = total - tp->prev_total;
+ unsigned int count, rate;
+
+ count = total - tp->prev_total;
tp->prev_total = total;
tp->prev_tv = tv;
tp->avg_bytes += count;
tp->avg_misecs += misecs;
-
- if (total > 1 << 30) {
- l -= snprintf(tp->display, l, ", %u.%2.2u GiB",
- (int)(total >> 30),
- (int)(total & ((1 << 30) - 1)) / 10737419);
- } else if (total > 1 << 20) {
- l -= snprintf(tp->display, l, ", %u.%2.2u MiB",
- (int)(total >> 20),
- ((int)(total & ((1 << 20) - 1))
- * 100) >> 20);
- } else if (total > 1 << 10) {
- l -= snprintf(tp->display, l, ", %u.%2.2u KiB",
- (int)(total >> 10),
- ((int)(total & ((1 << 10) - 1))
- * 100) >> 10);
- } else {
- l -= snprintf(tp->display, l, ", %u bytes", (int)total);
- }
- snprintf(tp->display + sizeof(tp->display) - l, l,
- " | %u KiB/s", tp->avg_bytes / tp->avg_misecs);
-
+ rate = tp->avg_bytes / tp->avg_misecs;
tp->avg_bytes -= tp->last_bytes[tp->idx];
tp->avg_misecs -= tp->last_misecs[tp->idx];
tp->last_bytes[tp->idx] = count;
tp->last_misecs[tp->idx] = misecs;
tp->idx = (tp->idx + 1) % TP_IDX_MAX;
+ throughput_string(tp, total, rate);
if (progress->last_value != -1 && progress_update)
display(progress, progress->last_value, 0);
}
@@ -225,6 +233,12 @@ void stop_progress(struct progress **p_progress)
*p_progress = NULL;
if (progress->last_value != -1) {
/* Force the last update */
+ struct throughput *tp = progress->throughput;
+ if (tp) {
+ unsigned int rate = !tp->avg_misecs ? 0 :
+ tp->avg_bytes / tp->avg_misecs;
+ throughput_string(tp, tp->curr_total, rate);
+ }
progress_update = 1;
display(progress, progress->last_value, 1);
}
^ permalink raw reply related
* Re: [PATCH] git-cvsimport: Add -N option to force a new import
From: Piet Delaney @ 2007-11-06 21:35 UTC (permalink / raw)
To: git; +Cc: piet delaney
In-Reply-To: <1194320170.21645.72.camel@localhost>
Matt McCutchen wrote:
> On Wed, 2007-10-24 at 20:17 -0700, Junio C Hamano wrote:
>> Matt McCutchen <matt@mattmccutchen.net> writes:
>>
>>> I had a git repository for development of rsync and wanted to start
>>> importing the upstream CVS with git-cvsimport, but git-cvsimport saw
>>> that the git repository existed and insisted on updating a previous
>>> import. This patch adds an -N option to git-cvsimport to force a new
>>> import and updates the documentation appropriately.
>> Sounds like a useful addition. Tests?
>
> Good call! As I was dismayed to discover, the existing files in the
> working tree confused the import,\
What's the confusion? I thought updating of the git repo from cvs
worked. Sigh.
-piet
> so -N as I implemented it is useless.
> I ended up doing the import a different way; I'll notify the list if I
> get around to implementing -N properly.
>
> Matt
>
^ permalink raw reply
* Re: [PATCH] Documentation: enhanced "git for CVS users" doc about shared repositories
From: Francesco Pretto @ 2007-11-06 21:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x5cmern.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Francesco Pretto <ceztkoml@gmail.com>
---
More detailed instructions on how to set up shared repositories.
Removed an old reference to the need of setting umask of ssh
users of shared repositories.
Added a reference to "git for CVS users" doc in git-init manual.
Documentation/cvs-migration.txt | 61 +++++++++++++++++++++++++++++++++++----
Documentation/git-init.txt | 7 ++++
2 files changed, 62 insertions(+), 6 deletions(-)
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
index 3b6b494..849b403 100644
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -71,7 +71,40 @@ Setting Up a Shared Repository
We assume you have already created a git repository for your project,
possibly created from scratch or from a tarball (see the
link:tutorial.html[tutorial]), or imported from an already existing CVS
-repository (see the next section).
+repository (see the next section). Moreover, we assume you can write in a
+public accessible directory and give other users the permission to do so.
+You could need or not admin privileges to do so, depending on your
+system configuration and how you decide to export the repository.
+
+It's recommended, but not strictly necessary, to create a specific group for
+every project/repository you'll want to create, so it will be easier to give
+or prevent access of users to specific repositories. With admin privilege launch:
+
+------------------------------------------------
+$ groupadd $group
+------------------------------------------------
+
+If you want to add an user to this group, launch:
+
+------------------------------------------------
+$ usermod -a -G $group $username
+------------------------------------------------
+
+In our example, we will store the shared repository in the /pub dir, so the
+user creating it will need write permission there. There's no problems if you
+choose another directory, but you'll have to ensure it will be accessible by
+other users, on local or by remote (this could be not the case of home
+directories).
+
+If you just want to create a directory that is writable by every users that have
+a local account, launch with privileged credentials:
+
+------------------------------------------------
+$ mkdir /pub
+$ chmod a+w,+t /pub
+------------------------------------------------
+
+Now you can proceed with an unprivileged user.
Assume your existing repo is at /home/alice/myproject. Create a new "bare"
repository (a repository without a working tree) and fetch your project into
@@ -84,21 +117,37 @@ $ git --bare init --shared
$ git --bare fetch /home/alice/myproject master:master
------------------------------------------------
+If you previously decided to create a specific group for the committers of the
+repository, assign its ownership to that group (you'll have to be a member of it
+or switch to privileged credentials):
+
+------------------------------------------------
+$ chgrp -R $group /pub/my-repo.git
+------------------------------------------------
+
Next, give every team member read/write access to this repository. One
easy way to do this is to give all the team members ssh access to the
machine where the repository is hosted. If you don't want to give them a
full shell on the machine, there is a restricted shell which only allows
users to do git pushes and pulls; see gitlink:git-shell[1].
-Put all the committers in the same group, and make the repository
-writable by that group:
+The following two commands will require admin privileges; first, enable
+git-shell putting it on the trusted shells list of the system:
------------------------------------------------
-$ chgrp -R $group /pub/my-repo.git
+$ echo `which git-shell` >> /etc/shells
+------------------------------------------------
+
+Now, let's create the commit users:
+
+------------------------------------------------
+$ useradd -g $group -s `which git-shell` $username
------------------------------------------------
-Make sure committers have a umask of at most 027, so that the directories
-they create are writable and searchable by other group members.
+These users will be enabled to push on repositories owned by the group $group.
+Later, you can give access to other projects simply by adding them to
+other groups. Similarly, you can prevent access to repositories simply
+removing those users from related groups.
Importing a CVS archive
-----------------------
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 07484a4..f5f363d 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -101,6 +101,13 @@ $ git-add . <2>
<2> add all existing file to the index
+SHARED REPOSITORIES
+-------------------
+
+Please refer to link:cvs-migration.html[git for CVS users], section "Setting Up
+a Shared Repository", for details on how to set up shared repositories.
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
^ permalink raw reply related
* Re: git-bundle questions
From: Jakub Narebski @ 2007-11-06 21:49 UTC (permalink / raw)
To: git
In-Reply-To: <1194382443.5568.13.camel@localhost.localdomain>
Matthew Booth wrote:
> Secondly, has anybody given any thought to allowing a user to create a
> bundle from any of the web front-ends? The reason for this request is
> that I've been doing some work for a company where only corporate
> standard desktops have internet access. They run Windows, and you can't
> install additional software on them. This makes interacting with an
> external git repository from my development servers problematic. Git
> bundles do at least make this possible, but I have to create a bundle on
> my laptop when I'm at home and transfer it to a server when I get to the
> office. This would be a whole lot easier if I could just download the
> bundle at the office.
I have though about adding such support to gitweb. The problem lies
in how to specify the commits and refs to bundle.
Perhaps separate CGI script would be an answer.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Alex Riesen @ 2007-11-06 21:50 UTC (permalink / raw)
To: Karl Hasselström
Cc: Johannes Schindelin, Jeff King, Michael Cohen, Gerrit Pape,
Fernando J. Pereda, git, Junio C Hamano
In-Reply-To: <20071106163548.GA8207@diana.vm.bytemark.co.uk>
Karl Hasselström, Tue, Nov 06, 2007 17:35:48 +0100:
> On 2007-11-06 15:51:09 +0000, Johannes Schindelin wrote:
> > On Tue, 6 Nov 2007, Jeff King wrote:
> > > On Tue, Nov 06, 2007 at 11:01:03AM +0000, Johannes Schindelin wrote:
> > > > I fail to see how the absence of one of cur/ or new/ can lead to
> > > > the absence of patches. You could forget to save some patches,
> > > > yes, but the presence of cur/ and new/ is no indicator for that.
> > >
> > > Read my message again. Alex is proposing ignoring errors in
> > > opening the directories; I am proposing ignoring such errors
> > > _only_ when the error is that the directory does not exist.
> > >
> > > IOW, if there is some other error in opening the directory, it
> > > should be fatal, because you might be missing patches.
> >
> > Yeah, sorry, I missed that.
>
> I think it might actually not be totally unreasonable to error out
> unless both directories exist. From
> http://www.qmail.org/qmail-manual-html/man5/maildir.html:
>
> A directory in maildir format has three subdirectories, all on the
> same filesystem: tmp, new, and cur.
>
> In other words, if it doesn't have these three directories, it isn't a
> Maildir directory.
On the same line of reasoning, if opening a ".../cur" fails with ENOTDIR,
it must be not a Maildir...
> On the other hand, one could argue that requiring both dirs to exist
> is being too picky.
...which MUST NOT mean it does not contain useful patches.
IOW, the tool can try and apply everything it finds.
If user told it to get patches from the...whatever, then the patches
should it get and damn qmail.
^ permalink raw reply
* git-rev-list diff options broken
From: Han-Wen Nienhuys @ 2007-11-06 22:14 UTC (permalink / raw)
To: git
Hi,
the git-rev-list manpage says
**
Diff Formatting
~~~~~~~~~~~~~~~
Below are listed options that control the formatting of diff output.
Some of them are specific to gitlink:git-rev-list[1], however other diff
options may be given. See gitlink:git-diff-files[1] for more options.
**
however, the source code says
if ((!list &&
(!(revs.tag_objects||revs.tree_objects||revs.blob_objects) &&
!revs.pending.nr)) ||
revs.diff)
usage(rev_list_usage);
so any attempt at showing diffs with git-rev-list will fail. What's
the deal with this?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: git-rev-list diff options broken
From: Han-Wen Nienhuys @ 2007-11-06 22:15 UTC (permalink / raw)
To: git
In-Reply-To: <f329bf540711061414k1627521bvaf4a7a06460cc3fd@mail.gmail.com>
2007/11/6, Han-Wen Nienhuys <hanwenn@gmail.com>:
> so any attempt at showing diffs with git-rev-list will fail. What's
> the deal with this?
this is with
git version 1.5.3.5.576.gfe6193
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Johannes Schindelin @ 2007-11-06 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, Steven Grimm, git
In-Reply-To: <7vir4fgnz1.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 6 Nov 2007, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > On Tue, Nov 06, 2007 at 06:27:54PM +0000, Johannes Schindelin wrote:
> >
> >> On Tue, 6 Nov 2007, Junio C Hamano wrote:
> >>
> >> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >> >
> >> > > Well, I think that _if_ we allow "git revert <path>" to mean
> >> > > "revert the changes to <path>, relative to the index" (which
> >> > > would be the same as "git checkout <path>"), then committing that
> >> > > change just does not make sense.
> >> > >
> >> > > And it is this behaviour that people are seeking, not "git revert
> >> > > <commit> <path>".
> >> >
> >> > Heh, I found this in the recent log somewhere.
> >> >
> >> > <gitte> Really, I wonder how difficult git is for people who are not
> >> > brainwashed by cvs/svn, and unfortunately enough, partly by bzr
> >> > and hg.
> >> > <gitte> From a user perspective, you might be correct. But then we
> >> > have to add 1000 commands to reflect the English language.
> >> > <gitte> Not what I want. [06:46]
> >> >
> >> > I am wondering who said it ;-).
> >>
> >> Now, that is not fair, using my own words against me ;-)
> >
> > That's very funny actually :]
>
> Yeah, it was doubly funny after I saw you posted a list of "$scm revert"
> and Dscho still sided with you in that thread.
Hey, I had my nice 5 minutes for the day, so give me a break!
;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Johannes Schindelin @ 2007-11-06 22:25 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Mike Hommey, Junio C Hamano, Steven Grimm, Pierre Habouzit, git
In-Reply-To: <200711062221.58475.robin.rosenberg.lists@dewire.com>
Hi,
On Tue, 6 Nov 2007, Robin Rosenberg wrote:
> tisdag 06 november 2007 skrev Mike Hommey:
> > Maybe the documentation could emphasise on how to undo things when the
> > user makes mistakes.
> > Sometimes, saving your repo can be as simple as git reset --hard HEAD@{1}.
> > This is not, unfortunately, a works-for-all-cases command.
>
> Yea, git-undo(7).
In related news, I know a few users who need an un-rm-rf. Anyone?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] pretty=format: Avoid some expensive calculations when not needed
From: René Scharfe @ 2007-11-06 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vejf4kwry.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Junio C Hamano schrieb: ...
>>> Instead of allocating a separate array and freeing at the end,
>>> wouldn't it make more sense to have a bitfield that records what
>>> is used by the format string inside the array elements?
>> How about (ab)using the value field? Let interp_find_active() mark
>> unneeded entries with NULL, and the rest with some cookie. All
>> table entries with non-NULL values need to be initialized.
>> interp_set_entry() needs to be aware of this cookie, as it mustn't
>> free() it. The cookie could be the address of a static char* in
>> interpolate.c.
>
> Sorry, where is this aversion to making the struct a bit larger
> coming from?
Not from the rational part of my brain, for sure. The following on
top of Dscho's second patch? (A char would be smaller, but a bitfield
documents the intent better.)
diff --git a/interpolate.c b/interpolate.c
index 80eeb36..1e4ccaf 100644
--- a/interpolate.c
+++ b/interpolate.c
@@ -103,22 +103,21 @@ unsigned long interpolate(char *result, unsigned long reslen,
return newlen;
}
-char *interp_find_active(const char *orig,
- const struct interp *interps, int ninterps)
+void interp_find_active(const char *orig, struct interp *interps, int ninterps)
{
- char *result = xcalloc(1, ninterps);
char c;
int i;
+ for (i = 0; i < ninterps; i++)
+ interps[i].active = 0;
+
while ((c = *(orig++)))
if (c == '%')
/* Try to match an interpolation string. */
for (i = 0; i < ninterps; i++)
if (!prefixcmp(orig, interps[i].name + 1)) {
- result[i] = 1;
+ interps[i].active = 1;
orig += strlen(interps[i].name + 1);
break;
}
-
- return result;
}
diff --git a/interpolate.h b/interpolate.h
index 2d197c5..a8ee6b9 100644
--- a/interpolate.h
+++ b/interpolate.h
@@ -14,6 +14,7 @@
struct interp {
const char *name;
char *value;
+ unsigned active:1;
};
extern void interp_set_entry(struct interp *table, int slot, const char *value);
@@ -22,7 +23,6 @@ extern void interp_clear_table(struct interp *table, int ninterps);
extern unsigned long interpolate(char *result, unsigned long reslen,
const char *orig,
const struct interp *interps, int ninterps);
-extern char *interp_find_active(const char *orig,
- const struct interp *interps, int ninterps);
+extern void interp_find_active(const char *orig, struct interp *interps, int ninterps);
#endif /* INTERPOLATE_H */
^ permalink raw reply related
* Re: [PATCH] Give git-am back the ability to add Signed-off-by lines.
From: Pierre Habouzit @ 2007-11-06 22:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <200711062133.58903.johannes.sixt@telecom.at>
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
On Tue, Nov 06, 2007 at 08:33:58PM +0000, Johannes Sixt wrote:
> This was lost in the migration to git-rev-parse --parseopt by commit
> 78443d90491c1b82afdffc3d5d2ab8c1a58928b5.
>
> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> ---
> git-am.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-am.sh b/git-am.sh
> index 876b973..e5af955 100755
> --- a/git-am.sh
> +++ b/git-am.sh
> @@ -131,7 +131,7 @@ do
> binary=t ;;
> -3|--3way)
> threeway=t ;;
> - -s--signoff)
> + -s|--signoff)
Gaaaah. One more case of t/f finger-slip
> sign=t ;;
> -u|--utf8)
> utf8=t ;; # this is now default
> --
> 1.5.3.4.315.g2ce38
>
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git-log -p --raw broken?
From: Han-Wen Nienhuys @ 2007-11-06 22:48 UTC (permalink / raw)
To: git
Hi,
I'm trying to get a list of
git diff-tree -t -r --raw COMMITTISH
where COMMITTISH comes from git-rev-list, using a limited number of
processes. The manual page suggests that I should be able to do
git log -p --raw COMMIT-RANGE
however, when I try that, I get always get the same style output,
which is the (to me: useless) human readable output.
Am I missing something?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: git-log -p --raw broken?
From: Han-Wen Nienhuys @ 2007-11-06 23:03 UTC (permalink / raw)
To: git
In-Reply-To: <f329bf540711061448iab9d4a9q37e13b846dbc5ff1@mail.gmail.com>
2007/11/6, Han-Wen Nienhuys <hanwenn@gmail.com>:
> I'm trying to get a list of
>
> git diff-tree -t -r --raw COMMITTISH
>
> [..]
> Am I missing something?
I probably am, never mind this message.
\
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ 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