* Re: [PATCH] Support for configurable git command aliases (v2)
From: Martin Mares @ 2006-06-04 22:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060604212050.GV10488@pasky.or.cz>
Hello, world!
> And I forgot to mention that it also adds the interactivity test
> requested by Janek - aliases are now interpreted only when stdout is a
> tty.
Does this really make sense? Why should an alias stop working
if I happen to redirect its output? Or am I missing something?
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
God is real, unless declared integer.
^ permalink raw reply
* Re: [PATCH] Support for configurable git command aliases (v2)
From: Petr Baudis @ 2006-06-04 22:19 UTC (permalink / raw)
To: Martin Mares; +Cc: Junio C Hamano, git
In-Reply-To: <mj+md-20060604.221036.15619.albireo@ucw.cz>
Hi,
Dear diary, on Mon, Jun 05, 2006 at 12:11:14AM CEST, I got a letter
where Martin Mares <mj@ucw.cz> said that...
> > And I forgot to mention that it also adds the interactivity test
> > requested by Janek - aliases are now interpreted only when stdout is a
> > tty.
>
> Does this really make sense? Why should an alias stop working
> if I happen to redirect its output? Or am I missing something?
make
[alias]
log = log --pretty=raw
and then any script that works on git log output might get very
confused.
Then again, as pointed out on IRC you might get very confused as well
if you do git log | less. Besides, this is not going to help you with
aliases like commit = commit -a.
So, some other possibilities are to:
(i) Test stdin. Even in scripts, stdin is frequently terminal, but you
might add </dev/null after each git invocation and get a serious case of
RSI.
(ii) Add a --no-alias git argument. This way lies madness, too.
(iii) Check a $GIT_NO_ALIAS environment variable. This might work
best, after all. Opinions? Or some other clever idea?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: git clone takes ages on a slow link
From: Anton Blanchard @ 2006-06-04 22:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0606041046340.5498@g5.osdl.org>
Hi Linus,
> It is indeed. It's _meant_ to only tick once a second or when the
> percentage changes, but I think it forgot to clear the "once a second
> happened" flag, so instead of updates the percentage output for every
> file it checks out after the first second has passed.
>
> So something like this should help... Can you verify?
Thanks, it fixes it.
Anton
> diff --git a/builtin-read-tree.c b/builtin-read-tree.c
> index 716f792..80c9320 100644
> --- a/builtin-read-tree.c
> +++ b/builtin-read-tree.c
> @@ -336,6 +336,7 @@ static void check_updates(struct cache_e
> fprintf(stderr, "%4u%% (%u/%u) done\r",
> percent, cnt, total);
> last_percent = percent;
> + progress_update = 0;
> }
> }
> }
^ permalink raw reply
* Re: [PATCH] Support for configurable git command aliases (v2)
From: Junio C Hamano @ 2006-06-04 22:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060604221930.GW10488@pasky.or.cz>
Petr Baudis <pasky@ucw.cz> writes:
>
> Then again, as pointed out on IRC you might get very confused as well
> if you do git log | less. Besides, this is not going to help you with
> aliases like commit = commit -a.
>
> So, some other possibilities are to:
>
> (i) Test stdin. Even in scripts, stdin is frequently terminal, but you
> might add </dev/null after each git invocation and get a serious case of
> RSI.
>
> (ii) Add a --no-alias git argument. This way lies madness, too.
>
> (iii) Check a $GIT_NO_ALIAS environment variable. This might work
> best, after all. Opinions? Or some other clever idea?
Perhaps the simplest:
(iv) Refuse/ignore an alias that hides existing command, and
train users to write portable scripts by not using
aliases. E.g. "alias.log = log --pretty=raw" is
ignored, and you would do "alias.l = log --pretty=raw"
instead.
^ permalink raw reply
* Re: git daemon directory munging?
From: H. Peter Anvin @ 2006-06-04 23:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Loeliger, git
In-Reply-To: <Pine.LNX.4.64.0606031722340.5498@g5.osdl.org>
Linus Torvalds wrote:
>
> On Sat, 3 Jun 2006, Jon Loeliger wrote:
>> <jdl> Thus, I'd use something like:
>> --map-base=www.foo.com/pub/scm:/pub/foo/scm
>> --map-base=www.bar.com/pub/scm=/pub/bar/scm
>
> The bigger problem is that nothing actually passes in the hostname to
> git-daemon in the first place. By the time the git-daemon is contacted,
> the hostname is long gone ;(
Well, you can bind different git daemons to different IP addresses
(IP-based vhosting) or different ports (with SRV records in DNS.)
> Now, you can just extend the git protocol to just pass in the host too.
>
> You can in fact do this in a backwards-compatible manner (old git-daemons
> will just ignore it, and new git daemons will automatically notice new
> clients) with something evil like the appended.
>
That's actually what was done to HTTP.
> Not tested (and this actualyl doesn't make the daemon _use_ the data, it
> just adds a comment - the rest "is left as an exercise for the reader")
-hpa
^ permalink raw reply
* Re: git daemon directory munging?
From: H. Peter Anvin @ 2006-06-04 23:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vverhcu5n.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> Adding host like HTTP does with Host: header makes sense but I
> think the accept side can usually tell what the port it accepted
> the connection to is.
>
Yes, but that requires that each hostname has a separate IP address
and/or port number (and SRV records in DNS, which not all platforms pay
attention to.)
Now, if the hostname is passed in like this, it needs to be carefully
canonicalized, and there needs to be provisions for wildcard matches.
-hpa
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Linus Torvalds @ 2006-06-04 23:19 UTC (permalink / raw)
To: Robin Rosenberg (list subscriber); +Cc: Jakub Narebski, git
In-Reply-To: <200606042325.58884.robin.rosenberg.lists@dewire.com>
On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:
>
> Your patch assumes all files are text and the transformation doesn't corrupt
> the file, which isn't true.
How do you think things get done? You test the _technology_ first, and
then if that is shown to be workable in a real environment, _then_ do you
actually add the polish to make it useful.
That was all the patch was. A technology demonstration. I'd really like to
hear whether it works in a simple CR/LF environment, because if it
doesn't, then it needs some totally different approach.
And yes, I could test it myself, but (a) I'm way too lazy and (b) I
consciously try to get others involved because it's a better long-term
strategy (because I expect to be ay too lazy in the future too)
Linus
^ permalink raw reply
* Re: [PATCH] Support for configurable git command aliases (v2)
From: Linus Torvalds @ 2006-06-04 23:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060604212050.GV10488@pasky.or.cz>
On Sun, 4 Jun 2006, Petr Baudis wrote:
>
> And I forgot to mention that it also adds the interactivity test
> requested by Janek - aliases are now interpreted only when stdout is a
> tty.
I don't think that's a good test.
The fact is, I do
git diff | less -S
all the time, and if I start doing aliases, I'd expect them to work the
same regardless of whether I piped the output to "less" or not.
Also, a lot of scripts have stdout going to the regular stdout, so I don't
think it's even a sufficient test for scripting anyway.
So I would suggest some other way to suppress aliases if we need it, not
based on "isatty()" and frields.
But I suspect that the easiest solution is to just disallow aliases of
real built-ins. I realize it could be cool, but the fact is, it's also
extremely confusing if "git diff" does something else than what it's
supposed to do, and it _will_ break scripts.
The alternatives is to
- not do aliases for the "git-xyzzy" format
- and add a special environment flag ("GIT_NO_ALIASES") to allow scripts
to easily disable aliases (and add a "export GIT_NO_ALIASES" line to
the git-sh-setup.sh script)
Hmm?
Linus
^ permalink raw reply
* [PATCH] Add example xinetd(8) configuration to Documentation/everyday.txt
From: Horst H. von Brand @ 2006-06-04 23:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Many Linux distributions use xinetd(8), not inetd(8).
Give a sample configuration file.
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/everyday.txt | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index 2ad2d61..ffba543 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -377,6 +377,29 @@ git stream tcp nowait nobody \
+
The actual configuration line should be on one line.
+Run git-daemon to serve /pub/scm from xinetd.::
++
+------------
+$ cat /etc/xinetd.d/git-daemon
+# default: off
+# description: The git server offers access to git repositories
+service git
+{
+ disable = no
+ type = UNLISTED
+ port = 9418
+ socket_type = stream
+ wait = no
+ user = root
+ server = /usr/bin/git-daemon
+ server_args = --inetd --syslog --export-all --base-path=/pub/scm
+ log_on_failure += USERID
+}
+------------
++
+Check your xinetd(8) documentation and setup, this is from a Fedora system.
+Others might be different.
+
Give push/pull only access to developers.::
+
------------
--
1.3.3.g16a4
^ permalink raw reply related
* Re: [PATCH] Add example xinetd(8) configuration to Documentation/everyday.txt
From: Dmitry V. Levin @ 2006-06-05 0:01 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
In-Reply-To: <11494652252294-git-send-email-vonbrand@inf.utfsm.cl>
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
On Sun, Jun 04, 2006 at 07:53:45PM -0400, Horst H. von Brand wrote:
> Many Linux distributions use xinetd(8), not inetd(8).
> Give a sample configuration file.
[...]
> @@ -377,6 +377,29 @@ git stream tcp nowait nobody \
[...]
> + user = root
> + server = /usr/bin/git-daemon
It is a bad advice to run git-daemon as root.
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Jonas Fonseca @ 2006-06-05 0:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7vejy48wp5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote Sun, Jun 04, 2006:
>
> I may not be using tig in the way it was intended to, but I
> often find it frustrating having to do the following:
>
> - start tig, which shows list of one-line logs. Wonderful.
>
> - browsing around by UP or DOWN and stop at one particular commit
> I want to view closely. Press Enter and the screen split
> into two and I see what I want to see. Again, wonderful.
>
> - I want to see the neighbouring commits, but UP or DOWN
> does not do what I naïvely expect. It scrolls the lower
> pane. I say TAB to go up.
I wonder what tig version you are using. If you are using the tig
version from my git repo this should also be working to your
expectation, making ...
> - Press UP or DOWN and I can move the highlight to
> neighbouring commits. This is wonderful, but the lower
> pane does not follow this -- it keeps showing the original
> commit, and I have to say ENTER again.
.. this unnecessary. At least, I'd like to keep the one-line log view
from forcing updates of the diff view so it is more responsive over slow
links.
> It might make sense to make the log/diff view follow what
> happens on the main view when both are on-screen.
With my current version, the two views are much more integrated, e.g.
you can press 'd' to show full-screen diff view and use Up and Down to
navigate the log view.
--
Jonas Fonseca
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Yakov Lerner @ 2006-06-05 0:10 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0606031631480.5498@g5.osdl.org>
On 6/4/06, Linus Torvalds <torvalds@osdl.org> wrote:
+static unsigned long autodetect_crlf(unsigned char *src, unsigned long size)
> +{
> + unsigned long newsize = 0;
> + unsigned char *dst = src;
> + unsigned char last = 0;
> +
> + while (size) {
> + unsigned char c = *src++;
size--;
is missing
> + if (last == '\r' && c == '\n') {
> + dst[-1] = '\n';
> + } else {
> + newsize++;
> + dst++;
> + if (dst != src)
> + dst[-1] = c;
> + }
> + last = c;
> + }
> + return newsize;
> +}
Yakov
^ permalink raw reply
* Re: irc usage..
From: Alec Warner @ 2006-06-05 0:33 UTC (permalink / raw)
To: Martin Langhoff
Cc: Donnie Berkholz, Linus Torvalds, Yann Dirson, Git Mailing List,
Matthias Urlichs, Johannes Schindelin
In-Reply-To: <46a038f90606010047r676840d2nd91ad2361abbe1c8@mail.gmail.com>
Martin Langhoff wrote:
> On 6/1/06, Alec Warner <antarus@gentoo.org> wrote:
>
>> After reading the whole thread on this, I've using a git checkout of
>> git, cvsps-2.1 and cvs-1.11.12, running overnight in verbose mode with
>> screen. Hopefully will have a repo in the morning ;)
>
>
> Good stuff. I am rerunning it to prove (and bench) a complete an
> uninterrupted import. So far it's done 4hs 30m, footprint grown to
> 207MB, 49750 commits. So I think it will be done in approx 30hs on
> this single-cpu opteron.
>
> Most commits are small, but there is a handful that are downright
> massive -- and we hold all the file list in memory, which I think
> explains (most of) the memory growth. I've looked into avoiding
> holding the whole filelist in memory, but it involves rewriting the
> cvsps output parsing loop, which is better left for a rainy day, with
> a test case that doesn't take 30hs to resolve.
Ok the box this was running on had issues, so I switched to using
pearl.amd64.dev.gentoo.org, a dual core amd64 X2 4600+ with 4 gigs of
ram and plenty of disk. The "problem" now is just converstion time...30
hours and I'm into 2004-09-17...but it's been in 2004 all day, seems
like most of the commits are in the last three years. Are there
architectural issues with doing this in parallel?
Since the repository commits are all in cvs, it should be possible to do
the work in parallel, since you know what all the commits touch. The
concern would be ordering of nodes in the tree; you'd end up building a
bunch of subtrees and patching them together?
-Alec Warner
^ permalink raw reply
* Re: [PATCH, take 2] Add example xinetd(8) configuration to Documentation/everyday.txt
From: Horst von Brand @ 2006-06-05 0:54 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: Junio C Hamano, git
In-Reply-To: <20060605000144.GA12641@basalt.office.altlinux.org>
Dmitry V. Levin <ldv@altlinux.org> wrote:
> It is a bad advice to run git-daemon as root.
Right, my bad. Fixed patch below.
[Really dumb question: How do you separate comments, like this, from the
commit itself? Here done with dashes.]
--------
Add example xinetd(8) configuration to Documentation/everyday.txt
Many Linux distributions use xinetd(8), not inetd(8).
Give a sample configuration file.
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/everyday.txt | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index 2ad2d61..ffba543 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -377,6 +377,29 @@ git stream tcp nowait nobody \
+
The actual configuration line should be on one line.
+Run git-daemon to serve /pub/scm from xinetd.::
++
+------------
+$ cat /etc/xinetd.d/git-daemon
+# default: off
+# description: The git server offers access to git repositories
+service git
+{
+ disable = no
+ type = UNLISTED
+ port = 9418
+ socket_type = stream
+ wait = no
+ user = root
+ server = /usr/bin/git-daemon
+ server_args = --inetd --syslog --export-all --base-path=/pub/scm
+ log_on_failure += USERID
+}
+------------
++
+Check your xinetd(8) documentation and setup, this is from a Fedora system.
+Others might be different.
+
Give push/pull only access to developers.::
+
------------
--
1.3.3.g16a4
^ permalink raw reply related
* Re: [PATCH, take 2] Add example xinetd(8) configuration to Documentation/everyday.txt
From: Junio C Hamano @ 2006-06-05 1:24 UTC (permalink / raw)
To: Horst von Brand; +Cc: git
In-Reply-To: <200606050054.k550sFCC018490@laptop11.inf.utfsm.cl>
I do not know if the above address again bounces for me, but you
will see that on the list I presume...
> [Really dumb question: How do you separate comments, like this, from the
> commit itself? Here done with dashes.]
There are two ways often used on this list.
(1) Traditional, "really automatable and nicer to the
maintainer" style.
From xxx
Subject: [PATCH] Add example xinetd(8) config...
Commit log comes here, without the cover letter
material.
Signed-off-by: A U Thor <author@example.com>
---
* Cover letter material comes here, before the usual
diffstat and patch
Documentation/everyday.txt | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/Documentation/everyday.txt b/Documenta...
index 2ad2d61..ffba543 100644
Two points to observe:
- Subject: should be changed to match the first line of the
commit log message you would want to see, as needed.
- cover letter material comes after the "---\n" line.
When the cover letter material is short, this is often
preferred, since I can just run "git am" on the whole thing
and everything after the first "^---", including your cover
letter material, is omitted from the log message. It is,
however, like top-posting and becomes harder to follow if
the cover letter material gets long, in which case I
personally prefer style (2) (but do not send style (2) to
Linus).
(2) e-mail style, but NEVER use "---" (or longer) marker between
cover letter and the commit log.
From xxx
Subject: Re: some earlier discussion topic
Longer discussion, rambling, quotes, and cover letter
material.
-- >8 -- cut here -- >8 --
[PATCH] Add example xinetd(8) config...
Commit log comes here.
Signed-off-by: A U Thor <author@example.com>
---
Documentation/everyday.txt | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/Documentation/everyday.txt b/Documenta...
index 2ad2d61..ffba543 100644
When the cover letter material is long, this is easier to
read, because it avoids the problems associated with
top-posting. However, when I apply this with "git am", I
would need to go interactive and remove everything before
the scissors line by hand.
Usual patch application toolchain (either git-applymbox or
git-am) first splits your message at the first "^---" or "^diff
-", and uses the part before that line to form the commit log
message (together with what you have on the "Subject:" line).
The rest is fed to git-apply. What this means is that you do
not have to use the scissors logo (the tool does not know about
it), but it is _absolutely_ necessary not to use anything that
would usually signal the tool of the commit log message in place
of the scissors. If you have the cover letter first and then
"---" or "-----" followed by the commit message after that, the
commit log message will be taken from the "discussion, rambling,
quotes, and cover letter material" part and the real commit log
you wanted to have will not be seen at all, which needs to be
hand fixed.
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-05 1:37 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Paul Mackerras, git
In-Reply-To: <20060605000423.GA29521@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
>> - I want to see the neighbouring commits, but UP or DOWN
>> does not do what I naïvely expect. It scrolls the lower
>> pane. I say TAB to go up.
>
> I wonder what tig version you are using. If you are using the tig
> version from my git repo this should also be working to your
> expectation, making ...
Whichever was the latest when I wrote the message. I see you
have added a handful commits on it since then.
>> - Press UP or DOWN and I can move the highlight to
>> neighbouring commits. This is wonderful, but the lower
>> pane does not follow this -- it keeps showing the original
>> commit, and I have to say ENTER again.
>
> .. this unnecessary.
Maybe I am misusing it then.
"full-screen" diff view and being able to do [UP] and [DOWN] to
move around there do not feel useful to me that much. It is
something "git log -p" does already, thanks to its output paged
via "less" by default.
I like viewing the list in the upper and diff/log in the lower
at the same time, and that is the primary reason I liked tig, so
moving around in the commit list view and not seeing the
diff/log updated in sync was major dissapointment at least for
me.
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-06-05 2:06 UTC (permalink / raw)
To: antarus
Cc: Donnie Berkholz, Linus Torvalds, Yann Dirson, Git Mailing List,
Matthias Urlichs, Johannes Schindelin
In-Reply-To: <44837BDB.2090601@gentoo.org>
On 6/5/06, Alec Warner <antarus@gentoo.org> wrote:
> Ok the box this was running on had issues, so I switched to using
> pearl.amd64.dev.gentoo.org, a dual core amd64 X2 4600+ with 4 gigs of
> ram and plenty of disk. The "problem" now is just converstion time...30
> hours and I'm into 2004-09-17...but it's been in 2004 all day, seems
> like most of the commits are in the last three years. Are there
> architectural issues with doing this in parallel?
I don't think you can do this in parallel. What I would do is remove
the -a from the git-repack invocation. It does hurt import times quite
a bit -- just do a git-repack -a -d when it's done.
And... having said that, there is still a memory leak somehow,
somewhere. It's been evading me for 2 weeks now, so I feel an idiot
now. Not too bad in general, but it shows clearly in the gentoo and
mozilla imports.
> Since the repository commits are all in cvs, it should be possible to do
> the work in parallel, since you know what all the commits touch. The
> concern would be ordering of nodes in the tree; you'd end up building a
> bunch of subtrees and patching them together?
Well... parsecvs does a bit of this but in sequential fashion... it
imports all the files first, and then runs through the history
building the tree+commits in order, committing them. It saves a lot of
time in the file imports by parsing the RCS file directly. The
downside is that it must keep a filename+version=>sha1 mapping --
which I think is why parsecvs won't fit in memory until it's changed
to store it on disk somehow ;-)
You are forced to do it in a sequence because cvsps only tells you
about the files added/removed/changed in a commit -- you need the
ancestor to have a view of what the whole tree looked like. The only
room for parallelism I see is to fork off new processes to work on
branches in parallel.
martin
^ permalink raw reply
* [PATCH] Fix Documentation/everyday.txt: Junio's workflow
From: Horst H. von Brand @ 2006-06-05 2:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Dmitry V. Levin
The workflow for Junio was badly formatted.
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/everyday.txt | 21 +++++++++++++--------
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index ffba543..6745ab5 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -336,15 +336,20 @@ master, nor exposed as a part of a stabl
<11> make sure I did not accidentally rewind master beyond what I
already pushed out. "ko" shorthand points at the repository I have
at kernel.org, and looks like this:
- $ cat .git/remotes/ko
- URL: kernel.org:/pub/scm/git/git.git
- Pull: master:refs/tags/ko-master
- Pull: maint:refs/tags/ko-maint
- Push: master
- Push: +pu
- Push: maint
++
+------------
+$ cat .git/remotes/ko
+URL: kernel.org:/pub/scm/git/git.git
+Pull: master:refs/tags/ko-master
+Pull: maint:refs/tags/ko-maint
+Push: master
+Push: +pu
+Push: maint
+------------
++
In the output from "git show-branch", "master" should have
everything "ko-master" has.
+
<12> push out the bleeding edge.
<13> push the tag out, too.
@@ -390,7 +395,7 @@ service git
port = 9418
socket_type = stream
wait = no
- user = root
+ user = nobody
server = /usr/bin/git-daemon
server_args = --inetd --syslog --export-all --base-path=/pub/scm
log_on_failure += USERID
--
1.3.3.g16a4
^ permalink raw reply related
* Re: git daemon directory munging?
From: Jon Loeliger @ 2006-06-05 2:10 UTC (permalink / raw)
To: git
> Well, you can bind different git daemons to different IP addresses
> (IP-based vhosting) or different ports (with SRV records in DNS.)
Is there existing support for telling the git-daemon what
specific IP to bind to out of an inetd setup and I just
missed it?
I could set that up realatively easily and gain the
functionality I wanted that way too.
I've also hacked in a host interpolation too.
But like you said, canonicalizing it and checking it is likely
a bit of a pain. I've side-stepped one angle of that by
symlinking in my /pub directory for multiple different
hostnames too. :-)
jdl
^ permalink raw reply
* [PATCH] Fix Documentation/everyday.txt: Junio's workflow
From: Horst H. von Brand @ 2006-06-05 2:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The workflow for Junio was badly formatted.
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/everyday.txt | 21 +++++++++++++--------
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index ffba543..6745ab5 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -336,15 +336,20 @@ master, nor exposed as a part of a stabl
<11> make sure I did not accidentally rewind master beyond what I
already pushed out. "ko" shorthand points at the repository I have
at kernel.org, and looks like this:
- $ cat .git/remotes/ko
- URL: kernel.org:/pub/scm/git/git.git
- Pull: master:refs/tags/ko-master
- Pull: maint:refs/tags/ko-maint
- Push: master
- Push: +pu
- Push: maint
++
+------------
+$ cat .git/remotes/ko
+URL: kernel.org:/pub/scm/git/git.git
+Pull: master:refs/tags/ko-master
+Pull: maint:refs/tags/ko-maint
+Push: master
+Push: +pu
+Push: maint
+------------
++
In the output from "git show-branch", "master" should have
everything "ko-master" has.
+
<12> push out the bleeding edge.
<13> push the tag out, too.
@@ -390,7 +395,7 @@ service git
port = 9418
socket_type = stream
wait = no
- user = root
+ user = nobody
server = /usr/bin/git-daemon
server_args = --inetd --syslog --export-all --base-path=/pub/scm
log_on_failure += USERID
--
1.3.3.g16a4
^ permalink raw reply related
* Re: irc usage..
From: Alec Warner @ 2006-06-05 2:36 UTC (permalink / raw)
To: Martin Langhoff
Cc: Donnie Berkholz, Linus Torvalds, Yann Dirson, Git Mailing List,
Matthias Urlichs, Johannes Schindelin
In-Reply-To: <46a038f90606041906k66d85152v6e402c65151d7ab8@mail.gmail.com>
Martin Langhoff wrote:
> On 6/5/06, Alec Warner <antarus@gentoo.org> wrote:
>
>> Ok the box this was running on had issues, so I switched to using
>> pearl.amd64.dev.gentoo.org, a dual core amd64 X2 4600+ with 4 gigs of
>> ram and plenty of disk. The "problem" now is just converstion time...30
>> hours and I'm into 2004-09-17...but it's been in 2004 all day, seems
>> like most of the commits are in the last three years. Are there
>> architectural issues with doing this in parallel?
>
>
> I don't think you can do this in parallel. What I would do is remove
> the -a from the git-repack invocation. It does hurt import times quite
> a bit -- just do a git-repack -a -d when it's done.
Only repack at the end then? disk space isn't an issue here so I'll give
that a shot.
>
> And... having said that, there is still a memory leak somehow,
> somewhere. It's been evading me for 2 weeks now, so I feel an idiot
> now. Not too bad in general, but it shows clearly in the gentoo and
> mozilla imports.
30565 antarus 17 0 470m 456m 1640 S 14 11.6 234:23.38
git-cvsimport
30566 antarus 16 0 6753m 147m 752 S 7 3.7 120:27.06 cvs
I'm on cvs-1.11.12 and the git version of git
> You are forced to do it in a sequence because cvsps only tells you
> about the files added/removed/changed in a commit -- you need the
> ancestor to have a view of what the whole tree looked like. The only
> room for parallelism I see is to fork off new processes to work on
> branches in parallel.
Not helpful in the Gentoo case, since we only have one branch; minus an
accident when a dev branched gentoo-x86 a while back ;)
I'll keep chugging on this one; it won't be the final import as I
haven't used the complete Authors file, so I will try the repacking
optimization next time I do an import.
-Alec Warner
^ permalink raw reply
* Re: git daemon directory munging?
From: H. Peter Anvin @ 2006-06-05 2:59 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1Fn4Xf-0000bL-82@jdl.com>
Jon Loeliger wrote:
>> Well, you can bind different git daemons to different IP addresses
>> (IP-based vhosting) or different ports (with SRV records in DNS.)
>
> Is there existing support for telling the git-daemon what
> specific IP to bind to out of an inetd setup and I just
> missed it?
>
No, but that really should be added. It's a pretty trivial hack.
> I could set that up realatively easily and gain the
> functionality I wanted that way too.
>
> I've also hacked in a host interpolation too.
>
> But like you said, canonicalizing it and checking it is likely
> a bit of a pain. I've side-stepped one angle of that by
> symlinking in my /pub directory for multiple different
> hostnames too. :-)
>
Doesn't work very well. DNS is case-insensitive, and worse, there are
the PunyCode aliases or whatever they're called.
-hpa
^ permalink raw reply
* Re: irc usage..
From: Martin Langhoff @ 2006-06-05 3:49 UTC (permalink / raw)
To: antarus
Cc: Donnie Berkholz, Linus Torvalds, Yann Dirson, Git Mailing List,
Matthias Urlichs, Johannes Schindelin
In-Reply-To: <448398BC.5090402@gentoo.org>
On 6/5/06, Alec Warner <antarus@gentoo.org> wrote:
> > I don't think you can do this in parallel. What I would do is remove
> > the -a from the git-repack invocation. It does hurt import times quite
> > a bit -- just do a git-repack -a -d when it's done.
>
> Only repack at the end then? disk space isn't an issue here so I'll give
> that a shot.
Not exactly -- by removing the -a from the git-repack invocation what
you get is cheap "partial" packing rather than a full repack. This is
somewhat inefficient disk-wise, perhaps by 10% or so. But full repacks
get more and more expensive as the repo grows.
So you don't need to run git-repack -a -d at the end, but it will be a
good measure to see how compact the packing gets.
> > And... having said that, there is still a memory leak somehow,
> > somewhere. It's been evading me for 2 weeks now, so I feel an idiot
> > now. Not too bad in general, but it shows clearly in the gentoo and
> > mozilla imports.
>
> 30565 antarus 17 0 470m 456m 1640 S 14 11.6 234:23.38
> git-cvsimport
> 30566 antarus 16 0 6753m 147m 752 S 7 3.7 120:27.06 cvs
>
> I'm on cvs-1.11.12 and the git version of git
Yep, I see roughly the same. It grows slowly and I don't know why :(
> I'll keep chugging on this one; it won't be the final import as I
> haven't used the complete Authors file, so I will try the repacking
> optimization next time I do an import.
Cool. If it dies for any reason, just do
git-update-ref refs/heads/master refs/heads/origin
git-update-ref HEAD origin
git-checkout
You only need to do this the first time -- after that, the core heads
are set. Rerun the script and it will pick up where it left. If it
dies again, just do git-checkout to see the latest files.
(Above, replace origin with your -o option if you are using it. I
normally use -o cvshead.)
martin
^ permalink raw reply
* [RFC] Add first whack at interpolated daemon paths.
From: Jon Loeliger @ 2006-06-05 3:54 UTC (permalink / raw)
To: git
Modify git protocol to pass in client hostname and
allow it to be interpolated into daemon source dir.
New --interpolated-path=<path> option.
---
Makefile | 1 +
connect.c | 16 +++++++-
daemon.c | 113 ++++++++++++++++++++++++++++++++++++++++++++++++++-------
interpolate.c | 74 +++++++++++++++++++++++++++++++++++++
interpolate.h | 10 +++++
5 files changed, 198 insertions(+), 16 deletions(-)
This is really RFC-ish. No canonicalization of hostname is done.
It is backwards compatible with existing daemon path handling,
but also allows for future extensibility with more "extended"
client args being supplied. The interpolate code is pretty
generic, but the table driving it in this case is hard coded.
Tons of loginfo() crap left in here to be cleaned up.
diff --git a/Makefile b/Makefile
index 004c216..6a02236 100644
--- a/Makefile
+++ b/Makefile
@@ -211,6 +211,7 @@ DIFF_OBJS = \
LIB_OBJS = \
blob.o commit.o connect.o csum-file.o cache-tree.o base85.o \
date.o diff-delta.o entry.o exec_cmd.o ident.o index.o \
+ interpolate.o \
object.o pack-check.o patch-delta.o path.o pkt-line.o \
quote.o read-cache.o refs.o run-command.o dir.o \
server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
diff --git a/connect.c b/connect.c
index 54f7bf7..9e7b276 100644
--- a/connect.c
+++ b/connect.c
@@ -374,7 +374,13 @@ static int git_tcp_connect(int fd[2], co
fd[0] = sockfd;
fd[1] = sockfd;
- packet_write(sockfd, "%s %s\n", prog, path);
+
+ /*
+ * Separate original protocol components prog and path
+ * from extended components with a NUL byte.
+ */
+ packet_write(sockfd, "%s %s%cHOST=%s\n", prog, path, 0, host);
+
return 0;
}
@@ -443,7 +449,13 @@ static int git_tcp_connect(int fd[2], co
fd[0] = sockfd;
fd[1] = sockfd;
- packet_write(sockfd, "%s %s\n", prog, path);
+
+ /*
+ * Separate original protocol components prog and path
+ * from extended components with a NUL byte.
+ */
+ packet_write(sockfd, "%s %s%cHOST=%s\n", prog, path, 0, host);
+
return 0;
}
diff --git a/daemon.c b/daemon.c
index 776749e..0c9ebe3 100644
--- a/daemon.c
+++ b/daemon.c
@@ -10,6 +10,7 @@ #include <syslog.h>
#include "pkt-line.h"
#include "cache.h"
#include "exec_cmd.h"
+#include "interpolate.h"
static int log_syslog;
static int verbose;
@@ -18,7 +19,8 @@ static int reuseaddr;
static const char daemon_usage[] =
"git-daemon [--verbose] [--syslog] [--inetd | --port=n] [--export-all]\n"
" [--timeout=n] [--init-timeout=n] [--strict-paths]\n"
-" [--base-path=path] [--user-path | --user-path=path]\n"
+" [--base-path=path] [--interpolated-path=path]\n"
+" [--user-path | --user-path=path]\n"
" [--reuseaddr] [directory...]";
/* List of acceptable pathname prefixes */
@@ -28,8 +30,15 @@ static int strict_paths = 0;
/* If this is set, git-daemon-export-ok is not required */
static int export_all_trees = 0;
-/* Take all paths relative to this one if non-NULL */
+/*
+ * Take all paths relative to this one if non-NULL.
+ *
+ */
static char *base_path = NULL;
+static char *interpolated_path = NULL;
+
+/* Flag indicating client sent extra args. */
+int saw_extended_args = 0;
/* If defined, ~user notation is allowed and the string is inserted
* after ~user/. E.g. a request to git://host/~alice/frotz would
@@ -41,6 +50,23 @@ static char *user_path = NULL;
static unsigned int timeout = 0;
static unsigned int init_timeout = 0;
+/*
+ * Static table for now. Ugh.
+ * Feel free to make dynamic as needed.
+ */
+#define INTERP_SLOT_HOST (0)
+#define INTERP_SLOT_DIR (1)
+#define INTERP_SLOT_PERCENT (2)
+
+struct interp interp_table[] = {
+ { "%H", 0},
+ { "%D", 0},
+ { "%%", "%"},
+};
+
+#define N_INTERPS (sizeof(interp_table) / sizeof(struct interp))
+
+
static void logreport(int priority, const char *err, va_list params)
{
/* We should do a single write so that it is atomic and output
@@ -142,10 +168,15 @@ static int avoid_alias(char *p)
}
}
-static char *path_ok(char *dir)
+static char *path_ok(struct interp *itable)
{
static char rpath[PATH_MAX];
+ static char interp_path[PATH_MAX];
char *path;
+ char *dir;
+
+ dir = itable[INTERP_SLOT_DIR].value;
+ loginfo("Request for '%s'", dir);
if (avoid_alias(dir)) {
logerror("'%s': aliased", dir);
@@ -174,16 +205,34 @@ static char *path_ok(char *dir)
dir = rpath;
}
}
+ else if (interpolated_path && saw_extended_args) {
+ if (*dir != '/') {
+ /* Allow only absolute */
+ logerror("'%s': Non-absolute path denied (interpolated-path active)", dir);
+ return NULL;
+ }
+
+ loginfo("Before interpolation '%s'", dir);
+ loginfo("Interp slot 0 (%s,%s)",
+ interp_table[0].name, interp_table[0].value);
+ loginfo("Interp slot 1 (%s,%s)",
+ interp_table[1].name, interp_table[1].value);
+ interpolate(interp_path, PATH_MAX, interpolated_path,
+ interp_table, N_INTERPS);
+ loginfo("After interpolation '%s'", interp_path);
+ dir = interp_path;
+ }
else if (base_path) {
if (*dir != '/') {
/* Allow only absolute */
logerror("'%s': Non-absolute path denied (base-path active)", dir);
return NULL;
}
- else {
- snprintf(rpath, PATH_MAX, "%s%s", base_path, dir);
- dir = rpath;
- }
+ snprintf(rpath, PATH_MAX, "%s%s", base_path, dir);
+ loginfo("dir was %s", dir);
+ loginfo("base_path is %s", base_path);
+ loginfo("rpath now %s", rpath);
+ dir = rpath;
}
path = enter_repo(dir, strict_paths);
@@ -223,15 +272,13 @@ static char *path_ok(char *dir)
return NULL; /* Fallthrough. Deny by default */
}
-static int upload(char *dir)
+static int upload(struct interp *itable)
{
/* Timeout as string */
char timeout_buf[64];
const char *path;
- loginfo("Request for '%s'", dir);
-
- if (!(path = path_ok(dir)))
+ if (!(path = path_ok(itable)))
return -1;
/*
@@ -264,10 +311,34 @@ static int upload(char *dir)
return -1;
}
+void parse_extra_args(char *extra_args, int buflen)
+{
+ char *val;
+ int vallen;
+ char *end = extra_args + buflen;
+
+ while (extra_args < end && *extra_args) {
+ saw_extended_args = 1;
+ loginfo("Extended arg %s", extra_args);
+ if (strncasecmp("host=", extra_args, 5) == 0) {
+ val = extra_args + 5;
+ vallen = strlen(val) + 1;
+ if (*val) {
+ char *save = xmalloc(vallen);
+ interp_table[INTERP_SLOT_HOST].value = save;
+ safe_strncpy(save, val, vallen);
+ }
+ /* On to the next one */
+ extra_args = val + vallen;
+ }
+ }
+}
+
static int execute(void)
{
static char line[1000];
- int len;
+ int len; /* full packet length, including extended args */
+ int n; /* original protocol part size */
alarm(init_timeout ? init_timeout : timeout);
len = packet_read_line(0, line, sizeof(line));
@@ -276,8 +347,18 @@ static int execute(void)
if (len && line[len-1] == '\n')
line[--len] = 0;
- if (!strncmp("git-upload-pack ", line, 16))
- return upload(line+16);
+ /*
+ * Check for extended args after a NUL byte.
+ */
+ n = strlen(line);
+ if (n != len) {
+ parse_extra_args(line + n + 1, len - n - 1);
+ }
+
+ if (!strncmp("git-upload-pack ", line, 16)) {
+ interp_table[INTERP_SLOT_DIR].value = line+16;
+ return upload(interp_table);
+ }
logerror("Protocol error: '%s'", line);
return -1;
@@ -711,6 +792,10 @@ int main(int argc, char **argv)
base_path = arg+12;
continue;
}
+ if (!strncmp(arg, "--interpolated-path=", 20)) {
+ interpolated_path = arg+20;
+ continue;
+ }
if (!strcmp(arg, "--reuseaddr")) {
reuseaddr = 1;
continue;
diff --git a/interpolate.c b/interpolate.c
new file mode 100644
index 0000000..d936022
--- /dev/null
+++ b/interpolate.c
@@ -0,0 +1,74 @@
+#include <string.h>
+
+#include "interpolate.h"
+
+
+int
+interpolate(char *result, int reslen, char *orig,
+ struct interp *interps, int ninterps)
+{
+ int i;
+ char *p;
+ char *src = orig;
+ char *dest = result;
+ int newlen = 0;
+
+ char *name;
+ char *value;
+ int valuelen;
+
+ do {
+
+ p = strchr(src, '%');
+
+ if (p) {
+ /*
+ * Found a potential interpolation point.
+ */
+ for (i = 0; i < ninterps; i++) {
+ name = interps[i].name;
+ if (strncmp(p, name, strlen(name)) == 0)
+ break;
+ }
+
+ value = interps[i].value;
+ valuelen = strlen(value);
+ printf("Interp: %s to %s\n", name, value);
+
+ int len = p - src;
+ if (newlen + len < reslen) {
+ strncpy(dest, src, len);
+ newlen += len;
+ dest += len;
+ *dest = 0;
+ src = p + strlen(name);
+ if (newlen + valuelen < reslen) {
+ strncpy(dest, value, valuelen);
+ newlen += valuelen;
+ dest += valuelen;
+ *dest = 0;
+ } else {
+ printf("new value %s didn't fit.\n", value);
+ return 0; /* something's not fitting. */
+ }
+ } else {
+ printf("orig part %s didn't fit.\n", src);
+ return 0; /* something's not fitting. */
+ }
+
+ } else {
+ /* Copy remainder */
+ int len = strlen(src);
+ if (newlen < reslen) {
+ strncpy(dest, src, len);
+ dest += len;
+ *dest = 0;
+ } else {
+ printf("Remainder %s didn't fit.\n", src);
+ return 0;
+ }
+ }
+ } while (p);
+
+ return 1; /* successful */
+}
diff --git a/interpolate.h b/interpolate.h
new file mode 100644
index 0000000..3b710ad
--- /dev/null
+++ b/interpolate.h
@@ -0,0 +1,10 @@
+
+struct interp {
+ char *name;
+ char *value;
+};
+
+
+extern int interpolate(char *result, int reslen, char *orig,
+ struct interp *interps, int ninterps);
+
--
1.3.3.g16a4-dirty
^ permalink raw reply related
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-05 6:20 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <e5bfff550606040657p5c1a3dceq3eef254ab64f0e3a@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> What I understand is that git-rev-list lists _first_ the given commit,
> then his parents, then his grandparents and so on _until_ a commit
> which is stated with a preceding '{caret}' is found.
> So everything that is between the given commit and HEAD is never found
> and ignored.
As you now know, the way it works is that it takes an unordered
set of committishes, and performs a set operation that says
"include everybody reachable from positive ones while excluding
everybody reachable from negative ones". --topo-order tells it
to topologically (instead of doing the commit date-order which
it does by default) sort the resulting list. The resulting list
is then written out.
> Is it a problem to change the git-rev-list behaviour to reflect (my
> understanding of) documentation or it breaks something?
I suspect it would break quite many things. Existing users use
the command knowing it is a set operation on an unordered set of
committishes, and expect the command to behave that way. Also
the most typical use A..B translates to ^B A (either internally
or by rev-parse) so "the first" would typically be a negative
one.
I think your "start from positive ones, traverse one by one and
stop traversal that hits the negative one" logic requires the
negative one to be directly on the traversal paths starting from
positive ones to have _any_ effect. We often ask "what's the
ones that are still not merged to the master from the side
branch" while dealing with topic branches:
c-------d---e master time flows from
/ / left to right
--a---b---x---y---z side
and the way to ask that question is "rev-list master..side"
(which is "rev-list side ^master"). It should list z and not
show y nor x nor b nor a.
In order for it to be able to notice that y should not be
listed, it needs to perform traversals from negative ones as
well in order to learn that y is reachable from master.
How would you ask the same question to the modified rev-list
that does "start from positive ones, traverse one by one and
stop traversal that hits the negative one" logic?
I think one useful thing we can do is to generalize what
"describe", "nave-rev", and "merge-base" do to have a command
that takes a committish X and a set of other committish T1..Tn,
and examines if Ti (1<=i<=n) is reachable from X and if X is
reachable from Ti (1<=i<=n), and give a short-hand to specify
the set of T for common patterns like --heads --tags and --all.
But that would not be rev-list; I suspect you would end up doing
something quite similar to what show-branch does.
^ 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