* Re: using-topic-branches.txt
From: J. Bruce Fields @ 2005-12-19 15:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff Garzik, git
In-Reply-To: <7v64plmz1e.fsf@assigned-by-dhcp.cox.net>
On Sun, Dec 18, 2005 at 09:33:17PM -0800, Junio C Hamano wrote:
> Jeff Garzik <jgarzik@pobox.com> writes:
>
> > master.kernel.org is non-public, so it shouldn't be mentioned in
> > documentation...
>
> I'm willing to be persuaded otherwise, but the reason I changed
> this part was twofold:
>
> - The documentation is meant to be an example for subsystem
> maintainers, who are "non-public" people anyway.
There are people without kernel.org accounts who do similar sorts of
work.
--b.
^ permalink raw reply
* Branches and all commits
From: Jon Nelson @ 2005-12-19 15:15 UTC (permalink / raw)
To: git
Should *all* commits be reachable via at least one branch? I ran into a
situation this weekend that has me a little confused. I had performed a
number of commits and such and I noticed that the author and committer
info had suboptimal values. A bit of searching led me to a comment made
by Linus that basically said "go hack git-convert-objects", which I did.
After performing git-convert-objects on every commit object in
.git/refs/heads and the requisite pruning, etc... just about everything
looked fine. However, I still had a long series of commits that
contained the wrong information. Further inspection makes it appear as
though these commits are not reachable via any branch, although they are
/all/ reachable via a series of tags. I worked around the problem by
further modifying git-convert-objects to also understand tags (at least
the basic ones I've got) and that's all taken care of, but the question
remains: should *all* commit objects be reachable by at least one
branch?
--
Jon Nelson <jnelson-git@jamponi.net>
^ permalink raw reply
* Best way to use gitweb with a non-utf8 git repository
From: Romano Giannetti @ 2005-12-19 13:55 UTC (permalink / raw)
To: git
Hi,
I am trying to start using git for a little project I have here. I
stumbled with a small difficulty with gitweb.
For historical reasons the 3 or 4 files in my project that are not ascii
or binary blobs are encoded in iso-8859-1. I know that utf8 is better,
but I cannot do anything to enforce it... Well, git obviously has no
problem, "all-is-a-byte-stream" is a great thing. The only problem is in
"tree" view of gitweb, were the files with iso-8859-1 are filled with
"invalid unicode sequence" symbols. I horribly hacked gitweb like this:
--- /home/romano/software/downloads/gitweb.cgi 2005-12-16 12:10:46.000000000 +0100
+++ /var/www/cgi-bin/gitweb.cgi 2005-12-19 12:20:25.000000000 +0100
@@ -221,6 +221,7 @@
# replace invalid utf8 character with SUBSTITUTION sequence
sub esc_html {
my $str = shift;
+ Encode::from_to($str, "iso-8859-1", "utf8");
$str = decode("utf8", $str, Encode::FB_DEFAULT);
$str = escapeHTML($str);
return $str;
but I wonder, is there a way to say gitweb "if invalid utf-8 is found,
assume whatever-encoding-is encoding"?
Thanks,
Romano
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569
http://www.dea.icai.upcomillas.es/romano/
^ permalink raw reply
* [PATCH] cg-update quotes too much
From: Tero Roponen @ 2005-12-19 12:19 UTC (permalink / raw)
To: git
Hi,
It seems that cogito commit e5ca051c1d3900f7fbc1592d018ab3aab6a9573a
broke cg-update, as expected ("Such a large patch is bound to introduce
some (probably mostly trivial) bugs").
Quoting $force and $squash gives cg-fetch and cg-merge an empty argument
if they are not set. If they are not quoted they will be omitted if they
are empty, which is the right thing.
Signed-off-by: Tero Roponen <teanropo@cc.jyu.fi>
---
diff --git a/cg-update b/cg-update
index d586631..1d6e0a0 100755
--- a/cg-update
+++ b/cg-update
@@ -55,10 +55,10 @@ name="${ARGS[0]}"
[ -s "$_git/refs/heads/$name" ] && export _cg_orig_head="$(cat "$_git/refs/heads/$name")"
if [ -s "$_git/branches/$name" ]; then
- cg-fetch "$force" "$name" || exit 1
+ cg-fetch $force "$name" || exit 1
else
echo "Updating from a local branch."
fi
echo
echo "Applying changes..."
-cg-merge "$squash" "$name"
+cg-merge $squash "$name"
^ permalink raw reply related
* EAGAIN?
From: Junio C Hamano @ 2005-12-19 10:07 UTC (permalink / raw)
To: git; +Cc: torvalds
I am embarrassed to ask this in public, but anyway.
I was looking at "git grep -n EAGAIN" output and found that many
places check "errno == EAGAIN" without checking "errno ==
EINTR", both for read(2) and write(2). I feel that EAGAIN is
probably not that useful (it probably would not hurt us, though)
because we do not set up nonblocking ourselves, but I am
wondering if there is particular reason to only check EAGAIN but
not EINTR, or if they are just cut and paste errors.
apply.c:: read checks EAGAIN only, write checks both.
cat-file.c: write checks EAGAIN only.
copy.c:: read checks EAGAIN only, write checks both.
mktag.c:: read checks EAGAIN only.
pkt-line.c:: both read and write checks both.
tar-tree.c:: write checks EAGAIN only.
unpack-objects.c:: both read and write checks both.
^ permalink raw reply
* Re: new file leaked onto release branch
From: Junio C Hamano @ 2005-12-19 9:16 UTC (permalink / raw)
To: Brown, Len; +Cc: Linus Torvalds, git
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B30056F9395@hdsmsx401.amr.corp.intel.com>
"Brown, Len" <len.brown@intel.com> writes:
> 2. I agree that while #### names may be an area of a potential
> problem, it may not be related to the observed failure.
I made it a potential problem by mistake and left it so for a
couple of weeks, but there was no reason for #### names to be a
problem. Even when #### is a unique prefix of a valid object
name, if you have .git/refs/heads/#### branch, that should be
the one that takes precedence over a random object name, and
that is what the fixed code does. Sorry about the earlier
breakage.
Just please keep in mind that the search order is "tags then
heads" (see sha1_name.c::get_sha1_basic()::prefix[]), so if you
happen to have #### branch *and* tag then you will be merging
the tag with this:
> git checkout test && git merge "Pull #### into test branch" test ####
If the git.merge wrapper you posted earlier is always used to
pull a topic branch, it might be safer to update it to do:
git checkout "$2" &&
git merge "Pull $1 into $2 branch" HEAD "refs/heads/$1"
to disambiguate.
^ permalink raw reply
* Re: [PATCH] Fix race and deadlock when sending pack
From: Junio C Hamano @ 2005-12-19 9:02 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Paul Serice, git
In-Reply-To: <Pine.LNX.4.64.0512190130450.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> ... I don't think that it's actually a
> good idea to have output to stdout from hooks go to git-send-pack's
> stdout, since we may want to have git-send-pack report some sort of
> information of its own to stdout,...
I admit that I haven't thought things through yet, but I do not
offhand think of an argument against Paul's patch (a scenario
that may be broken by the patch, that is), so I am inclined to
take it, perhaps after hearing about the cpfd() thing I
mentioned in the previous response to Paul.
It is conceivable that we may want to later extend the protocol
so that the receiver can tell the sender the result of what
happened to each of the ref-update request. Right now, the
sender refuses to listen to what receiver says after it learns
the current object names, but after pack transfer finishes and
receiver decides what to do with each ref update request, we
might want to add status, like this:
# Tell the pusher what commits we have and what their names are
R: SHA1 name
R: ...
R: SHA1 name
R: # flush -- it's your turn
# Tell the puller what the pusher wants to happen
S: old-SHA1 new-SHA1 name
S: old-SHA1 new-SHA1 name
S: ...
S: # flush -- done with the list
S: XXXXXXX --- packfile contents.
# current protocol exchange ends here, but we could add...
# ... what happened to each ref-update request.
R: name OK
R: name FAIL
R: ...
If we do something like this, we might want to say why things
failed on "FAIL" line, and the output from hooks/update that
prevented the ref-update would probably belong there.
^ permalink raw reply
* Re: [PATCH] Fix race and deadlock when sending pack
From: Daniel Barkalow @ 2005-12-19 6:49 UTC (permalink / raw)
To: Paul Serice; +Cc: Junio C Hamano, git
In-Reply-To: <43A628F6.1060807@serice.net>
On Sun, 18 Dec 2005, Paul Serice wrote:
> Fix race and deadlock when sending pack.
>
> The best way to reproduce the problem is to locally clone your
> repository. When you perform a push, git-send-pack will directly set
> up pipes connected to stdin and stdout of git-receive-pack. You
> should then set up hook/post-update or hook/update to try to write
> lots of text to stdout. (You want to use the local protocol because
> ssh is robust enough to mask the worst behavior.)
>
> The first problem is that git-send-pack closes git-receive-pack's
> stdout (which is inherited by the hooks) immediately after sending the
> pack. This almost always causes the hooks to receive SIGPIPE when
> they try to write to stdout.
>
> After fixing the SIGPIPE problem, you then run into a deadlock because
> git-send-pack is blocked trying to reap git-receive-pack and
> git-receive-pack (or one of its hooks) is blocked waiting for
> git-send-pack to read its output.
>
> I've also added an example a one-liner to both hooks demonstrating how
> to redirect all subsequent output to stderr. Because
> git-receive-pack's stderr is not redirected, it has always been safe
> to write to stderr. Thus, all current status related output appears
> on stderr. This can lead to confusing ordering of messages if only
> the hooks are using stdout. The patch has the one-liner commented
> out, but perhaps it should be enabled by default.
>
> In addition, this commit reverts the work-around provided by
> 128aed684d0b3099092b7597c8644599b45b7503 which redirected both stdout
> and stderr for the hooks to /dev/null.
Actually, that was stdin and stdout. If, for some reason, a hook looked at
stdin, it could get surprising results. I don't think that it's actually a
good idea to have output to stdout from hooks go to git-send-pack's
stdout, since we may want to have git-send-pack report some sort of
information of its own to stdout, which would then get confused with
output from hooks. I think /dev/null, a log file, and stderr are the
reasonable choices for what happens to output (and input pretty much has
to be /dev/null).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: using-topic-branches.txt
From: Linus Torvalds @ 2005-12-19 6:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brown, Len, git
In-Reply-To: <7vfyoplk0r.fsf@assigned-by-dhcp.cox.net>
On Sun, 18 Dec 2005, Junio C Hamano wrote:
> "Brown, Len" <len.brown@intel.com> writes:
>
> > This works for me, but now it requires a password to update
> > when before it did not.
>
> You are right. I do not have preference either way myself what
> to put in this document. However, the change stops recommending
> rsync://, which is something I prefer to keep.
Well, you can use "git://git.kernel.org/" for reading.
Personally, I use master.kernel.org both for reading and writing, but I
end up using an ssh key with an empty passphrase.
Linus
^ permalink raw reply
* Re: using-topic-branches.txt
From: Junio C Hamano @ 2005-12-19 5:43 UTC (permalink / raw)
To: Brown, Len; +Cc: git
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B30056F93AC@hdsmsx401.amr.corp.intel.com>
"Brown, Len" <len.brown@intel.com> writes:
> This works for me, but now it requires a password to update
> when before it did not.
You are right. I do not have preference either way myself what
to put in this document. However, the change stops recommending
rsync://, which is something I prefer to keep.
The reason for the change from public machine to master already
got an objection from Jeff. The reasoning was because I
understand that Linus pulls from master to avoid mirroring lags
(and he publicly stated he does so number of times), and the
workflow recommended for subsystem maintainers, the primary
audience of this document, should not slow them down by pulling
from public machines.
^ permalink raw reply
* Re: [PATCH] Fix race and deadlock when sending pack
From: Junio C Hamano @ 2005-12-19 5:36 UTC (permalink / raw)
To: Paul Serice; +Cc: git
In-Reply-To: <43A628F6.1060807@serice.net>
Paul Serice <paul@serice.net> writes:
> The best way to reproduce the problem is to locally clone your
> repository. When you perform a push, git-send-pack will directly set
> up pipes connected to stdin and stdout of git-receive-pack. You
> should then set up hook/post-update or hook/update to try to write
> lots of text to stdout. (You want to use the local protocol because
> ssh is robust enough to mask the worst behavior.)
My immediate reaction was "do not do it then", but you are
right. Hooks are run after all the protocol exchanges are done,
so they should be free to throw any garbage at the other end.
It appears cpfd() seems to mostly duplicate what is in copy.c;
is there any particular reason?
^ permalink raw reply
* Re: using-topic-branches.txt
From: Junio C Hamano @ 2005-12-19 5:33 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <43A63C9B.7080306@pobox.com>
Jeff Garzik <jgarzik@pobox.com> writes:
> master.kernel.org is non-public, so it shouldn't be mentioned in
> documentation...
I'm willing to be persuaded otherwise, but the reason I changed
this part was twofold:
- The documentation is meant to be an example for subsystem
maintainers, who are "non-public" people anyway.
- Linus publicly stated number of times that he fulfils the
pull requests to him by pulling from master --- this avoids
mirroring lag. Not slowing down subsystem maintainers
waiting for mirroring lag would equally be a good idea, I
thought.
^ permalink raw reply
* Re: using-topic-branches.txt
From: Jeff Garzik @ 2005-12-19 4:52 UTC (permalink / raw)
To: Brown, Len; +Cc: Junio C Hamano, git, Luck, Tony
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B30056F93AC@hdsmsx401.amr.corp.intel.com>
Brown, Len wrote:
>>file:4698abe46bff0b878dcfcd05771f5760483b4278 -> file:494429738f8f86bbe21f38b5f90cc94344ad0630
>>--- a/Documentation/howto/using-topic-branches.txt
>>+++ b/Documentation/howto/using-topic-branches.txt
>>@@ -31,7 +31,7 @@ test tree and then pull to the release t
>>patches blocked in the test tree waiting for complex changes to accumulate
>>enough test time to graduate.
>>-Back in the BitKeeper days I achieved this my creating small forests of
>>+Back in the BitKeeper days I achieved this by creating small forests of
>>temporary trees, one tree for each logical grouping of patches, and then
>>pulling changes from these trees first to the test tree, and then to the
>>release tree. At first I replicated this in GIT, but then I realised
>>@@ -42,7 +42,8 @@ So here is the step-by-step guide how th
>>First create your work tree by cloning Linus's public tree:
>>- $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
>>+ $ git clone \
>>+ master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
>>Change directory into the cloned tree you just created
>>@@ -52,7 +53,7 @@ Set up a remotes file so that you can fe
>>branch into a local branch named "linus":
>>$ cat > .git/remotes/linus
>>- URL: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>>+ URL: master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>>Pull: master:linus
>>^D
>
>
> This works for me, but now it requires a password to update
> when before it did not.
master.kernel.org is non-public, so it shouldn't be mentioned in
documentation...
Jeff
^ permalink raw reply
* Re: [ANNOUNCE] gitkdiff 0.1
From: Tejun Heo @ 2005-12-19 4:28 UTC (permalink / raw)
To: KRONSTORFER Horst; +Cc: git
In-Reply-To: <C5BA91F04186584EB68FD42BB4993E6B93E188@FRQWOLEX01.frequentis.frq>
KRONSTORFER Horst wrote:
>
> thanx for the link. app is really useful.
> maybe you could state the app's dependencies on your wiki.
> afaict that would be:
> http://www.tcl.tk/ >= 8.4
> http://cyberelk.net/tim/patchutils/
> http://invisible-island.net/diffstat/
>
> -h
Thanks, just updated.
--
tejun
^ permalink raw reply
* using-topic-branches.txt
From: Brown, Len @ 2005-12-19 4:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Luck, Tony
> file:4698abe46bff0b878dcfcd05771f5760483b4278 -> file:494429738f8f86bbe21f38b5f90cc94344ad0630
> --- a/Documentation/howto/using-topic-branches.txt
> +++ b/Documentation/howto/using-topic-branches.txt
> @@ -31,7 +31,7 @@ test tree and then pull to the release t
> patches blocked in the test tree waiting for complex changes to accumulate
> enough test time to graduate.
> -Back in the BitKeeper days I achieved this my creating small forests of
> +Back in the BitKeeper days I achieved this by creating small forests of
> temporary trees, one tree for each logical grouping of patches, and then
> pulling changes from these trees first to the test tree, and then to the
> release tree. At first I replicated this in GIT, but then I realised
> @@ -42,7 +42,8 @@ So here is the step-by-step guide how th
> First create your work tree by cloning Linus's public tree:
> - $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
> + $ git clone \
> + master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
> Change directory into the cloned tree you just created
> @@ -52,7 +53,7 @@ Set up a remotes file so that you can fe
> branch into a local branch named "linus":
> $ cat > .git/remotes/linus
> - URL: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> + URL: master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Pull: master:linus
> ^D
This works for me, but now it requires a password to update
when before it did not.
-Len
^ permalink raw reply
* [PATCH] Fix race and deadlock when sending pack
From: Paul Serice @ 2005-12-19 3:28 UTC (permalink / raw)
To: Daniel Barkalow, Junio C Hamano; +Cc: git
Fix race and deadlock when sending pack.
The best way to reproduce the problem is to locally clone your
repository. When you perform a push, git-send-pack will directly set
up pipes connected to stdin and stdout of git-receive-pack. You
should then set up hook/post-update or hook/update to try to write
lots of text to stdout. (You want to use the local protocol because
ssh is robust enough to mask the worst behavior.)
The first problem is that git-send-pack closes git-receive-pack's
stdout (which is inherited by the hooks) immediately after sending the
pack. This almost always causes the hooks to receive SIGPIPE when
they try to write to stdout.
After fixing the SIGPIPE problem, you then run into a deadlock because
git-send-pack is blocked trying to reap git-receive-pack and
git-receive-pack (or one of its hooks) is blocked waiting for
git-send-pack to read its output.
I've also added an example a one-liner to both hooks demonstrating how
to redirect all subsequent output to stderr. Because
git-receive-pack's stderr is not redirected, it has always been safe
to write to stderr. Thus, all current status related output appears
on stderr. This can lead to confusing ordering of messages if only
the hooks are using stdout. The patch has the one-liner commented
out, but perhaps it should be enabled by default.
In addition, this commit reverts the work-around provided by
128aed684d0b3099092b7597c8644599b45b7503 which redirected both stdout
and stderr for the hooks to /dev/null.
Signed-off-by: Paul Serice <paul@serice.net>
---
receive-pack.c | 2 +
run-command.c | 27 +++++++++---------
run-command.h | 3 --
send-pack.c | 64 +++++++++++++++++++++++++++++++++++++++++-
templates/hooks--post-update | 4 +++
templates/hooks--update | 4 +++
6 files changed, 85 insertions(+), 19 deletions(-)
36800ae8c6aa1427608a2d131b24986edba91bc9
diff --git a/receive-pack.c b/receive-pack.c
index cbe37e7..1873506 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -173,7 +173,7 @@ static void run_update_post_hook(struct
argc++;
}
argv[argc] = NULL;
- run_command_v_opt(argc, argv, RUN_COMMAND_NO_STDIO);
+ run_command_v(argc, argv);
}
/*
diff --git a/run-command.c b/run-command.c
index 8bf5922..38cd6cb 100644
--- a/run-command.c
+++ b/run-command.c
@@ -2,19 +2,23 @@
#include "run-command.h"
#include <sys/wait.h>
-int run_command_v_opt(int argc, char **argv, int flags)
+int run_command_v(int argc, char **argv)
{
- pid_t pid = fork();
+
+ pid_t pid = (pid_t)-1;
+
+ /* Because each process has independent buffering, if you
+ * don't flush before the fork, it can seem like the new
+ * output for the child occurs before the old output of the
+ * parent which can be confusing at times. */
+ fflush(stdout);
+ fflush(stderr);
+
+ pid = fork();
if (pid < 0)
return -ERR_RUN_COMMAND_FORK;
if (!pid) {
- if (flags & RUN_COMMAND_NO_STDIO) {
- int fd = open("/dev/null", O_RDWR);
- dup2(fd, 0);
- dup2(fd, 1);
- close(fd);
- }
execvp(argv[0], (char *const*) argv);
die("exec %s failed.", argv[0]);
}
@@ -42,11 +46,6 @@ int run_command_v_opt(int argc, char **a
}
}
-int run_command_v(int argc, char **argv)
-{
- return run_command_v_opt(argc, argv, 0);
-}
-
int run_command(const char *cmd, ...)
{
int argc;
@@ -65,5 +64,5 @@ int run_command(const char *cmd, ...)
va_end(param);
if (MAX_RUN_COMMAND_ARGS <= argc)
return error("too many args to run %s", cmd);
- return run_command_v_opt(argc, argv, 0);
+ return run_command_v(argc, argv);
}
diff --git a/run-command.h b/run-command.h
index 2469eea..5ee0972 100644
--- a/run-command.h
+++ b/run-command.h
@@ -11,9 +11,6 @@ enum {
ERR_RUN_COMMAND_WAITPID_NOEXIT,
};
-#define RUN_COMMAND_NO_STDIO 1
-
-int run_command_v_opt(int argc, char **argv, int opt);
int run_command_v(int argc, char **argv);
int run_command(const char *cmd, ...);
diff --git a/send-pack.c b/send-pack.c
index 6ce0d9f..efc66ca 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -274,6 +274,55 @@ static int send_pack(int in, int out, in
return ret;
}
+/* This function copies the data from in_fd to out_fd. It returns 1 if
+ * all data was successfully copied; otherwise, it returns 0, and
+ * errno will be set depending on how read() or write() failed. */
+static int cpfd(int in_fd, int out_fd)
+{
+ int rv = 0;
+ ssize_t rcount = -1;
+ ssize_t wcount = 0;
+ ssize_t wtmp = -1;
+ static char cpfd_buf[4096];
+
+ for (;;) {
+
+ /* Read buffer. */
+ rcount = read(in_fd, cpfd_buf, sizeof(cpfd_buf));
+
+ /* Done. */
+ if (rcount == 0) {
+ rv = 1;
+ goto out;
+ }
+
+ /* Error. */
+ if (rcount < 0) {
+ if (errno == EINTR) {
+ continue;
+ }
+ goto out;
+ }
+
+ /* Write buffer. */
+ wcount = 0;
+ while (wcount < rcount) {
+ wtmp = write(out_fd,
+ cpfd_buf + wcount,
+ rcount - wcount);
+ if (wtmp < 0) {
+ if (errno == EINTR) {
+ continue;
+ }
+ goto out;
+ }
+ wcount += wtmp;
+ }
+ }
+
+ out:
+ return rv;
+}
int main(int argc, char **argv)
{
@@ -319,8 +368,21 @@ int main(int argc, char **argv)
if (pid < 0)
return 1;
ret = send_pack(fd[0], fd[1], nr_heads, heads);
- close(fd[0]);
+
+ /* git_connect() sets up a pipe between this program and
+ * "exec" (typically git-receive-pack). The git-receive-pack
+ * program in turn executes the "update" and "post-update"
+ * hooks which might write to this program's fd[0]. To avoid
+ * deadlock, this program must consume all of the data on
+ * fd[0]. (The hooks are called after the pack has been
+ * transfered so it should it should be safe to allow them to
+ * write to stdout because it should not interfere with the
+ * transfer protocol which also occurs on stdout). */
+ cpfd(fd[0], fileno(stdout));
+
close(fd[1]);
finish_connect(pid);
+ close(fd[0]);
+
return ret;
}
diff --git a/templates/hooks--post-update b/templates/hooks--post-update
index bcba893..d470dcc 100644
--- a/templates/hooks--post-update
+++ b/templates/hooks--post-update
@@ -5,4 +5,8 @@
#
# To enable this hook, make this file executable by "chmod +x post-update".
+# If your stdout and stderr messages are interleaved, uncomment the
+# following line.
+#exec 1>&2
+
exec git-update-server-info
diff --git a/templates/hooks--update b/templates/hooks--update
index 6db555f..6199deb 100644
--- a/templates/hooks--update
+++ b/templates/hooks--update
@@ -8,6 +8,10 @@
# (2) make this file executable by "chmod +x update".
#
+# If your stdout and stderr messages are interleaved, uncomment the
+# following line.
+#exec 1>&2
+
recipient="commit-list@example.com"
if expr "$2" : '0*$' >/dev/null
--
0.99.9.GIT
^ permalink raw reply related
* RE: new file leaked onto release branch
From: Brown, Len @ 2005-12-19 3:21 UTC (permalink / raw)
To: Junio C Hamano, Linus Torvalds; +Cc: git
>This theory however does not seem to match what really happened.
>Len did mention that he has "5165" branch (there is a commit
>marked "Pull 5165 into release branch" near a problematic
>merge), but he did not say he also has a 5165 tag; the bug does
>not trigger if you do not have the tag of the same name. Also
>if this theory holds true, the problematic commit should have a
>commit whose object name begins with 5165 as the second parent
>but that is not the case. And the problem happened with a
>commit that is not a merge between release/test and topic
>branch anyway; it is with an "Auto-update from upstream" commit.
Per Tony's topic-branches howto, I do plenty of branching,
where the topic branch name , #### below , is a 4-digit number:
git checkout -b #### linus
and I use the wrapper script to do this:
git checkout test && git merge "Pull #### into test branch" test ####
git checkout release && git merge "Pull #### into release branch" release ####
But
1. I don't create tags with #### names, indeed, I never use tags at all
2. I agree that while #### names may be an area of a potential
problem, it may not be related to the observed failure. This is
because the file in question was added to to a topic branch called "acpica"
which IIR never interacted in any way with a branched named ####,
but only with the branches called "linus" and "test".
>So I am still puzzled by the "where did this file come from"
>problem. The most plausible explanation was the driver error
>mentioned already in the thread: "update-index --add" in the
>middle of merge with manual committing.
I too suspect that a failed automatic merge is related.
Likely the sequence of events is not something that either
a git expert or a git beginner would ever issue, but takes
somebody like me who knows just enough to be dangerous:-)
-Len
^ permalink raw reply
* [PATCH] Documentation/git-archimport: document -o, -a, f, -D options
From: Eric Wong @ 2005-12-19 1:23 UTC (permalink / raw)
To: git list
Also, ensure usage help switches are in the same order.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Documentation/git-archimport.txt | 23 ++++++++++++++++++++++-
git-archimport.perl | 5 +++--
2 files changed, 25 insertions(+), 3 deletions(-)
53a88811af9db5cb6287fe0fe9a7d03ab62652c7
diff --git a/Documentation/git-archimport.txt b/Documentation/git-archimport.txt
index fcda012..a2bd788 100644
--- a/Documentation/git-archimport.txt
+++ b/Documentation/git-archimport.txt
@@ -8,7 +8,8 @@ git-archimport - Import an Arch reposito
SYNOPSIS
--------
-`git-archimport` [ -h ] [ -v ] [ -T ] [ -t tempdir ]
+`git-archimport` [ -h ] [ -v ] [ -o ] [ -a ] [ -f ] [ -T ]
+ [ -D depth ] [ -t tempdir ]
<archive/branch> [ <archive/branch> ]
DESCRIPTION
@@ -63,6 +64,26 @@ OPTIONS
Many tags. Will create a tag for every commit, reflecting the commit
name in the Arch repository.
+-f::
+ Use the fast patchset import strategy. This can be significantly
+ faster for large trees, but cannot handle directory renames or
+ permissions changes. The default strategy is slow and safe.
+
+-o::
+ Use this for compatibility with old-style branch names used by
+ earlier versions of git-archimport. Old-style branch names
+ were category--branch, whereas new-style branch names are
+ archive,category--branch--version.
+
+-D <depth>::
+ Follow merge ancestry and attempt to import trees that have been
+ merged from. Specify a depth greater than 1 if patch logs have been
+ pruned.
+
+-a::
+ Attempt to auto-register archives at http://mirrors.sourcecontrol.net
+ This is particularly useful with the -D option.
+
-t <tmpdir>::
Override the default tempdir.
diff --git a/git-archimport.perl b/git-archimport.perl
index aab4e38..841738d 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -9,7 +9,8 @@
=head1 Invocation
- git-archimport [ -h ] [ -v ] [ -T ] [ -t tempdir ] <archive>/<branch> [ <archive>/<branch> ]
+ git-archimport [ -h ] [ -v ] [ -o ] [ -a ] [ -f ] [ -T ]
+ [ -D depth] [ -t tempdir ] <archive>/<branch> [ <archive>/<branch> ]
Imports a project from one or more Arch repositories. It will follow branches
and repositories within the namespaces defined by the <archive/branch>
@@ -74,7 +75,7 @@ our($opt_h,$opt_f,$opt_v,$opt_T,$opt_t,$
sub usage() {
print STDERR <<END;
Usage: ${\basename $0} # fetch/update GIT from Arch
- [ -f ] [ -o ] [ -h ] [ -v ] [ -T ] [ -a ] [ -D depth ] [ -t tempdir ]
+ [ -h ] [ -v ] [ -o ] [ -a ] [ -f ] [ -T ] [ -D depth ] [ -t tempdir ]
repository/arch-branch [ repository/arch-branch] ...
END
exit(1);
--
0.99.9.GIT
^ permalink raw reply related
* Re: why are gitweb 'description' and 'owner' stored in different ways?
From: Kay Sievers @ 2005-12-19 1:13 UTC (permalink / raw)
To: Ben Clifford; +Cc: Git List
In-Reply-To: <C095FE37-2673-449D-AAB9-ADF042CE8F32@hawaga.org.uk>
On Sun, Dec 18, 2005 at 08:27:41PM +0930, Ben Clifford wrote:
> Just wondering, is there a reason that gitweb stores the
> 'description' in one way (inside .git) and 'owner' in a different way
> (in index.aux) ?
No special reason besides that the owner is generated automatically from
the file permissions on the master server along with searching for
repositories and creating the list. We currently have more than one
"Linus' kernel tree" descriptions, so if we would rely on in-repo data
for the owner, the owner would be wrong on that repos too.
Kay
^ permalink raw reply
* Re: [PATCH] cg-completion: improve options and command listing
From: Ben Clifford @ 2005-12-19 1:03 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Git List, Petr Baudis
In-Reply-To: <20051218143439.GA7064@diku.dk>
On Sun, 18 Dec 2005, Jonas Fonseca wrote:
> Else I was thinking of maybe adding --list parameter to cg-help to have
> it list all known commands.
yeah, that would be nice.
--
http://www.hawaga.org.uk/ben/
^ permalink raw reply
* why are gitweb 'description' and 'owner' stored in different ways?
From: Ben Clifford @ 2005-12-18 10:57 UTC (permalink / raw)
To: kay.sievers; +Cc: Git List
Just wondering, is there a reason that gitweb stores the
'description' in one way (inside .git) and 'owner' in a different way
(in index.aux) ?
--
Ben • ベン • Бэн • 벤 • 班明
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,
SMS number(s) at above URL.
^ permalink raw reply
* Make "git help" sort git commands in columns
From: Linus Torvalds @ 2005-12-18 20:41 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List, Andreas Ericsson
This changes "pretty_print_string_list()" to show the git commands
alphabetically in column order, which is the normal one.
Ie instead of doing
git commands available in '/home/torvalds/bin'
----------------------------------------------
add am ...
applypatch archimport ...
cat-file check-ref-format ...
...
it does
git commands available in '/home/torvalds/bin'
----------------------------------------------
add diff-tree ...
am fetch ...
apply fetch-pack ...
...
where each column is sorted.
This is how "ls" sorts things too, and since visually the columns are much
more distinct than the rows, so it _looks_ more sorted.
The "ls" command has a "-x" option that lists entries by lines (the way
git.c used to): if somebody wants to do that, the new print-out logic
could be easily accomodated to that too. Matter of taste and preference, I
guess.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
Side note: this is independent of the other patch I just sent out. Take
either or both.
----
diff --git a/git.c b/git.c
index c26cac6..0fd95bf 100644
--- a/git.c
+++ b/git.c
@@ -74,25 +85,28 @@ static int cmdname_compare(const void *a
static void pretty_print_string_list(struct cmdname **cmdname, int longest)
{
- int cols = 1;
+ int cols = 1, rows;
int space = longest + 1; /* min 1 SP between words */
int max_cols = term_columns() - 1; /* don't print *on* the edge */
- int i;
+ int i, j;
if (space < max_cols)
cols = max_cols / space;
+ rows = (cmdname_cnt + cols - 1) / cols;
qsort(cmdname, cmdname_cnt, sizeof(*cmdname), cmdname_compare);
- for (i = 0; i < cmdname_cnt; ) {
- int c;
+ for (i = 0; i < rows; i++) {
printf(" ");
- for (c = cols; c && i < cmdname_cnt; i++) {
- printf("%s", cmdname[i]->name);
-
- if (--c)
- mput_char(' ', space - cmdname[i]->len);
+ for (j = 0; j < cols; j++) {
+ int n = j * rows + i;
+ int size = space;
+ if (n >= cmdname_cnt)
+ break;
+ if (j == cols-1 || n + rows >= cmdname_cnt)
+ size = 1;
+ printf("%-*s", size, cmdname[n]->name);
}
putchar('\n');
}
^ permalink raw reply related
* Re: [PATCH] git-grep: convert from bash to sh
From: Timo Hirvonen @ 2005-12-18 20:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0512181155360.4827@g5.osdl.org>
On Sun, 18 Dec 2005 11:57:26 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:
> On Sun, 18 Dec 2005, Timo Hirvonen wrote:
> >
> > sh does not support arrays so we have to use eval instead.
>
> This seems horribly broken.
>
> If I'm not mistaken, this breaks
>
> git grep "it's a happy coincidence"
>
> badly. I didn't test, just looking at the patch.
Actually it works:
/usr/src/linux-2.6: git grep "it's a"
Documentation/Changes:debugfs. Obviously, it's a good idea to upgrade.
Documentation/CodingStyle:and NOT read it. Burn them, it's a great
symbolic gesture.
but it doesn't work with backslashes. Need to use \\
/usr/src/linux-2.6: git grep 'e.\\n"'
Documentation/DMA-mapping.txt: "mydev: No suitable DMA
available.\n");
Documentation/DMA-mapping.txt: "mydev: No suitable DMA
available.\n");
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Make "git help" react to window size correctly
From: Linus Torvalds @ 2005-12-18 20:15 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List, Andreas Ericsson
Currently the git "show commands" function will react to the environment
variable COLUMNS, or just default to a width of 80 characters.
That's just soo eighties. Nobody sane sets COLUMNS any more, unless they
need to support some stone-age software from before the age of steam
engines, SIGWINCH and TIOCGWINSZ.
So get with the new century, and use TIOCGWINSZ to get the terminal size.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/git.c b/git.c
index c26cac6..157c549 100644
--- a/git.c
+++ b/git.c
@@ -8,6 +8,7 @@
#include <errno.h>
#include <limits.h>
#include <stdarg.h>
+#include <sys/ioctl.h>
#include "git-compat-util.h"
#ifndef PATH_MAX
@@ -26,6 +27,16 @@ static int term_columns(void)
if (col_string && (n_cols = atoi(col_string)) > 0)
return n_cols;
+#ifdef TIOCGWINSZ
+ {
+ struct winsize ws;
+ if (!ioctl(1, TIOCGWINSZ, &ws)) {
+ if (ws.ws_col)
+ return ws.ws_col;
+ }
+ }
+#endif
+
return 80;
}
^ permalink raw reply related
* Re: [PATCH] git-grep: convert from bash to sh
From: Linus Torvalds @ 2005-12-18 19:57 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: Junio C Hamano, git
In-Reply-To: <20051218152639.5c14bc26.tihirvon@gmail.com>
On Sun, 18 Dec 2005, Timo Hirvonen wrote:
>
> sh does not support arrays so we have to use eval instead.
This seems horribly broken.
If I'm not mistaken, this breaks
git grep "it's a happy coincidence"
badly. I didn't test, just looking at the patch.
Dammit, I'd rather depend on "bash"/"ksh" than have a broken "git grep".
Tell people to get a real shell.
Linus
^ 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