* Re: [PATCH] First cut at libifying revlist generation
From: Johannes Schindelin @ 2006-02-27 1:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602251608160.22647@g5.osdl.org>
Hi,
beware of that patch. It breaks at least one thing: cloning a repository
with a tag pointing to a tag object (the tag is cloned, but not the tag
object).
Sorry to not fix it right away, but I am just too tired.
By way of figuring this out, I just found a (warning: irony) "cute
feature" of git-bisect. I needed to apply a certain patch to trigger a
certain bug. So I always applied that patch after bisect chose the next
rev, and of course committed it so that bisect could continue.
(In hindsight, I probably should've applied the patch,
git-update-index'ed the file, and hoped that the merge mechanism take care
of it.)
Now, short of finding the correct commit, bisect would loop endlessly,
giving me the same rev to test over and over again (saying "2 revs to go
after this"), because I would label the current rev (which was the applied
patch, not the bad rev) as bad.
So, in a very real sense, it might not be such a phantastic idea as was
suggested earlier on this list, that you are able to commit on top of a
bisected rev.
Good night and good luck,
Dscho
^ permalink raw reply
* Re: Recoding of {git,cg}-log output
From: Petr Baudis @ 2006-02-27 1:26 UTC (permalink / raw)
To: Krzysiek Pawlik; +Cc: Git Mailing List
In-Reply-To: <44024384.4060406@people.pl>
Dear diary, on Mon, Feb 27, 2006 at 01:10:44AM CET, I got a letter
where Krzysiek Pawlik <krzysiek.pawlik@people.pl> said that...
>
> First: a little "why": having /usr/bin/vim as PAGER allows to enter
> UTF-8 commit messages quite easily, the problem is when git-log (or
> cg-log) is run in terminal that's not UTF-8. In my case: terminal is
> ISO-8859-2 and:
>
> nelchael@nelchael ~$ cat ~/.vimrc | grep gitci
> au BufRead /tmp/gitci* setlocal textwidth=75 fileencoding=utf-8
> encoding=utf-8 fileencodings=utf-8,default
Wouldn't it be enough to also set termencoding?
> So... having {git,cg}-log recode the log entires when displaying is
> quite useful. Two patches attached:
>
> a. git-log-recode.patch - uses iconv to recode the log output to
> GIT_LOG_RECODE encoding
> b. cg-log-recode.patch - the same, but for cogito
>
> With this patches it's possible to write UTF-8 commit messages and see
> them ok in non-UTF-8 terminal in log by having GIT_LOG_RECODE=iso-8859-2.
>
> Comments?
Not opposed in principle. But it would be much more sensible to have
something like $GIT_META_ENCODING (defaulting probably to utf8), recode
to whatever is your current locale, have the appropriate setting in the
configfile, ...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: NT directory traversal speed on 25K files on Cygwin
From: Christopher Faylor @ 2006-02-27 1:18 UTC (permalink / raw)
To: git
In-Reply-To: <20060226231701.GA11961@nospam.com>
On Mon, Feb 27, 2006 at 12:17:01AM +0100, Rutger Nijlunsing wrote:
>On Sun, Feb 26, 2006 at 02:55:52PM -0500, Christopher Faylor wrote:
>>On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote:
>>>filesystem is slow and locked down, and exec-attribute is NOT really
>>>useful even on NTFS (it is somehow related to execute permission and
>>>open files. I still cannot figure out how exactly are they related).
>>
>>Again, it's not clear if you're talking about Windows or Cygwin but
>>under Cygwin, in the default configuration, the exec attribute means
>>the same thing to cygwin as it does to linux.
>
>I don't know about native Windows speed, but comparing NutCracker with
>Cygwin on a simple 'find . | wc -l' already gives a clue that looking
>at Cygwin to benchmark NT file inspection IO will give a skewed
>picture:
>
>##### NutCracker $ time find . | wc -l
>
>real 0m 1.44s
>user 0m 0.45s
>sys 0m 0.98s
>25794
>
>##### Cygwin $ time c:\\cygwin\\bin\\find . | wc -l
>
>real 0m 6.72s
>user 0m 1.09s
>sys 0m 5.59s
>25794
>
>##### CMD.EXE + DIR /S C:\PROJECT> c:\cygwin\bin\time cmd /c dir /s
>>NUL 0.01user 0.01system 0:05.70elapsed 0%CPU (0avgtext+0avgdata
>6320maxresident)k 0inputs+0outputs (395major+0minor)pagefaults 0swaps
>
>##### Cygwin 'find -ls' (NutCracker doesn't have a '-ls') C:\PROJECT>
>c:\cygwin\bin\time c:\cygwin\bin\find -ls | wc -l 2.79user 7.81system
>0:10.60elapsed 100%CPU (0avgtext+0avgdata 14480maxresident)k 25794
I'm lost. What does this have to do with the exec attribute?
Or, were you just climbing aboard the "Cygwin sure is slow" bandwagon?
cgf
^ permalink raw reply
* [ANNOUNCE] Cogito-0.17
From: Petr Baudis @ 2006-02-27 1:16 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The last winter snow
leaves but Cogito comes in
its place, snow-white 0.17
(*)
After some random bugfixes I got no more bugreports so this feels
stable enough for a release. The rest of this mail will mostly be
a rehash of the 0.17rc1 announcement; the rc2-to-0.17 bugfixes were
rather dull.
Huge amount of new features and cool stuff. The highlight is cg-switch
for switching between local branches and massive cg-patch improvements,
but there is plenty of other stuff as well. Read on for more details.
The notable new stuff includes:
* cg-switch - Cogito finally gives you the full convenience of
multiple local branches in a single repository ;)
* cg-patch -c, -C, -d - Cogito now supports cherrypicking, easy commit
reverts and automatic committing of applied patches
* Resumable cg-clone - if cg-clone fails in the middle of the initial
fetch, the directory is not deleted and you do not have to start all
over again - just cd inside and run cg-fetch and it will DTRT
* Support for tracking rebasing branches; as long as you use cg-update
(NOT cg-fetch + cg-merge) and won't commit local changes, Cogito
will correctly update the branch even if it got rebased in the
meanwhile
* Quoting fixes - this means that Cogito should be now theoretically
100% resilient to whitespaces and metacharacters in filenames etc.
Note that filenames containing newlines still aren't supported and
aren't likely to ever be. You are a loonie. Go away.
* Radically improved cg-fetch progressbar; it still doesn't quite work
with rsync (use cg-fetch -v -v), but I don't think that can be
helped. The main advantage is that it will show HTTP fetch progress
even when fetching large files (especially packs).
* Much more sensible behaviour for cg-clean wrt. untracked directories
(do not erase their content).
* Significant merges speedup (but still quite some potential for
improvement)
* cg-* --help now by default shows only short help; use --long-help
to see the full manual
* cg-commit --signoff
* cg-commit --review to review and even modify the patch you are
committing
* cg-commit -M to take the commit message from a file
* bash commandline autocompletion files in contrib/
* cg-fetch -v, cg-fetch -v -v, cg-merge -v, cg-update -v
* cg-push -r to push a different branch (or even a specific commit)
instead of your current branch
* cg-rm -r for recursive directories removal
* cg-mv trivial wrapper for git-mv
* cg-push over HTTP
* cg-patch -u for applying non-git patches while autoadding/removing
files, cg-patch -pN with obvious meaning
* cg-object-id -d for short human-readable commit string id
(just wraps git-describe)
* Too many minor new features to list here
* Incompatible change - cg-log -d renamed to cg-log -D
* Incompatible change - the post-commit hook won't be ran for all the
merged commits anymore when you commit a merge; you can reenable
that in .git/config, see the cg-commit documentation for details
P.S.: See us at #git @ FreeNode!
P.P.S.: (*) That means bug-free, if it wasn't obvious!
P.P.P.S.: Yes, it just occurred to me that I've forgot about the
pre-built documentation, but it's too late in the night by now. Sorry,
the next time.
Happy hacking,
--
Petr "Pasky the lousy poet" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Recoding of {git,cg}-log output
From: Krzysiek Pawlik @ 2006-02-27 0:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0602270133330.5275@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
Johannes Schindelin wrote:
> Of course, you could always set up a script doing the recoding and
> the paging, like
No.
> The advantage of this approach compared to adjusting git is that
> other programs use PAGER, too.
Passing code (web pages, etc) throught iconv is not a good idea -
{git,cg}-diff should show the file content as it is, not altered by iconv.
Changing PAGER is a bit... ugly and messy way of doing it. Assume that I
work on some files and want to look at some unversioned files outside
the tree (like docs, man pages, whatever) and the $PAGER passes the
legitimate ISO8859-2 files through iconv, what gives us garbage. And we
end up changing pager very often - Bad Idea (TM).
--
Krzysiek Pawlik (Nelchael)
RLU #322999 GPG Key ID: 0xBC555551
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: the war on trailing whitespace
From: Junio C Hamano @ 2006-02-27 0:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, junkio, git
In-Reply-To: <Pine.LNX.4.64.0602261213340.22647@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Personally, I don't mind whitespace that much. In particular, I _suspect_
> I often have empty lines like
>
> int i;
>
> i = 10;
>
> where the "empty" line actually has the same indentation as the lines
> around it. Is that wrong? Perhaps.
Yes, you do, and I hand-fixed one a couple of minutes ago ;-).
Regarding git-apply change, I suspect warn_on_whitespace should
not squelch itself after the first one, and error_on_whitespace
should not die instantly. The sample pre-applypatch hook (it
was missing code to figure out where GIT_DIR was so it never
worked as shipped; corrected in "master") shows line numbers of
suspicious lines from the files being patched. They can be
manually fixed up, and then "git am --resolved", if the
integrator is in a better mood.
The error messages from pre-commit/pre-applypatch hook mimic the
way compiler errors are spit out, so that it works well in Emacs
compilation buffer -- doing C-x ` (next-error) takes you the
line the error appears and lets you edit it.
^ permalink raw reply
* Re: Recoding of {git,cg}-log output
From: Johannes Schindelin @ 2006-02-27 0:36 UTC (permalink / raw)
To: Krzysiek Pawlik; +Cc: Git Mailing List
In-Reply-To: <44024384.4060406@people.pl>
Hi,
On Mon, 27 Feb 2006, Krzysiek Pawlik wrote:
> First: a little "why": having /usr/bin/vim as PAGER allows to enter
> UTF-8 commit messages quite easily, the problem is when git-log (or
> cg-log) is run in terminal that's not UTF-8.
Of course, you could always set up a script doing the recoding and the
paging, like
-- snip --
#!/bin/sh
iconv -f UTF-8 -t ISO-8859-2 "$@" | vim
-- snap --
and point your PAGER to that script (which is untested BTW). The advantage
of this approach compared to adjusting git is that other programs use
PAGER, too.
Hth,
Dscho
^ permalink raw reply
* Re: Make git diff-generation use a simpler spawn-like interface
From: Junio C Hamano @ 2006-02-27 0:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602261547440.22647@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> This actually ends up simplifying the code, and should make it much
> easier to make it efficient under broken operating systems (read: Windows).
>
> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
> ---
>
> Now, somebody else might disagree with my contention that this also makes
> things simpler, but I like how we separate out the "run an external
> program" phase from the actual setup and header printing phase.
I agree this is going in the right direction.
A note that is offtopic to this particular patch but is related
to Andrew's point. I had a wrong version of pre-applypatch hook
in the sample shipped as "templates", and after I rebuilt my
private development repository I've been running with the
version without a fix I personally had. I've pushed out the fix
in the master branch.
I'll look at your patch to git-apply next.
^ permalink raw reply
* [PATCH] contrib/git-svn: add show-ignore command
From: Eric Wong @ 2006-02-27 0:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060226234601.GA28732@localdomain>
Recursively finds and lists the svn:ignore property on
directories. The output is suitable for appending to the
$GIT_DIR/info/exclude file.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Note: Whitespace cleaned
contrib/git-svn/git-svn.perl | 25 +++++++++++++++++++++++++
contrib/git-svn/git-svn.txt | 7 +++++++
2 files changed, 32 insertions(+), 0 deletions(-)
63b497ce5f0762cdfef3ef30ec658b8c98e1a144
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index a32ce15..3d855f1 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -49,6 +49,7 @@ my %cmd = (
fetch => [ \&fetch, "Download new revisions from SVN" ],
init => [ \&init, "Initialize and fetch (import)"],
commit => [ \&commit, "Commit git revisions to SVN" ],
+ 'show-ignore' => [ \&show_ignore, "Show svn:ignore listings" ],
rebuild => [ \&rebuild, "Rebuild git-svn metadata (after git clone)" ],
help => [ \&usage, "Show help" ],
);
@@ -258,6 +259,30 @@ sub commit {
}
+sub show_ignore {
+ require File::Find or die $!;
+ my $exclude_file = "$GIT_DIR/info/exclude";
+ open my $fh, '<', $exclude_file or croak $!;
+ chomp(my @excludes = (<$fh>));
+ close $fh or croak $!;
+
+ $SVN_URL ||= file_to_s("$GIT_DIR/$GIT_SVN/info/url");
+ chdir $SVN_WC or croak $!;
+ my %ign;
+ File::Find::find({wanted=>sub{if(lstat $_ && -d _ && -d "$_/.svn"){
+ s#^\./##;
+ @{$ign{$_}} = safe_qx(qw(svn propget svn:ignore),$_);
+ }}, no_chdir=>1},'.');
+
+ print "\n# /\n";
+ foreach (@{$ign{'.'}}) { print '/',$_ if /\S/ }
+ delete $ign{'.'};
+ foreach my $i (sort keys %ign) {
+ print "\n# ",$i,"\n";
+ foreach (@{$ign{$i}}) { print '/',$i,'/',$_ if /\S/ }
+ }
+}
+
########################### utility functions #########################
sub setup_git_svn {
diff --git a/contrib/git-svn/git-svn.txt b/contrib/git-svn/git-svn.txt
index cf098d7..b4b7789 100644
--- a/contrib/git-svn/git-svn.txt
+++ b/contrib/git-svn/git-svn.txt
@@ -61,6 +61,11 @@ rebuild::
the directory/repository you're tracking has moved or changed
protocols.
+show-ignore::
+ Recursively finds and lists the svn:ignore property on
+ directories. The output is suitable for appending to
+ the $GIT_DIR/info/exclude file.
+
OPTIONS
-------
-r <ARG>::
@@ -152,6 +157,8 @@ Tracking and contributing to an Subversi
git commit git-svn-HEAD..my-branch
# Something is committed to SVN, pull the latest into your branch::
git-svn fetch && git pull . git-svn-HEAD
+# Append svn:ignore settings to the default git exclude file:
+ git-svn show-ignore >> .git/info/exclude
DESIGN PHILOSOPHY
-----------------
--
1.2.2.ga559
^ permalink raw reply related
* Recoding of {git,cg}-log output
From: Krzysiek Pawlik @ 2006-02-27 0:10 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 873 bytes --]
First: a little "why": having /usr/bin/vim as PAGER allows to enter
UTF-8 commit messages quite easily, the problem is when git-log (or
cg-log) is run in terminal that's not UTF-8. In my case: terminal is
ISO-8859-2 and:
nelchael@nelchael ~$ cat ~/.vimrc | grep gitci
au BufRead /tmp/gitci* setlocal textwidth=75 fileencoding=utf-8
encoding=utf-8 fileencodings=utf-8,default
So... having {git,cg}-log recode the log entires when displaying is
quite useful. Two patches attached:
a. git-log-recode.patch - uses iconv to recode the log output to
GIT_LOG_RECODE encoding
b. cg-log-recode.patch - the same, but for cogito
With this patches it's possible to write UTF-8 commit messages and see
them ok in non-UTF-8 terminal in log by having GIT_LOG_RECODE=iso-8859-2.
Comments?
--
Krzysiek Pawlik (Nelchael)
RLU #322999 GPG Key ID: 0xBC555551
[-- Attachment #1.2: cg-log-recode.patch --]
[-- Type: text/plain, Size: 889 bytes --]
--- /usr/bin/cg-log 2006-01-19 17:22:22.000000000 +0100
+++ bin/cg-log 2006-02-27 00:59:07.000000000 +0100
@@ -348,13 +348,21 @@
if [ "$shortlog" ]; then
# Special care here.
- $revls $sep "${ARGS[@]}" | git-shortlog | pager
+ if [ -n "${GIT_LOG_RECODE}" ]; then
+ $revls $sep "${ARGS[@]}" | git-shortlog | iconv --from-code=UTF-8 --to-code="${GIT_LOG_RECODE}" | pager
+ else
+ $revls $sep "${ARGS[@]}" | git-shortlog | pager
+ fi
exit
fi
# LESS="S" will prevent less to wrap too long titles to multiple lines;
# you can scroll horizontally.
-$revls $sep "${ARGS[@]}" | print_commit_log | _local_CG_LESS="S" pager
+if [ -n "${GIT_LOG_RECODE}" ]; then
+ $revls $sep "${ARGS[@]}" | print_commit_log | iconv --from-code=UTF-8 --to-code="${GIT_LOG_RECODE}" | _local_CG_LESS="S" pager
+else
+ $revls $sep "${ARGS[@]}" | print_commit_log | _local_CG_LESS="S" pager
+fi
exit 0
[-- Attachment #1.3: git-log-recode.patch --]
[-- Type: text/plain, Size: 544 bytes --]
--- /usr/bin/git-log 2006-02-23 18:31:32.000000000 +0100
+++ bin/git-log 2006-02-27 00:47:34.000000000 +0100
@@ -11,5 +11,11 @@
[ "$revs" ] || {
die "No HEAD ref"
}
-git-rev-list --pretty $(git-rev-parse --default HEAD "$@") |
-LESS=-S ${PAGER:-less}
+if [ -n "${GIT_LOG_RECODE}" ]; then
+ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \
+ iconv --from-code=UTF-8 --to-code="${GIT_LOG_RECODE}" | \
+ LESS=-S ${PAGER:-less}
+else
+ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \
+ LESS=-S ${PAGER:-less}
+fi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: git-svn and working with tags
From: Eric Wong @ 2006-02-27 0:07 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <4401933B.2070109@iaglans.de>
Nicolas Vilz 'niv' <niv@iaglans.de> wrote:
> Hi guys,
>
> I am about to use a git/svn construct for a project next week to track
> my work and the work of my co-workers.
>
> Reason for this is, that all the others are working on windows-boxes and
> I am the lonesome gunman, who wants to work with git on a linux box
> contributing the others on svn side.
>
> There is still a lot of work todo, preparing both backends, git and svn,
> for serving almost the same content structure.
>
> I think, i can do a little scripting to switch my git-SVN-HEAD to
> another branch. But how am i intended to export tags to svn?
>
> tags should simply go to <repos>/tags/<tagname>
> branches go to <repos>/branches/<branchname>
> master goes to <repos>/trunk
>
> A svn-import should be no problem then. The re-exporting back to one
> branch or svn_path is described in git-svn howto. but how about tags?
>
> do i have to consider the tags on svn-side manually?
You'll need to do tags on the svn-side manually. git-svn (by-design)
has hardly any notion of SVN tags (they're really just branches
designated as read-only). git-svn also fails to track directory copies
[1], so using git-svn to track a higher-level directory and performing a
copy in git and doing git-svn commit may not work so well.
You can make something that parses a git commit that was imported in
git-svn-HEAD. These imported commits have a 'git-svn-id:' line at the
end that can be parsed for URL and revision number, so you could make it
frontend 'svn cp' pretty easily.
[1]: git-diff-* doesn't notice copied/renamed directories. I'm
actually very thankful for this as it's very prone to bugs in my
experience.
--
Eric Wong
^ permalink raw reply
* Make git diff-generation use a simpler spawn-like interface
From: Linus Torvalds @ 2006-02-26 23:51 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Instead of depending of fork() and execve() and doing things in between
the two, make the git diff functions do everything up front, and then do
a single "spawn_prog()" invocation to run the actual external diff
program (if any is even needed).
This actually ends up simplifying the code, and should make it much
easier to make it efficient under broken operating systems (read: Windows).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
Now, somebody else might disagree with my contention that this also makes
things simpler, but I like how we separate out the "run an external
program" phase from the actual setup and header printing phase.
Of course, it still uses fork/execvp here, but now it should be _trivial_
to just have a windows-optimized version of "spawn_prog()" that does that
Windows thang.
Linus
diff --git a/diff.c b/diff.c
index 804c08c..32da5d7 100644
--- a/diff.c
+++ b/diff.c
@@ -178,11 +178,12 @@ static void emit_rewrite_diff(const char
copy_file('+', temp[1].name);
}
-static void builtin_diff(const char *name_a,
+static const char *builtin_diff(const char *name_a,
const char *name_b,
struct diff_tempfile *temp,
const char *xfrm_msg,
- int complete_rewrite)
+ int complete_rewrite,
+ const char **args)
{
int i, next_at, cmd_size;
const char *const diff_cmd = "diff -L%s -L%s";
@@ -242,19 +243,24 @@ static void builtin_diff(const char *nam
}
if (xfrm_msg && xfrm_msg[0])
puts(xfrm_msg);
+ /*
+ * we do not run diff between different kind
+ * of objects.
+ */
if (strncmp(temp[0].mode, temp[1].mode, 3))
- /* we do not run diff between different kind
- * of objects.
- */
- exit(0);
+ return NULL;
if (complete_rewrite) {
- fflush(NULL);
emit_rewrite_diff(name_a, name_b, temp);
- exit(0);
+ return NULL;
}
}
- fflush(NULL);
- execlp("/bin/sh","sh", "-c", cmd, NULL);
+
+ /* This is disgusting */
+ *args++ = "sh";
+ *args++ = "-c";
+ *args++ = cmd;
+ *args = NULL;
+ return "/bin/sh";
}
struct diff_filespec *alloc_filespec(const char *path)
@@ -559,6 +565,40 @@ static void remove_tempfile_on_signal(in
raise(signo);
}
+static int spawn_prog(const char *pgm, const char **arg)
+{
+ pid_t pid;
+ int status;
+
+ fflush(NULL);
+ pid = fork();
+ if (pid < 0)
+ die("unable to fork");
+ if (!pid) {
+ execvp(pgm, (char *const*) arg);
+ exit(255);
+ }
+
+ while (waitpid(pid, &status, 0) < 0) {
+ if (errno == EINTR)
+ continue;
+ return -1;
+ }
+
+ /* Earlier we did not check the exit status because
+ * diff exits non-zero if files are different, and
+ * we are not interested in knowing that. It was a
+ * mistake which made it harder to quit a diff-*
+ * session that uses the git-apply-patch-script as
+ * the GIT_EXTERNAL_DIFF. A custom GIT_EXTERNAL_DIFF
+ * should also exit non-zero only when it wants to
+ * abort the entire diff-* session.
+ */
+ if (WIFEXITED(status) && !WEXITSTATUS(status))
+ return 0;
+ return -1;
+}
+
/* An external diff command takes:
*
* diff-cmd name infile1 infile1-sha1 infile1-mode \
@@ -573,9 +613,9 @@ static void run_external_diff(const char
const char *xfrm_msg,
int complete_rewrite)
{
+ const char *spawn_arg[10];
struct diff_tempfile *temp = diff_temp;
- pid_t pid;
- int status;
+ int retval;
static int atexit_asked = 0;
const char *othername;
@@ -592,59 +632,41 @@ static void run_external_diff(const char
signal(SIGINT, remove_tempfile_on_signal);
}
- fflush(NULL);
- pid = fork();
- if (pid < 0)
- die("unable to fork");
- if (!pid) {
- if (pgm) {
- if (one && two) {
- const char *exec_arg[10];
- const char **arg = &exec_arg[0];
- *arg++ = pgm;
- *arg++ = name;
- *arg++ = temp[0].name;
- *arg++ = temp[0].hex;
- *arg++ = temp[0].mode;
- *arg++ = temp[1].name;
- *arg++ = temp[1].hex;
- *arg++ = temp[1].mode;
- if (other) {
- *arg++ = other;
- *arg++ = xfrm_msg;
- }
- *arg = NULL;
- execvp(pgm, (char *const*) exec_arg);
+ if (pgm) {
+ const char **arg = &spawn_arg[0];
+ if (one && two) {
+ *arg++ = pgm;
+ *arg++ = name;
+ *arg++ = temp[0].name;
+ *arg++ = temp[0].hex;
+ *arg++ = temp[0].mode;
+ *arg++ = temp[1].name;
+ *arg++ = temp[1].hex;
+ *arg++ = temp[1].mode;
+ if (other) {
+ *arg++ = other;
+ *arg++ = xfrm_msg;
}
- else
- execlp(pgm, pgm, name, NULL);
+ } else {
+ *arg++ = pgm;
+ *arg++ = name;
}
- /*
- * otherwise we use the built-in one.
- */
- if (one && two)
- builtin_diff(name, othername, temp, xfrm_msg,
- complete_rewrite);
- else
+ *arg = NULL;
+ } else {
+ if (one && two) {
+ pgm = builtin_diff(name, othername, temp, xfrm_msg, complete_rewrite, spawn_arg);
+ } else
printf("* Unmerged path %s\n", name);
- exit(0);
}
- if (waitpid(pid, &status, 0) < 0 ||
- !WIFEXITED(status) || WEXITSTATUS(status)) {
- /* Earlier we did not check the exit status because
- * diff exits non-zero if files are different, and
- * we are not interested in knowing that. It was a
- * mistake which made it harder to quit a diff-*
- * session that uses the git-apply-patch-script as
- * the GIT_EXTERNAL_DIFF. A custom GIT_EXTERNAL_DIFF
- * should also exit non-zero only when it wants to
- * abort the entire diff-* session.
- */
- remove_tempfile();
+
+ retval = 0;
+ if (pgm)
+ retval = spawn_prog(pgm, spawn_arg);
+ remove_tempfile();
+ if (retval) {
fprintf(stderr, "external diff died, stopping at %s.\n", name);
exit(1);
}
- remove_tempfile();
}
static void diff_fill_sha1_info(struct diff_filespec *one)
^ permalink raw reply related
* Re: Teach the "git" command to handle some commands internally
From: Junio C Hamano @ 2006-02-26 23:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: Git Mailing List, Andreas Ericsson, Alex Riesen, Michal Ostrowski
In-Reply-To: <Pine.LNX.4.64.0602261518110.22647@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 26 Feb 2006, Junio C Hamano wrote:
>>
>> > There's one other change: the search order for external programs is
>> > modified slightly, so that the first entry remains GIT_EXEC_DIR, but the
>> > second entry is the same directory as the git wrapper itself was executed
>> > out of - if we can figure it out from argv[0], of course.
>>
>> I am not sure about this part, though.
>
> Well, what it means is that _if_ you install all your "git" binaries in
> some directory that is not in your patch and is not GIT_EXEC_DIR, they
> will still magically work, assuming you don't do something strange.
I understood that part. I was wondering if this change defeats
what Michal (you sensibly CC'ed your message to) wanted to do
earlier, going great length trying to avoid mucking with PATH
and "where-ever git itself is found" in the last round. After
reviewing the change in 77cb17 commit, I realize my worry was
unfounded.
^ permalink raw reply
* Re: [PATCH] contrib/git-svn: add show-ignore command
From: Eric Wong @ 2006-02-26 23:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkvx7mve.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> After Andrew Morten raised the issue, I've made sure I _really_
> enable my pre-applypatch hook.
>
> Please enable your pre-commit hook (comes with the distribution
> as a sample hook) to catch these trailing whitespaces before
> they hit your commit objects.
Oops, sorry about this one. I forgot it on the directory I was working
on at the time. I've also added Dave Jones' whitespace hilighter lines
to my .vimrc as well.
--
Eric Wong
^ permalink raw reply
* Re: Teach the "git" command to handle some commands internally
From: Linus Torvalds @ 2006-02-26 23:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Andreas Ericsson, Alex Riesen, Michal Ostrowski
In-Reply-To: <7vbqwt7m3t.fsf@assigned-by-dhcp.cox.net>
On Sun, 26 Feb 2006, Junio C Hamano wrote:
>
> > There's one other change: the search order for external programs is
> > modified slightly, so that the first entry remains GIT_EXEC_DIR, but the
> > second entry is the same directory as the git wrapper itself was executed
> > out of - if we can figure it out from argv[0], of course.
>
> I am not sure about this part, though.
Well, what it means is that _if_ you install all your "git" binaries in
some directory that is not in your patch and is not GIT_EXEC_DIR, they
will still magically work, assuming you don't do something strange.
IOW, you can do things like
alias git=/opt/my-git/git
and all the "git" commands will automatically work fine, even if you
didn't know at compile time where you would install them, and you didn't
set GIT_EXEC_DIR at run-time. It will still first look in GIT_EXEC_DIR,
but if that fails, it will take the git commands from /opt/my-git/ instead
of from /usr/bin or whatever.
It seemed a nice thing to try to make the git wrapper execute whatever git
version it was installed with, rather than depend on PATH.
But hey, it's only a couple of lines out of the whole thing, so you can
certainly skip it (remove the
if (exec_path)
prepend_path(exec_path)
lines to disable it).
Linus
^ permalink raw reply
* NT directory traversal speed on 25K files on Cygwin
From: Rutger Nijlunsing @ 2006-02-26 23:17 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060226195552.GA30735@trixie.casa.cgf.cx>
On Sun, Feb 26, 2006 at 02:55:52PM -0500, Christopher Faylor wrote:
> On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote:
> >filesystem is slow and locked down, and exec-attribute is NOT really
> >useful even on NTFS (it is somehow related to execute permission and
> >open files. I still cannot figure out how exactly are they related).
>
> Again, it's not clear if you're talking about Windows or Cygwin but
> under Cygwin, in the default configuration, the exec attribute means the
> same thing to cygwin as it does to linux.
I don't know about native Windows speed, but comparing NutCracker with
Cygwin on a simple 'find . | wc -l' already gives a clue that looking
at Cygwin to benchmark NT file inspection IO will give a skewed
picture:
##### NutCracker
$ time find . | wc -l
real 0m 1.44s
user 0m 0.45s
sys 0m 0.98s
25794
##### Cygwin
$ time c:\\cygwin\\bin\\find . | wc -l
real 0m 6.72s
user 0m 1.09s
sys 0m 5.59s
25794
##### CMD.EXE + DIR /S
C:\PROJECT> c:\cygwin\bin\time cmd /c dir /s >NUL
0.01user 0.01system 0:05.70elapsed 0%CPU (0avgtext+0avgdata 6320maxresident)k
0inputs+0outputs (395major+0minor)pagefaults 0swaps
##### Cygwin 'find -ls' (NutCracker doesn't have a '-ls')
C:\PROJECT> c:\cygwin\bin\time c:\cygwin\bin\find -ls | wc -l
2.79user 7.81system 0:10.60elapsed 100%CPU (0avgtext+0avgdata 14480maxresident)k
25794
Regards,
Rutger.
--
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------
^ permalink raw reply
* Re: Teach the "git" command to handle some commands internally
From: Junio C Hamano @ 2006-02-26 23:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: Git Mailing List, Andreas Ericsson, Alex Riesen, Michal Ostrowski
In-Reply-To: <Pine.LNX.4.64.0602261225500.22647@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> This also implies that to support the old "git-log" and "git-diff" syntax,
> the "git" wrapper now automatically looks at the name it was executed as,
> and if it is "git-xxxx", it will assume that it is to internally do what
> "git xxxx" would do.
>
> In other words, you can (once you implement an internal command) soft- or
> hard-link that command to the "git" wrapper command, and it will do the
> right thing, whether you use the "git xxxx" or the "git-xxxx" format.
I like this careful backward compatibility part.
> There's one other change: the search order for external programs is
> modified slightly, so that the first entry remains GIT_EXEC_DIR, but the
> second entry is the same directory as the git wrapper itself was executed
> out of - if we can figure it out from argv[0], of course.
I am not sure about this part, though.
^ permalink raw reply
* Re: [PATCH] contrib/git-svn: add show-ignore command
From: Junio C Hamano @ 2006-02-26 22:53 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <11409493473353-git-send-email-normalperson@yhbt.net>
After Andrew Morten raised the issue, I've made sure I _really_
enable my pre-applypatch hook.
Please enable your pre-commit hook (comes with the distribution
as a sample hook) to catch these trailing whitespaces before
they hit your commit objects.
Applying 'contrib/git-svn: add show-ignore command'
*
* You have some suspicious patch lines:
*
* In contrib/git-svn/git-svn.perl
* trailing whitespace (line 268)
contrib/git-svn/git-svn.perl:268:
* trailing whitespace (line 276)
contrib/git-svn/git-svn.perl:276:
^ permalink raw reply
* Re: [PATCH] Add a Documentation/git-tools.txt
From: Junio C Hamano @ 2006-02-26 22:51 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, Alexandre Julliard
In-Reply-To: <e5bfff550602260022jde1fe2n4ec117c609a5d22d@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> A brief survey of useful git tools, including third-party
> and external projects.
>
> Signed-off-by: Marco Costalba <mcostalba@gmail.com>
> ---
>
> Suggestions/corrections from the list has been collected during the
> past week, so I resend
> the updated patch.
>
> Please consider for apply.
Thanks. I've considered it, but it is seriously linewrapped.
> + - *pcl-cvs* (contrib/)
> +
> + This is an Emacs interface for git. The user interface is
> modeled on
> + pcl-cvs.
Also is the emacs one really pcl-cvs? I thought it was modeled
after pcl-cvs, but this is a different implementation to deal
with git. If Alexandre does not have a name for it, I'd say
we'll list it as "git.el".
^ permalink raw reply
* [PATCH] annotate: Use qx{} for pipes on activestate.
From: Ryan Anderson @ 2006-02-26 21:09 UTC (permalink / raw)
To: junkio; +Cc: merlyn, git, Ryan Anderson
In-Reply-To: <1140922925166-git-send-email-ryan@michonline.com>
Note: This needs someone to tell me what the value of $^O is on ActiveState.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
As always, available in
http://h4x0r5.com/~ryan/git/ryan.git/ annotate-upstream
Randal, does this look basically the right approach here?
(I would like to make that glob I use not a global, but I can't
seem to figure out how at the moment.)
git-annotate.perl | 43 ++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 42 insertions(+), 1 deletions(-)
a927bb08b9b319cc3832fcf354a75e3760af593c
diff --git a/git-annotate.perl b/git-annotate.perl
index ee8ff15..f9c2c6c 100755
--- a/git-annotate.perl
+++ b/git-annotate.perl
@@ -431,8 +431,20 @@ sub gitvar_name {
return join(' ', @field[0...(@field-4)]);
}
-
sub open_pipe {
+ if ($^O eq '##INSERT_ACTIVESTATE_STRING_HERE##') {
+ return open_pipe_activestate(@_);
+ } else {
+ return open_pipe_normal(@_);
+ }
+}
+
+sub open_pipe_activestate {
+ tie *fh, "Git::ActiveStatePipe", @_;
+ return *fh;
+}
+
+sub open_pipe_normal {
my (@execlist) = @_;
my $pid = open my $kid, "-|";
@@ -445,3 +457,32 @@ sub open_pipe {
return $kid;
}
+
+package Git::ActiveStatePipe;
+use strict;
+
+sub TIEHANDLE {
+ my ($class, @params) = @_;
+ my $cmdline = join " ", @params;
+ my @data = qx{$cmdline};
+ bless { i => 0, data => \@data }, $class;
+}
+
+sub READLINE {
+ my $self = shift;
+ if ($self->{i} >= scalar @{$self->{data}}) {
+ return undef;
+ }
+ return $self->{'data'}->[ $self->{i}++ ];
+}
+
+sub CLOSE {
+ my $self = shift;
+ delete $self->{data};
+ delete $self->{i};
+}
+
+sub EOF {
+ my $self = shift;
+ return ($self->{i} >= scalar @{$self->{data}});
+}
--
1.2.3.g9ca3
^ permalink raw reply related
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Christopher Faylor @ 2006-02-26 20:40 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0602261217080.22647@g5.osdl.org>
On Sun, Feb 26, 2006 at 12:18:19PM -0800, Linus Torvalds wrote:
>On Sun, 26 Feb 2006, Christopher Faylor wrote:
>>If the speed of cygwin's fork is an issue then I'd previously suggested
>>using spawn*. The spawn family of functions were designed to emulate
>>Windows functions of the same name. They start a new process without
>>the requirement of forking.
>
>I thought that cygwin didn't implement the posix_spawn*() family?
Right. It just implements the windows version of spawn. I looked more
closely at the posix_spawn functions after you last suggested it and,
while it would be possible to implement this in cygwin, these functions
are a lot more heavyweight than the windows-like implementation of spawn
that are already in cygwin. So, they would come with their own
performance penalty.
The cygwin/windows version of spawn is basically like an extended version
of exec*():
pid = spawnlp (P_NOWAIT, "/bin/ls", "ls", "-l", NULL);
will start "/bin/ls" and return a pid which can be used in waitpid.
There is still some overhead to this function but it basically is just a
wrapper around the Windows CreateProcess, which means that it doesn't
go through the annoying overhead of Cygwin's fork.
The posix_spawn stuff is in my todo list but the Windows spawn stuff
could be used now.
cgf
^ permalink raw reply
* Teach the "git" command to handle some commands internally
From: Linus Torvalds @ 2006-02-26 20:34 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List, Andreas Ericsson, Alex Riesen,
Michal Ostrowski
This is another patch in the "prepare to do more in C" series, where the
git wrapper command is taught about the notion of handling some
functionality internally.
Right now, the only internal commands are "version" and "help", but the
point being that we can now easily extend it to handle some of the trivial
scripts internally. Things like "git log" and "git diff" wouldn't need
separate external scripts any more.
This also implies that to support the old "git-log" and "git-diff" syntax,
the "git" wrapper now automatically looks at the name it was executed as,
and if it is "git-xxxx", it will assume that it is to internally do what
"git xxxx" would do.
In other words, you can (once you implement an internal command) soft- or
hard-link that command to the "git" wrapper command, and it will do the
right thing, whether you use the "git xxxx" or the "git-xxxx" format.
There's one other change: the search order for external programs is
modified slightly, so that the first entry remains GIT_EXEC_DIR, but the
second entry is the same directory as the git wrapper itself was executed
out of - if we can figure it out from argv[0], of course.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
I personally think this is also a cleanup, but I'm cc'ing other people who
have worked on the wrapper for comments. Maybe people hate it.
Linus
---
diff --git a/git.c b/git.c
index 4616df6..993cd0d 100644
--- a/git.c
+++ b/git.c
@@ -230,62 +230,141 @@ static void show_man_page(char *git_cmd)
execlp("man", "man", page, NULL);
}
+static int cmd_version(int argc, char **argv, char **envp)
+{
+ printf("git version %s\n", GIT_VERSION);
+ return 0;
+}
+
+static int cmd_help(int argc, char **argv, char **envp)
+{
+ char *help_cmd = argv[1];
+ if (!help_cmd)
+ cmd_usage(git_exec_path(), NULL);
+ show_man_page(help_cmd);
+ return 0;
+}
+
+#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
+
+static void handle_internal_command(int argc, char **argv, char **envp)
+{
+ const char *cmd = argv[0];
+ static struct cmd_struct {
+ const char *cmd;
+ int (*fn)(int, char **, char **);
+ } commands[] = {
+ { "version", cmd_version },
+ { "help", cmd_help },
+ };
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(commands); i++) {
+ struct cmd_struct *p = commands+i;
+ if (strcmp(p->cmd, cmd))
+ continue;
+ exit(p->fn(argc, argv, envp));
+ }
+}
+
int main(int argc, char **argv, char **envp)
{
+ char *cmd = argv[0];
+ char *slash = strrchr(cmd, '/');
char git_command[PATH_MAX + 1];
- char wd[PATH_MAX + 1];
- int i, show_help = 0;
- const char *exec_path;
+ const char *exec_path = NULL;
- getcwd(wd, PATH_MAX);
+ /*
+ * Take the basename of argv[0] as the command
+ * name, and the dirname as the default exec_path
+ * if it's an absolute path and we don't have
+ * anything better.
+ */
+ if (slash) {
+ *slash++ = 0;
+ if (*cmd == '/')
+ exec_path = cmd;
+ cmd = slash;
+ }
- for (i = 1; i < argc; i++) {
- char *arg = argv[i];
+ /*
+ * "git-xxxx" is the same as "git xxxx", but we obviously:
+ *
+ * - cannot take flags in between the "git" and the "xxxx".
+ * - cannot execute it externally (since it would just do
+ * the same thing over again)
+ *
+ * So we just directly call the internal command handler, and
+ * die if that one cannot handle it.
+ */
+ if (!strncmp(cmd, "git-", 4)) {
+ cmd += 4;
+ argv[0] = cmd;
+ handle_internal_command(argc, argv, envp);
+ die("cannot handle %s internally", cmd);
+ }
- if (!strcmp(arg, "help")) {
- show_help = 1;
- continue;
- }
+ /* Default command: "help" */
+ cmd = "help";
- if (strncmp(arg, "--", 2))
+ /* Look for flags.. */
+ while (argc > 1) {
+ cmd = *++argv;
+ argc--;
+
+ if (strncmp(cmd, "--", 2))
break;
- arg += 2;
+ cmd += 2;
+
+ /*
+ * For legacy reasons, the "version" and "help"
+ * commands can be written with "--" prepended
+ * to make them look like flags.
+ */
+ if (!strcmp(cmd, "help"))
+ break;
+ if (!strcmp(cmd, "version"))
+ break;
- if (!strncmp(arg, "exec-path", 9)) {
- arg += 9;
- if (*arg == '=') {
- exec_path = arg + 1;
- git_set_exec_path(exec_path);
- } else {
- puts(git_exec_path());
- exit(0);
+ /*
+ * Check remaining flags (which by now must be
+ * "--exec-path", but maybe we will accept
+ * other arguments some day)
+ */
+ if (!strncmp(cmd, "exec-path", 9)) {
+ cmd += 9;
+ if (*cmd == '=') {
+ git_set_exec_path(cmd + 1);
+ continue;
}
- }
- else if (!strcmp(arg, "version")) {
- printf("git version %s\n", GIT_VERSION);
+ puts(git_exec_path());
exit(0);
}
- else if (!strcmp(arg, "help"))
- show_help = 1;
- else if (!show_help)
- cmd_usage(NULL, NULL);
- }
-
- if (i >= argc || show_help) {
- if (i >= argc)
- cmd_usage(git_exec_path(), NULL);
-
- show_man_page(argv[i]);
+ cmd_usage(NULL, NULL);
}
+ argv[0] = cmd;
+ /*
+ * We search for git commands in the following order:
+ * - git_exec_path()
+ * - the path of the "git" command if we could find it
+ * in $0
+ * - the regular PATH.
+ */
+ if (exec_path)
+ prepend_to_path(exec_path, strlen(exec_path));
exec_path = git_exec_path();
prepend_to_path(exec_path, strlen(exec_path));
- execv_git_cmd(argv + i);
+ /* See if it's an internal command */
+ handle_internal_command(argc, argv, envp);
+
+ /* .. then try the external ones */
+ execv_git_cmd(argv);
if (errno == ENOENT)
- cmd_usage(exec_path, "'%s' is not a git-command", argv[i]);
+ cmd_usage(exec_path, "'%s' is not a git-command", cmd);
fprintf(stderr, "Failed to run command '%s': %s\n",
git_command, strerror(errno));
^ permalink raw reply related
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Christopher Faylor @ 2006-02-26 20:33 UTC (permalink / raw)
To: git
In-Reply-To: <43FDB8CC.5000503@op5.se>
On Thu, Feb 23, 2006 at 02:29:48PM +0100, Andreas Ericsson wrote:
>Alex Riesen wrote:
>>On 2/23/06, Andreas Ericsson <ae@op5.se> wrote:
>>
>>>Not to be unhelpful or anything, but activestate perl seems to be quite
>>>a lot of bother. Is it worth supporting it?
>>
>>
>>It's not activestate perl actually. It's only one platform it also
>>_has_ to support.
>>Is it worth supporting Windows?
>
>
>With or without cygwin? With cygwin, I'd say "yes, unless it makes
>things terribly difficult to maintain and so long as we don't take
>performance hits on unices". Without cygwin, I'd say "What? It runs on
>windows?".
>
>If we claim to support windows but do a poor job of it, no-one else will
>start working on a windows-port. If we don't claim to support windows
>but say that "it's known to work with cygwin, although be aware of these
>performance penalties...", eventually someone will come along with their
>shiny Visual Express and hack up support for it, even if some tools will
>be missing and others unnecessarily complicated.
Well, with Cygwin, you've at least got the ear of one of the Cygwin
maintainers, which should be worth something.
Even if I disappear, you can always send concerns to the Cygwin mailing
list. Do the ActiveState folks respond to complaints about things as
basic as pipes not working in perl?
Cygwin's goal is to make Windows look as much like Linux as we can
manage, so, unless we're total incompetents (which has been hinted in
this mailing list from time to time), it has *got* to be better,
source-code-wise to target Windows-running-Cygwin than
just-plain-Windows. However, as has been noted, that means that there
will be a speed tradeoff.
I think that, for most projects, the convenience of not having to
clutter the code with substantial accommodations for the windows/POSIX
mismatch usually offsets the annoyance of the speed penalty. Maybe
that's not the case for git, however.
Anyway, we're willing, within the limits of available time, to help out
where git uncovers issues with Cygwin. I just fixed some stuff in
dirent.h in the last Cygwin release, as a direct result of people noting
a problem here. Basically, I don't want git to be a morasse of #ifdef
__CYGWIN_'s and I'll do whatever I can to help.
We're always trying to tweak things to improve speed in Cygwin and am
open to intelligent suggestions about how we can make things better.
The dance between total linux compatibility and speed is one that we
struggle with all of the time and, sadly, over time, we've probably
sacrificed speed in the name of functionality. That's probably because
it's easy to fix a problem like "close-on-exec doesn't work for sockets"
and feel good that you've fixed a bug even if you've just added a few
microseconds to fork/exec.
cgf
^ permalink raw reply
* Re: the war on trailing whitespace
From: Dave Jones @ 2006-02-26 20:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, junkio, git
In-Reply-To: <20060226202617.GH7851@redhat.com>
On Sun, Feb 26, 2006 at 03:26:17PM -0500, Dave Jones wrote:
> in my .vimrc, which highlights this (and other trailing whitespace) as
> a big red blob. I do this in part for the same reason Andrew does,
> so that when someone sends me a diff with a zillion spaces at the EOL,
> it screams at me, I spot them, and chop them out.
(seconds later, I find my .vimrc on master.k.o hasn't had this turned
on so I find a billion instances of this mess in agp/cpufreq -- Bah).
Dave
^ permalink raw reply
* Re: [PATCH] Use setenv(), fix warnings
From: Junio C Hamano @ 2006-02-26 20:29 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060226203756.05dcfb26.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> putenv(3):
> "If the argument `string` is of the form `name`, and does not
> contain an `=' character, then the variable `name` is removed from
> the environment."
>
> So the variable is emptied, not removed. But usually empty environment
> variables are treated as if they didn't exist...
Yes we were aware of that when we did it.
^ 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