* [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] 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
* 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: 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: 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: [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 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: 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: [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: Importing Mozilla CVS into git
From: Robin Rosenberg (list subscriber) @ 2006-06-04 22:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <200606042325.58884.robin.rosenberg.lists@dewire.com>
Just forget this post... @_@ (except the last line)
söndag 04 juni 2006 23:25 skrev Robin Rosenberg (list subscriber):
> söndag 04 juni 2006 22:00 skrev Linus Torvalds:
> > On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:
> > > Other version control systems simply treat text and binary files
> > > differently. No smart(ass) logic doing the wrong thing.
> >
> > Treating text and binary file differently _is_ the "smart(ass) logic
> > doing the wrong thing".
> >
> > Git really shouldn't do that. The patch was meant to show how you really
> > don't need to - the internal objects would never be "binary vs text",
> > there would be a way to just basically map one onto another.
>
> Your patch assumes all files are text and the transformation doesn't
> corrupt the file, which isn't true. CR-LF combinations cannot be translated
> to LF and vice verse in all files, simply becuase what looks like CR LF
> isn't two characters, but something else. Looking for a nul byte and
> possibly some other magic byte would make you right more often, but not
> always.
>
> [...]
>
> > If you can't be civil, at least be quiet, ok?
> >
> > Linus
>
> A bad joke, I'm sorry. It wasn't ment to be offensive.
>
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Robin Rosenberg (list subscriber) @ 2006-06-04 21:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0606041256480.5498@g5.osdl.org>
söndag 04 juni 2006 22:00 skrev Linus Torvalds:
> On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:
> > Other version control systems simply treat text and binary files
> > differently. No smart(ass) logic doing the wrong thing.
>
> Treating text and binary file differently _is_ the "smart(ass) logic doing
> the wrong thing".
>
> Git really shouldn't do that. The patch was meant to show how you really
> don't need to - the internal objects would never be "binary vs text",
> there would be a way to just basically map one onto another.
Your patch assumes all files are text and the transformation doesn't corrupt
the file, which isn't true. CR-LF combinations cannot be translated to LF and
vice verse in all files, simply becuase what looks like CR LF isn't two
characters, but something else. Looking for a nul byte and possibly some
other magic byte would make you right more often, but not always.
[...]
> If you can't be civil, at least be quiet, ok?
>
> Linus
A bad joke, I'm sorry. It wasn't ment to be offensive.
-- robin
^ permalink raw reply
* Re: [PATCH] Support for configurable git command aliases (v2)
From: Petr Baudis @ 2006-06-04 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060604211931.10117.82695.stgit@machine.or.cz>
Dear diary, on Sun, Jun 04, 2006 at 11:19:31PM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> This patch adds support for configurable aliases for git commands -
> "alias.WHATEVER = which ever" will kick in when you do "git WHATEVER"
> and substitute WHATEVER with "which ever" (splitted to arguments at
> whitespaces).
>
> The second version does all the work in handle_aliases() which was
> inspired by Johannes Schindelin's patch.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
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.
--
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
* [PATCH] Support for configurable git command aliases (v2)
From: Petr Baudis @ 2006-06-04 21:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch adds support for configurable aliases for git commands -
"alias.WHATEVER = which ever" will kick in when you do "git WHATEVER"
and substitute WHATEVER with "which ever" (splitted to arguments at
whitespaces).
The second version does all the work in handle_aliases() which was
inspired by Johannes Schindelin's patch.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/config.txt | 5 ++++
Documentation/git.txt | 3 ++
git.c | 60 ++++++++++++++++++++++++++++++++++++++++++++--
3 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c861c6c..aaaa33d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -91,6 +91,11 @@ core.warnAmbiguousRefs::
If true, git will warn you if the ref name you passed it is ambiguous
and might match multiple refs in the .git/refs/ tree. True by default.
+alias.*::
+ Command aliases for the gitlink:git[1] command wrapper - e.g.
+ after defining "alias.last = cat-file commit HEAD", the invocation
+ "git last" is equivalent to "git cat-file commit HEAD".
+
apply.whitespace::
Tells `git-apply` how to handle whitespaces, in the same way
as the '--whitespace' option. See gitlink:git-apply[1].
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 24ca55d..e474bdf 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -21,6 +21,9 @@ link:everyday.html[Everyday Git] for a u
"man git-commandname" for documentation of each command. CVS users may
also want to read link:cvs-migration.html[CVS migration].
+The COMMAND is either a name of a Git command (see below) or an alias
+as defined in the configuration file (see gitlink:git-repo-config[1]).
+
OPTIONS
-------
--version::
diff --git a/git.c b/git.c
index bc463c9..50850fb 100644
--- a/git.c
+++ b/git.c
@@ -10,6 +10,7 @@ #include <limits.h>
#include <stdarg.h>
#include "git-compat-util.h"
#include "exec_cmd.h"
+#include "cache.h" /* setup_git_directory_gently() */
#include "builtin.h"
@@ -88,13 +89,65 @@ static void handle_internal_command(int
}
}
+static const char *cmd;
+static char *cmdalias;
+
+int git_alias_config(const char *var, const char *value)
+{
+ if (strncmp(var, "alias.", 6))
+ return 0;
+ var += /* strlen("alias.") */ 6;
+ if (!strcmp(var, cmd))
+ cmdalias = strdup(value);
+ return 0;
+}
+
+void handle_alias(int *argc, const char ***argv)
+{
+ /* XXX: We do a redundant git directory detection. */
+ int nongit = 0;
+ const char *subdir;
+
+ if (!isatty(1))
+ return;
+
+ subdir = setup_git_directory_gently(&nongit);
+ if (!nongit) {
+ git_config(git_alias_config);
+ if (cmdalias) {
+ /* More than the worst case: */
+ const char **argv2 = malloc((strlen(cmdalias) + *argc) * sizeof(char*));
+ int argc2 = 0, i = 1;
+
+ while (cmdalias && *cmdalias) {
+ argv2[argc2++] = strsep(&cmdalias, " \t");
+ if (cmdalias)
+ while (*cmdalias == ' ' || *cmdalias == '\t')
+ cmdalias++;
+ }
+ while (i < *argc) {
+ argv2[argc2++] = (*argv)[i++];
+ }
+ argv2[argc2] = NULL;
+ *argv = argv2;
+ *argc = argc2;
+ }
+ }
+
+ /* Go back so that the commands start with clean table */
+ if (subdir)
+ chdir(subdir);
+}
+
+
int main(int argc, const char **argv, char **envp)
{
- const char *cmd = argv[0];
- char *slash = strrchr(cmd, '/');
+ char *slash = strrchr(argv[0], '/');
char git_command[PATH_MAX + 1];
const char *exec_path = NULL;
+ cmd = argv[0];
+
/*
* Take the basename of argv[0] as the command
* name, and the dirname as the default exec_path
@@ -121,6 +174,7 @@ int main(int argc, const char **argv, ch
if (!strncmp(cmd, "git-", 4)) {
cmd += 4;
argv[0] = cmd;
+ handle_alias(&argc, &argv);
handle_internal_command(argc, argv, envp);
die("cannot handle %s internally", cmd);
}
@@ -178,7 +232,7 @@ int main(int argc, const char **argv, ch
exec_path = git_exec_path();
prepend_to_path(exec_path, strlen(exec_path));
- /* See if it's an internal command */
+ handle_alias(&argc, &argv);
handle_internal_command(argc, argv, envp);
/* .. then try the external ones */
^ permalink raw reply related
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-04 20:58 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Paul Mackerras, git
In-Reply-To: <20060603151240.GA4024@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> The problem is of course to come up with some ascii-art which is both
> readable and dense. Below is my mockup of something not using line
> graphics, however using line graphics it might be possible to get
> something more unambiguos but also more "edgy".
I do not necessarily think an ascii-art is needed, nor an
appropriate way to present it to the curses user. When the user
wants to "view" a commit, you could show from which branch heads
and from which tags the commit is reachable, and perhaps which
tag is the latest among the ones reachable from that commit, as
part of the commit detail information you display on the lower
pane (log/diff view).
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.
- 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.
It might make sense to make the log/diff view follow what
happens on the main view when both are on-screen.
^ permalink raw reply
* [PATCH] Makefile: make customization of installation locations easier.
From: Junio C Hamano @ 2006-06-04 20:38 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git, Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index a7ff69b..d20f823 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,8 @@
-PREFIX = $(HOME)
+prefix = $(HOME)
+bindir= $(prefix)/bin
+mandir = $(prefix)/man
+# DESTDIR=
+
LDLIBS = -lcurses
CFLAGS = -Wall -O2
DFLAGS = -g -DDEBUG -Werror
@@ -19,14 +23,15 @@ doc: $(DOCS)
install: all
for prog in $(PROGS); do \
- install $$prog $(PREFIX)/bin; \
+ install $$prog $(DESTDIR)$(bindir); \
done
install-doc: doc
+ mkdir -p $(DESTDIR)$(mandir)/man1 $(DESTDIR)$(mandir)/man5
for doc in $(DOCS); do \
case "$$doc" in \
- *.1) install $$doc $(PREFIX)/man/man1 ;; \
- *.5) install $$doc $(PREFIX)/man/man5 ;; \
+ *.1) install $$doc $(DESTDIR)$(mandir)/man1 ;; \
+ *.5) install $$doc $(DESTDIR)$(mandir)/man5 ;; \
esac \
done
--
1.3.3.gb266
^ permalink raw reply related
* Re: [PATCH] git: handle aliases defined in $GIT_DIR/config
From: Junio C Hamano @ 2006-06-04 20:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606042047160.1598@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> For me, short cuts have to be easy to type, so they never
> include digits, and they are never case sensitive, so I do not
> need any fancy config stuff...
Fair enough, and the spirit is the same as what Pasky suggested
earlier, I think.
However, I am not sure about some parts of the code. I started
mucking with it myself, but realized it is far easier for me to
just let the original submitter, especially the capable one like
you, do a bit more work ;-).
> +#define MAX_ALIAS_ARGS 32
> +
> +static int handle_alias(int *argcp, const char **argv, char **envp)
> +{
> + int i, i2, j = 0;
Please name them src, dst and cnt.
> + char *new_argv[MAX_ALIAS_ARGS];
> +
> + alias_command = argv[0];
> + git_config(git_alias_config);
> + if (!alias_string)
> + return 0;
> +
> + /* split alias_string */
> + new_argv[j++] = alias_string;
> + for (i = i2 = 0; alias_string[i]; i++, i2++) {
> + if (isspace(alias_string[i])) {
> + alias_string[i2] = 0;
> + while (alias_string[++i] && isspace(alias_string[i]));
Please make empty loops easier to read by saying:
while (alias_string[++src] && isspace(alias_string[src]))
; /* skip */
> + new_argv[j++] = alias_string + i;
> + i2 = i;
Do we need to reset dst here? I suspect starting the next
parsed string immediately after the terminating NUL might be
cleaner.
> + if (j >= MAX_ALIAS_ARGS)
> + die("too many args in alias %s",
> + alias_command);
> + } else {
> + if (alias_string[i] == '\\')
> + i++;
Barf when the config line ends with a lone backslash, perhaps?
Since the configuration file parser uses backslash for quoting
itself, the user would need to have double backslashes, I
suspect. We might want to support single/double quote pairs in
this parser as well. I would further suggest separating this
"split single string into a pair of (argc, argv)" into a helper
function, so we can reuse it in other parts of the system later.
> + if (i != i2)
> + alias_string[i2] = alias_string[i];
Doing this unconditionally is probably more readable (i.e. lose
the if condition) -- this is not performance critical part of
the system.
> + }
> + }
> +
> + if (j < 1)
> + die("empty alias: %s", alias_command);
> +
> + /* insert after command name */
> + if (j > 1)
> + memmove(argv + j, argv + 1, (*argcp - 1) * sizeof(char*));
> + memcpy(argv, new_argv, j * sizeof(char*));
Who guarantees the original argv array main() received is big
enough to hold (j-1) additional pointers, I wonder? I think you
would need to allocate a new array, and muck with both argc and
argv of the caller by passing the pointers to them, not just
argc.
> @@ -121,6 +176,7 @@ int main(int argc, const char **argv, ch
> if (!strncmp(cmd, "git-", 4)) {
> cmd += 4;
> argv[0] = cmd;
> + handle_alias(&argc, argv, envp);
Hence probably "handle_alias(&argc, &argv, envp)" is needed here.
> handle_internal_command(argc, argv, envp);
> die("cannot handle %s internally", cmd);
> }
> @@ -178,6 +234,8 @@ int main(int argc, const char **argv, ch
> exec_path = git_exec_path();
> prepend_to_path(exec_path, strlen(exec_path));
>
> + handle_alias(&argc, argv, envp);
> +
... and here.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Linus Torvalds @ 2006-06-04 20:00 UTC (permalink / raw)
To: Robin Rosenberg (list subscriber); +Cc: Jakub Narebski, git
In-Reply-To: <200606042144.45385.robin.rosenberg.lists@dewire.com>
On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:
>
> Other version control systems simply treat text and binary files differently.
> No smart(ass) logic doing the wrong thing.
Treating text and binary file differently _is_ the "smart(ass) logic doing
the wrong thing".
Git really shouldn't do that. The patch was meant to show how you really
don't need to - the internal objects would never be "binary vs text",
there would be a way to just basically map one onto another.
> > I'm absolutely _not_ suggesting merging that patch as-is or even in any
> > form very close to it. It clearly needs a config file entry with filename
> > patterns etc at a minimum.
>
> Do people apply your patches right away, like it's some god-like commandments?
What's your problem here, exactly?
I was just trying to point out that my patch was an example, where
somebody who cares (not me) can use it as a starting point.
If you can't be civil, at least be quiet, ok?
Linus
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Robin Rosenberg (list subscriber) @ 2006-06-04 19:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0606041050010.5498@g5.osdl.org>
söndag 04 juni 2006 19:55 skrev Linus Torvalds:
> On Sun, 4 Jun 2006, Jakub Narebski wrote:
> > > And that shouldn't actually be that hard to do. The most trivial
> > > approach is to have just a pre-trigger on commits, but let's face it,
> > > that would not be a good "full" solution. A better one is to just make
> > > the whole "git update-index" thing just have a "automatically ignore
> > > CR/LF" mode.
> >
> > Why wouldn't it be good solution?
>
> The pre-commit filter thing should work fine, and hey, maybe it's worth
> doing that way. I just worry/think that it will result in tons of noise
> when you do a "git diff" and "git update-index --refresh" on a file that
> has been changed, but then the change reverted.
>
> But I didn't really think it through very deeply, it was just an idle "I
> think the pre-commit hook will fall down when X happens that is a
> non-commit event" thought. I suspect this is one of those things where
> somebody actually working in that kind of environment will figure out what
> the problems are, and what the righ solution is.
>
> > BTW. wouldn't Mercurial encode/decode filters
> >
> > http://www.selenic.com/mercurial/wiki/index.cgi/EncodeDecodeFilter
> >
> > be a better solution than modifying files by "git update-index",
> > with all problems it can cause (not detected binary files, text files
> > which have to be in CR/LF line ending,...).
>
> Please do realize that the patch I sent out was absolutely _not_ meant to
> be taken seriously. It was more a "somebody could try this in a windows
> environment, and if it works as an approach, we can try to do it right".
Other version control systems simply treat text and binary files differently.
No smart(ass) logic doing the wrong thing. A text file gets processed on
check-in AND checkout depending on it's type and the client setting.
Some heuristics may be applied when adding files. i.e look-up according to
magic cookies or looking for bytes that simply do not occur in text files
(e..g a nul byte). Those few systems that I know about treat the type as a
file (as opposed to a version specific) attribute. Some systems have lots of
file types, not just text and binary. Encoding is about the only thing that
would interest me, although not terribly important (except the file name),
but that may be off topic for this thread.
The hash-on-the whole-tree might be a reason for making the attribute
version-specific.
Mercurial's filters sounds like a good way to implement file types in a
generic way as long as git's excellent performance isn't hurt.
> I'm absolutely _not_ suggesting merging that patch as-is or even in any
> form very close to it. It clearly needs a config file entry with filename
> patterns etc at a minimum.
Do people apply your patches right away, like it's some god-like commandments?
-- robin
^ permalink raw reply
* Re: Clean up sha1 file writing
From: H. Peter Anvin @ 2006-06-04 19:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias Lederhofer, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606041139310.5498@g5.osdl.org>
Linus Torvalds wrote:
>
> On Sun, 4 Jun 2006, Linus Torvalds wrote:
>> On Sun, 4 Jun 2006, H. Peter Anvin wrote:
>>> Or if you're getting a SIGWINCH in the middle of it.
>>>
>>> Any POSIX system will interrupt the transfer and return a short read on
>>> receiving a signal.
>> Only for interruptible fd's, though, which normally a real "file" won't
>> be.
>
> And _usually_ only if you actually have a SIGWINCH handler.
>
> Although older Linux kernels were broken in this regard. They'd interrupt
> a socket/pipe read or write even for a signal that ended up being ignored.
>
> So it's absolutely the case that having the loop is always the safer thing
> to do, and it's never the _wrong_ thing to do.
>
Right. I tend to think of it as implementation-defined the cases where
it happen to be safe, with the one exception of transactions which are
smaller than PIPE_BUF that are directed to a pipe.
-hpa
^ permalink raw reply
* [PATCH] git: handle aliases defined in $GIT_DIR/config
From: Johannes Schindelin @ 2006-06-04 18:47 UTC (permalink / raw)
To: git, junkio
If you have a config containing something like this:
[alias]
l = "log --stat -M ORIG_HEAD.."
you can call
git l
and it will do the same as
git log --stat -M ORIG_HEAD..
This also works with hard links.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
For me, short cuts have to be easy to type, so they never
include digits, and they are never case sensitive, so I do not
need any fancy config stuff...
git.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/git.c b/git.c
index bc463c9..846062f 100644
--- a/git.c
+++ b/git.c
@@ -10,6 +10,7 @@ #include <limits.h>
#include <stdarg.h>
#include "git-compat-util.h"
#include "exec_cmd.h"
+#include "cache.h"
#include "builtin.h"
@@ -32,6 +33,60 @@ static void prepend_to_path(const char *
setenv("PATH", path, 1);
}
+static const char *alias_command;
+static char *alias_string = NULL;
+
+static int git_alias_config(const char *var, const char *value)
+{
+ if (!strncmp(var, "alias.", 6) && !strcmp(var + 6, alias_command)) {
+ alias_string = strdup(value);
+ }
+ return 0;
+}
+
+#define MAX_ALIAS_ARGS 32
+
+static int handle_alias(int *argcp, const char **argv, char **envp)
+{
+ int i, i2, j = 0;
+ char *new_argv[MAX_ALIAS_ARGS];
+
+ alias_command = argv[0];
+ git_config(git_alias_config);
+ if (!alias_string)
+ return 0;
+
+ /* split alias_string */
+ new_argv[j++] = alias_string;
+ for (i = i2 = 0; alias_string[i]; i++, i2++) {
+ if (isspace(alias_string[i])) {
+ alias_string[i2] = 0;
+ while (alias_string[++i] && isspace(alias_string[i]));
+ new_argv[j++] = alias_string + i;
+ i2 = i;
+ if (j >= MAX_ALIAS_ARGS)
+ die("too many args in alias %s",
+ alias_command);
+ } else {
+ if (alias_string[i] == '\\')
+ i++;
+ if (i != i2)
+ alias_string[i2] = alias_string[i];
+ }
+ }
+
+ if (j < 1)
+ die("empty alias: %s", alias_command);
+
+ /* insert after command name */
+ if (j > 1)
+ memmove(argv + j, argv + 1, (*argcp - 1) * sizeof(char*));
+ memcpy(argv, new_argv, j * sizeof(char*));
+ *argcp += j - 1;
+
+ return 1;
+}
+
const char git_version_string[] = GIT_VERSION;
static void handle_internal_command(int argc, const char **argv, char **envp)
@@ -121,6 +176,7 @@ int main(int argc, const char **argv, ch
if (!strncmp(cmd, "git-", 4)) {
cmd += 4;
argv[0] = cmd;
+ handle_alias(&argc, argv, envp);
handle_internal_command(argc, argv, envp);
die("cannot handle %s internally", cmd);
}
@@ -178,6 +234,8 @@ int main(int argc, const char **argv, ch
exec_path = git_exec_path();
prepend_to_path(exec_path, strlen(exec_path));
+ handle_alias(&argc, argv, envp);
+
/* See if it's an internal command */
handle_internal_command(argc, argv, envp);
--
1.3.3.ga182-dirty
^ permalink raw reply related
* Re: Clean up sha1 file writing
From: Linus Torvalds @ 2006-06-04 18:40 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Matthias Lederhofer, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606041136180.5498@g5.osdl.org>
On Sun, 4 Jun 2006, Linus Torvalds wrote:
>
> On Sun, 4 Jun 2006, H. Peter Anvin wrote:
> >
> > Or if you're getting a SIGWINCH in the middle of it.
> >
> > Any POSIX system will interrupt the transfer and return a short read on
> > receiving a signal.
>
> Only for interruptible fd's, though, which normally a real "file" won't
> be.
And _usually_ only if you actually have a SIGWINCH handler.
Although older Linux kernels were broken in this regard. They'd interrupt
a socket/pipe read or write even for a signal that ended up being ignored.
So it's absolutely the case that having the loop is always the safer thing
to do, and it's never the _wrong_ thing to do.
Linus
^ permalink raw reply
* Re: Clean up sha1 file writing
From: Linus Torvalds @ 2006-06-04 18:39 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Matthias Lederhofer, Git Mailing List
In-Reply-To: <4483259A.7090806@zytor.com>
On Sun, 4 Jun 2006, H. Peter Anvin wrote:
>
> Or if you're getting a SIGWINCH in the middle of it.
>
> Any POSIX system will interrupt the transfer and return a short read on
> receiving a signal.
Only for interruptible fd's, though, which normally a real "file" won't
be.
Linus
^ permalink raw reply
* Re: Clean up sha1 file writing
From: H. Peter Anvin @ 2006-06-04 18:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias Lederhofer, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606021416040.5498@g5.osdl.org>
Linus Torvalds wrote:
>
> On Fri, 2 Jun 2006, H. Peter Anvin wrote:
>> Linus Torvalds wrote:
>>> Any POSIX-conformant OS/filesystem should always do a full write for a
>>> regular file, unless a serious error happens.
>>>
>> Actually, at least Linux won't, if the object is larger than 2 GB on a 64-bit
>> system :)
>
> Yeah, true.
>
> In the end, you should always have the loop. That way, you never have to
> worry about what kind of file descriptor it is, what kind of filesystem
> you're running on, and what the limits of ssize_t might be.
>
Or if you're getting a SIGWINCH in the middle of it.
Any POSIX system will interrupt the transfer and return a short read on
receiving a signal.
-hpa
^ permalink raw reply
* gitview: Add some useful keybindings.
From: Aneesh Kumar K.V @ 2006-06-04 18:07 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0001-gitview-Add-some-useful-keybindings.txt --]
[-- Type: text/plain, Size: 1873 bytes --]
gitview: Add some useful keybindings.
key binding for maximize, fullscreen, unfullscreen
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 15 +++++++++++++++
contrib/gitview/gitview.txt | 6 ++++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index b836047..3b6bdce 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -450,6 +450,9 @@ class GitView:
self.accel_group = gtk.AccelGroup()
self.window.add_accel_group(self.accel_group)
self.accel_group.connect_group(0xffc2, 0, gtk.ACCEL_LOCKED, self.refresh);
+ self.accel_group.connect_group(0xffc1, 0, gtk.ACCEL_LOCKED, self.maximize);
+ self.accel_group.connect_group(0xffc8, 0, gtk.ACCEL_LOCKED, self.fullscreen);
+ self.accel_group.connect_group(0xffc9, 0, gtk.ACCEL_LOCKED, self.unfullscreen);
self.window.add(self.construct())
@@ -461,6 +464,18 @@ class GitView:
self.window.show()
return True
+ def maximize(self, widget, event=None, *arguments, **keywords):
+ self.window.maximize()
+ return True
+
+ def fullscreen(self, widget, event=None, *arguments, **keywords):
+ self.window.fullscreen()
+ return True
+
+ def unfullscreen(self, widget, event=None, *arguments, **keywords):
+ self.window.unfullscreen()
+ return True
+
def get_bt_sha1(self):
""" Update the bt_sha1 dictionary with the
respective sha1 details """
diff --git a/contrib/gitview/gitview.txt b/contrib/gitview/gitview.txt
index e3bc4f4..6924df2 100644
--- a/contrib/gitview/gitview.txt
+++ b/contrib/gitview/gitview.txt
@@ -26,8 +26,14 @@ OPTIONS
<args>
All the valid option for git-rev-list(1)
Key Bindings:
+ F4:
+ To maximize the window
F5:
To reread references.
+ F11:
+ Full screen
+ F12:
+ Leave full screen
EXAMPLES
------
--
1.3.3.g16a4-dirty
^ permalink raw reply related
* Re: [PATCH 0/27] Documentation: Spelling fixes
From: Nikolai Weibull @ 2006-06-04 17:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Horst.H.von.Brand, git
In-Reply-To: <7vk67xenfe.fsf@assigned-by-dhcp.cox.net>
On 6/4/06, Junio C Hamano <junkio@cox.net> wrote:
> Most do not seem to be typoes, depending on where you learned
> the language (XYZour vs XYZor; ok, Ok, and OK; ie vs i.e.).
Where do you write "ie" instead of "i.e."?
In Swedish, there has been a trend to remove dots from abbreviated
expressions, but it seems people are returning to use dots.
Personally, I find that dots make things a lot clearer.
nikolai
^ 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