* Re: Is there any plan to support partial checkout or submoudule improvement?
From: Lars Hjemli @ 2007-10-16 10:50 UTC (permalink / raw)
To: franky; +Cc: git
In-Reply-To: <20071016095622.CE14F7E6F@mail.kooxoo.com>
On 10/16/07, franky <yinping@kooxoo.com> wrote:
> lars said:
> > $ git archive --remote=<repo> <revspec> <path> | tar -x
>
> I can't know deployment version easily
The <revspec> can be a tag. So you can easily create a wrapper script
to allow such things as
$ ./deploy.sh v1.2.3
$ ./deploy.sh HEAD
$ ./deploy.sh master
$ ./deploy.sh <sha1>
(note: for this to work with the git:// protocol, git-daemon needs
--enable=upload-archive)
--
larsh
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-16 10:51 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Shawn O. Pearce, Steven Grimm, Reece Dunn, Linus Torvalds,
J. Bruce Fields, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.9999.0710152245530.19446@xanadu.home>
Hi,
On Mon, 15 Oct 2007, Nicolas Pitre wrote:
> On Mon, 15 Oct 2007, Shawn O. Pearce wrote:
>
> > Nicolas Pitre <nico@cam.org> wrote:
> > > BTW I have patches here reworking the progress code for a more compact
> > > display which should mitigate this issue quite a bit.
> >
> > git-gui is scraping the output of the current progress meter using
> > a regex and then building a graphical progress bar from that output.
>
> Erk!
>
> > Any change in how git produces the progress bar should still keep
> > it in a form that git-gui can regex match and scrape, preferably
> > without needing to know what version of git it is pulling that
> > output from. For example just teach git-gui to try two different
> > regexps, new format and if that doesn't match then try the old
> > (aka current) format.
>
> I think my new format might be easier for you as the "title" and the
> actual percentage and count is now on the same line.
That might have been an advantage if Shawn did not do the code already.
As it is, he'll have to maintain two different regexes, _and_ detect when
to use which.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make the output of "git svn clone" less confusing.
From: David Kågedal @ 2007-10-16 11:00 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20071016093228.GA30503@soma>
Eric Wong <normalperson@yhbt.net> writes:
>> diff --git a/git-svn.perl b/git-svn.perl
>> index 777e436..d4450ca 100755
>> --- a/git-svn.perl
>> +++ b/git-svn.perl
>> @@ -286,6 +286,7 @@ sub do_git_init_db {
>>
>> sub init_subdir {
>> my $repo_path = shift or return;
>> + print "Creating directory $repo_path\n";
>> mkpath([$repo_path]) unless -d $repo_path;
>> chdir $repo_path or die "Couldn't chdir to $repo_path: $!\n";
>
> Since mkpath() isn't guaranteed to get called, maybe putting a
>
> print "Entering directory $repo_path\n"
>
> right before the chdir is better.
You're probably right.
> The other option would be to alter git-init to print the absolute path
> of the repository being initialized...
Absolute paths don't sound like a great idea to me. Ideally, I'd like
to see the path I gave it, or something relative to the working
directory. That is, *my* working directory, and not some internal one
because one of the tools did a chdir.
Can't we make init_subdir in git-svn not chdir, instead? Like this,
highly untested?
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -288,8 +288,7 @@ sub init_subdir {
my $repo_path = shift or return;
print "Creating directory $repo_path\n";
mkpath([$repo_path]) unless -d $repo_path;
- chdir $repo_path or die "Couldn't chdir to $repo_path: $!\n";
- $ENV{GIT_DIR} = '.git';
+ $ENV{GIT_DIR} = '$repo_path/.git';
}
sub cmd_clone {
--
David Kågedal
^ permalink raw reply
* RE: Is there any plan to support partial checkout or submoudule improvement?
From: Johannes Schindelin @ 2007-10-16 11:02 UTC (permalink / raw)
To: franky; +Cc: 'Lars Hjemli', git
In-Reply-To: <20071016082720.E5EDA7E6F@mail.kooxoo.com>
Hi,
[please do not top post. Only keep the parts of the original message that
you are responding to, and put your answers just below. It is a matter of
simple economy: it takes you just a couple of minutes, but spares those
"millions" of readers the minutes to understand what you're talking about.
In addition, it is a matter of politeness.]
On Tue, 16 Oct 2007, franky wrote:
> I want a single "git-pull" to deploy a new version and a
> single "git-reset" to back to versions before [on partial checkouts]
You are talking as if your partial checkout was a project in its own
right. Then make it so. Do not use a partial checkout, but make that a
submodule.
One reason _not_ to support partial checkouts is exactly to avoid people
falling into that mousetrap of thinking that they can sensibly merge
_parts_ of the HEAD.
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Peter Karlsson @ 2007-10-16 11:13 UTC (permalink / raw)
To: git list
In-Reply-To: <20071014221446.GC2776@steel.home>
> - it is the only OS in the world with multi-root (/a/b/c and /a/b/c
> can be not the same, depending on what current "drive" is) and
> multi-cwd, which hasn't had formed itself into a problem yet, but
> surely will
It's not the only OS with drive letters (although I don't see Git
coming to my Symbian OS phone any time soon), but there is only one
root. The problem is that it isn't addressable in the file system, and
that the concept of what is the root is different depending on what you
ask (either it's above the drive letters, or "My Computer").
You can create a search path rooted in "My Computer" if you want (using
shell APIs), but you probably can't get a readable text representation
of it.
> - it has only one argument (limited in size) passed to started
> programs, which means that there is no possible way to safely pass
> file and text arguments on command line (more than one, that is)
Well, there are many other ways of passing arguments than on the
command line, but they are probably difficult to access from console
applications (things like DDE or whatever the current implementation is
called).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: What's cooking in git/spearce.git (topics)
From: Johannes Schindelin @ 2007-10-16 11:16 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071016060456.GC13801@spearce.org>
Hi,
first let me thank you for being the interim maintainer. I know it is
much work, and I frankly do not have the time, or nerve, to do it. Out of
curiousity: did you use the scripts in "todo" to send these emails?
On Tue, 16 Oct 2007, Shawn O. Pearce wrote:
> * lt/diff-rename (Tue Oct 2 19:28:19 2007 -0700) 1 commit
> + optimize diffcore-delta by sorting hash entries.
AFAIR this was ready to go to master, with a 5-10% speedup or so, just
needing a bit of testing. Which it should have gotten by now.
> * kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits
> + Export rerere() and launch_editor().
> + Introduce entry point add_interactive and add_files_to_cache
> + Enable wt-status to run against non-standard index file.
> + Enable wt-status output to a given FILE pointer.
This is the beginning of the builtin-commit. The option parser has to go
in before that (it was split out from the builtin-commit series), and the
(minimal) adjustments to builtin-commit.c for the now-changed option
parser have to be done.
So I think this topic should stay in master until builtin-commit is there,
too.
> * js/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
> + rebase: allow starting from a dirty tree.
> + stash: implement "stash create"
This needs more work in rebase-i, and Junio indicated that he's not
completely happy with it.
It would serve to be able to rebase in a dirty tree, by first stashing
away the changes, and then applying them on top of the rebased branch.
I think that this would avoid many "Huh?" effects, but it should try to
"git stash apply --index" first, falling back to "git stash apply".
Something like that would be very nice for git-pull, too, I guess.
However, I have not thought through all implications.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 6/7] Bisect: factorise "bisect_{bad,good,dunno}" into "bisect_state".
From: Johannes Schindelin @ 2007-10-16 11:20 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, git
In-Reply-To: <200710160828.05137.chriscool@tuxfamily.org>
Hi,
[finally, a technical argument on "dunno". Maybe we really need
git-bikeshed@vger.kernel.org? ;-)]
On Tue, 16 Oct 2007, Christian Couder wrote:
> Le lundi 15 octobre 2007, Johannes Schindelin a ?crit :
> >
> > On Mon, 15 Oct 2007, Christian Couder wrote:
> > >
> > > But the new "bisect_state" takes one more argument, because the first
> > > one must be "good" "bad" or "dunno".
> > >
> > > So when there is only one argument HEAD is used, and when there are
> > > 2 arguments, $2 is used as the good|bad|dunno rev.
> >
> > Ah, that explains it! But do you not need to do
> > "2,bad|2,good|2,dunno" in that case? Or even better: "2,*"?
>
> Perhaps it would be an improvement at least in speed for "2,good" or
> "2,dunno".
I see: the later case catches them. Colour me satisfied with your patch.
> I wanted to keep exactly the same processing as there was before, in case
> something like "git bisect good v1.5.3.3..v1.5.3.4" was supported. But it
> seems it doesn't work. I don't know if it's a bug or a feature.
I think v1.5.3.3..v1.5.3.4 expands to ^v1.5.3.3 v1.5.3.4, which might
explain what you are experiencing.
OTOH "git bisect good v1.5.3.3..v1.5.3.4" does not make sense. bisect
assumes that all ancestors of a good commit are good, too.
Ciao,
Dscho
^ permalink raw reply
* RE: Is there any plan to support partial checkout or submoudule improvement?
From: franky @ 2007-10-16 11:45 UTC (permalink / raw)
To: 'Lars Hjemli'; +Cc: git
In-Reply-To: <8c5c35580710160350h53a7b5c4k374067372d4aac1d@mail.gmail.com>
> The <revspec> can be a tag. So you can easily create a wrapper script
> to allow such things as
>
> $ ./deploy.sh v1.2.3
> $ ./deploy.sh HEAD
> $ ./deploy.sh master
> $ ./deploy.sh <sha1>
But it is an online services, I must take care, so I prefer the incremental
update to avoid overwriting deployment directory fully each time. Another
consideration, Full update also introduces the busy network traffic.
franky
^ permalink raw reply
* RE: Is there any plan to support partial checkout or submoudule improvement?
From: franky @ 2007-10-16 11:53 UTC (permalink / raw)
To: 'Johannes Schindelin'; +Cc: 'Lars Hjemli', git
In-Reply-To: <Pine.LNX.4.64.0710161158350.25221@racer.site>
> [please do not top post. Only keep the parts of the original message that
> you are responding to, and put your answers just below. It is a matter of
> simple economy: it takes you just a couple of minutes, but spares those
> "millions" of readers the minutes to understand what you're talking about.
> In addition, it is a matter of politeness.]
Thanks for the hint, and I have corrected this.
> On Tue, 16 Oct 2007, franky wrote:
>
> > I want a single "git-pull" to deploy a new version and a
> > single "git-reset" to back to versions before [on partial checkouts]
>
> You are talking as if your partial checkout was a project in its own
> right. Then make it so. Do not use a partial checkout, but make that a
> submodule.
As I said in the first email, the submodule way suffers from the multiple
commit problem: src and bin as two submodules of project, three commits (for
the 3 dirs separately) are needed when src directory changes and compiled
binaries being put in bin directory. It's annoying to have to give 3 commit
logs.
franky
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-16 12:18 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: prohaska, git, raa.lkml, ae, tsuna, Johannes.Schindelin
In-Reply-To: <fcaeb9bf0710160309y51101fbaicae463a10612010c@mail.gmail.com>
> Date: Tue, 16 Oct 2007 17:09:08 +0700
> From: "Nguyen Thai Ngoc Duy" <pclouds@gmail.com>
> Cc: prohaska@zib.de, git@vger.kernel.org, raa.lkml@gmail.com, ae@op5.se,
> tsuna@lrde.epita.fr, Johannes.Schindelin@gmx.de
>
> > Where can one find this port of busybox's ash?
> >
>
> http://repo.or.cz/w/git/pclouds.git?a=shortlog;h=gitbox
>
> In directory box/shell.
Thanks!
^ permalink raw reply
* Re: should git command and git-command be equivalent?
From: David Symonds @ 2007-10-16 12:28 UTC (permalink / raw)
To: Matthieu Moy; +Cc: franky, git
In-Reply-To: <vpqk5pnmoah.fsf@bauges.imag.fr>
On 16/10/2007, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> "franky" <yinping@kooxoo.com> writes:
>
> >> Also, you can use aliases (for example, I type "git st" to do "git
> >> status") with "git whatever", but not with "git-whatever" (unless you
> >> define the alias in your shell).
> > I try "git st", but it complains "git: 'st' is not a git-command".
>
> Sure, I'm talking about aliases, so what I meant is that I had
>
> [alias]
> st = status
>
> in ~/.gitconfig.
If you use the contrib/completion/git-completion.bash script, you can
type "git st<TAB>", and it'll complete it for you. Well, it did, until
git-stash came along and ruined it...
At any rate, the bash completion also completes things like branch
names, which can be immensely helpful.
Dave.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-16 12:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Andreas Ericsson, barkalow, raa.lkml, tsuna, git
In-Reply-To: <E1Ihfrl-0007w1-3I@fencepost.gnu.org>
Hi,
[by explicit request culling make-w32 from the Cc list]
On Tue, 16 Oct 2007, Eli Zaretskii wrote:
> > Date: Tue, 16 Oct 2007 07:14:56 +0200
> > From: Andreas Ericsson <ae@op5.se>
> > CC: Daniel Barkalow <barkalow@iabervon.org>, raa.lkml@gmail.com,
> > Johannes.Schindelin@gmx.de, tsuna@lrde.epita.fr, git@vger.kernel.org,
> > make-w32@gnu.org
> >
> > > Sorry I'm asking potentially stupid questions out of ignorance: why
> > > would you want readdir to return `README' when you have `readme'?
> > >
> >
> > Because it might have been checked in as README, and since git is case
> > sensitive that is what it'll think should be there when it reads the
> > directories. If it's not, users get to see
> >
> > removed: README
> > untracked: readme
>
> This is a non-issue, then: Windows filesystems are case-preserving, so
> if `README' became `readme', someone deliberately renamed it, in which
> case it's okay for git to react as above.
No, it is not. On FAT filesystems, for example, I experienced Windows
happily naming a file "head" which was created under then name "HEAD".
This is the single reason why I cannot have non-bare repositories on a USB
stick.
> > could be an intentional rename, but we don't know for sure.
>
> It _must_ have been an intentional rename.
No. It can also be the output of a program which deletes the file first,
and then (since the filesystem is so "conveniently" case insensitive)
creates it again, with a lowercase filename.
And don't you tell me that there are no such programs. I have to use
them, and they are closed source.
Sigh.
> > To be honest though, there are so many places which do the
> > readdir+stat that I don't think it'd be worth factoring it out
>
> Something for Windows users to decide, I guess. It's not hard to
> refactor this, it just needs a motivated volunteer.
You?
> > I *think* (correct me if I'm wrong) that git is still faster
> > than a whole bunch of other scm's on windows, but to one who's used to
> > its performance on Linux that waiting several seconds to scan 10k files
> > just feels wrong.
>
> Unless that 10K is a typo and you really meant 100K, I don't think 10K
> files should take several seconds to scan on Windows. I just tried
> "find -print" on a directory with 32K files in 4K subdirectories, and
> it took 8 sec elapsed with a hot cache. So 10K files should take at
> most 2 seconds, even without optimizing file traversal code. Doing
> the same with native Windows system calls ("dir /s") brings that down
> to 4 seconds for 32K files.
On Linux, I would have hit Control-C already. Such an operation typically
takes less than 0.1 seconds.
> On the other hand, what packages have 100K files?
Mozilla, KDE, OpenOffice.org, X.org, ....
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-16 12:33 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Git Mailing List, Eli Zaretskii, Daniel Barkalow, Alex Riesen,
tsuna, Andreas Ericsson
In-Reply-To: <2EA3BEC9-5B13-44D3-B190-CA77499F642C@zib.de>
Hi,
[culled make-w32 list by explicit request]
On Tue, 16 Oct 2007, Steffen Prohaska wrote:
> On Oct 16, 2007, at 7:14 AM, Andreas Ericsson wrote:
>
> > Eli Zaretskii wrote:
> > > > Date: Mon, 15 Oct 2007 20:45:02 -0400 (EDT)
> > > > From: Daniel Barkalow <barkalow@iabervon.org>
> > > > cc: Alex Riesen <raa.lkml@gmail.com>, Johannes.Schindelin@gmx.de,
> > > > ae@op5.se, tsuna@lrde.epita.fr, git@vger.kernel.org,
> > > > make-w32@gnu.org
> > > >
> > > > I believe the hassle is that readdir doesn't necessarily report a
> > > > README in a directory which is supposed to have a README, when it
> > > > has a readme instead.
> > > Sorry I'm asking potentially stupid questions out of ignorance: why
> > > would you want readdir to return `README' when you have `readme'?
> >
> > Because it might have been checked in as README, and since git is case
> > sensitive that is what it'll think should be there when it reads the
> > directories. If it's not, users get to see
> >
> > removed: README
> > untracked: readme
> >
> > and there's really no easy way out of this one, since users on a case-
> > sensitive filesystem might be involved in this project too, so it
> > could be an intentional rename, but we don't know for sure. Just
> > clobbering the in-git file is wrong, but overwriting a file on disk is
> > wrong too. git tries hard to not ever lose any data for the user.
>
> Maybe we need a configuration similar to core.autocrlf (which controls
> newline conversion) to control filename comparison and normalization?
>
> Most obviously for the case (in-)sensitivity on Windows, but I also
> remember the unicode normalization happening on Mac's HFS filesystem
> that caused trouble in the past.
Robin Rosenberg has some preliminary code for that. The idea is to wrap
all filesystem operations in cache.h, and do a filename normalisation
first.
Ciao,
Dscho
^ permalink raw reply
* Problem with git-svnimport
From: VAUCHER Laurent @ 2007-10-16 12:30 UTC (permalink / raw)
To: git
Hi.
Trying to convert a svn repository to git, I encountered the following
error:
Use of uninitialized value in hash element at /usr/bin/git-svnimport
line 534.
Line 534 reads:
my $gitrev = $branches{$srcbranch}{$therev};
I have installed packages git-core and git-svn on Ubuntu. These
package have versions: "1:1.5.2.5-2-feisty1"
The tool seems to choke on tags or branches with special characters
(underscore, for instance).
Laurent.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Peter Karlsson @ 2007-10-16 12:38 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Eli Zaretskii, Andreas Ericsson, barkalow, raa.lkml, tsuna, git
In-Reply-To: <Pine.LNX.4.64.0710161324490.25221@racer.site>
> No, it is not. On FAT filesystems, for example, I experienced Windows
> happily naming a file "head" which was created under then name "HEAD".
If you create a file name with only capital letters, I believe Explorer
and the file browser will display the name with an initial capital, and
the rest lowercase, or in all lowercase. IIRC, this is because such a
file is saved with only an MS-DOS name and no LFN entry, and those have
special rules to avoid them being displayed in all-uppercase.
I believe it is possible to create a LFN entry for such a file, but I
can't remember right now how to do it.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-16 12:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Daniel Barkalow, raa.lkml, ae, tsuna, git
In-Reply-To: <E1IhgT2-0000bg-O6@fencepost.gnu.org>
Hi,
[culled make-w32, as per explicit request]
On Tue, 16 Oct 2007, Eli Zaretskii wrote:
> > Date: Tue, 16 Oct 2007 01:56:46 -0400 (EDT)
> > From: Daniel Barkalow <barkalow@iabervon.org>
> > cc: raa.lkml@gmail.com, Johannes.Schindelin@gmx.de, ae@op5.se,
> > tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org
> >
> > Ah, that's helpful. We don't actually care too much about the
> > particular info in stat; we just want to know quickly if the file has
> > changed, so we can hash only the ones that have been touched and get
> > the actual content changes.
>
> As I wrote in my other message, using native APIs improves performance
> by at least a factor of two.
Somehow this does not appeal to my "portability is good" side. You know,
if we had to do such trickeries for every platform we support, we'd soon
be as big as Subversion *cough*.
For me, this is the most annoying part about programming Win32. They went
out of their way to make it incompatible with everything else, and as a
consequence it is a PITA to maintain crossplatform programs.
> > The tricky thing is that, while the optimization process is running,
> > other programs may be reading the database, so (1) the files that are
> > no longer needed, because better-optimized versions are in place, may
> > be open in another task
>
> Is this because another user might be accessing the database, or are
> there other popular use cases that cause this? If the former, then this
> is not terribly important on Windows, since the situation when more than
> one user is logged and actively works is quite rare, basically limited
> to some scheduled task (the equivalent of a cron job) running for some
> user while another one is logged in interactively.
Quite to the contrary. Explorer often accesses files it should not lock.
On the machine I test msysGit on, this is the most common reason for a
test case to fail: it cannot delete the temporary directory, which
_should_ be unused. Indeed, a second after that, it _is_ unused.
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-16 12:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: ae, barkalow, raa.lkml, tsuna, git
In-Reply-To: <Pine.LNX.4.64.0710161324490.25221@racer.site>
> Date: Tue, 16 Oct 2007 13:29:41 +0100 (BST)
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> cc: Andreas Ericsson <ae@op5.se>, barkalow@iabervon.org, raa.lkml@gmail.com,
> tsuna@lrde.epita.fr, git@vger.kernel.org
>
> > > removed: README
> > > untracked: readme
> >
> > This is a non-issue, then: Windows filesystems are case-preserving, so
> > if `README' became `readme', someone deliberately renamed it, in which
> > case it's okay for git to react as above.
>
> No, it is not. On FAT filesystems, for example, I experienced Windows
> happily naming a file "head" which was created under then name "HEAD".
What program did that, and how did you see that the file was named
"head" instead of "HEAD"? (The latter question is because Explorer,
for example, does not show the file names exactly like they are
written in the directory, it capitalises them. But this is
application-level code; in the directory the file names are written
like you gave them in the argument to whatever "create file" API you
used.
> No. It can also be the output of a program which deletes the file first,
> and then (since the filesystem is so "conveniently" case insensitive)
> creates it again, with a lowercase filename.
>
> And don't you tell me that there are no such programs. I have to use
> them, and they are closed source.
Can you name them?
> > Something for Windows users to decide, I guess. It's not hard to
> > refactor this, it just needs a motivated volunteer.
>
> You?
Maybe some day.
> > Unless that 10K is a typo and you really meant 100K, I don't think 10K
> > files should take several seconds to scan on Windows. I just tried
> > "find -print" on a directory with 32K files in 4K subdirectories, and
> > it took 8 sec elapsed with a hot cache. So 10K files should take at
> > most 2 seconds, even without optimizing file traversal code. Doing
> > the same with native Windows system calls ("dir /s") brings that down
> > to 4 seconds for 32K files.
>
> On Linux, I would have hit Control-C already. Such an operation typically
> takes less than 0.1 seconds.
We were not comparing Linux with Windows, we were talking about
Windows user experience. On Windows 4 seconds is not too long.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-16 13:04 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Johannes.Schindelin, ae, barkalow, raa.lkml, tsuna, git
In-Reply-To: <Pine.LNX.4.64.0710161335500.8571@ds9.cixit.se>
> Date: Tue, 16 Oct 2007 13:38:59 +0100 (CET)
> From: Peter Karlsson <peter@softwolves.pp.se>
> cc: Eli Zaretskii <eliz@gnu.org>, Andreas Ericsson <ae@op5.se>,
> barkalow@iabervon.org, raa.lkml@gmail.com, tsuna@lrde.epita.fr,
> git@vger.kernel.org
>
> If you create a file name with only capital letters, I believe Explorer
> and the file browser will display the name with an initial capital, and
> the rest lowercase, or in all lowercase.
That's true, but the names are only displayed like that, what's on
disk is not changed in any way.
> IIRC, this is because such a
> file is saved with only an MS-DOS name and no LFN entry, and those have
> special rules to avoid them being displayed in all-uppercase.
I don't think this true anymore in modern versions of Windows, but I
might be mistaken. In any case, the reason for the Explorer behavior
is immaterial for us, what matters is that file names on disk preserve
the lettercase of the program that created them, at least AFAIK.
^ permalink raw reply
* Re: [PATCH 3/3] git-cvsexportcommit.perl: git-apply no longer needs --binary
From: Johannes Schindelin @ 2007-10-16 13:04 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <1192522094-4988-3-git-send-email-mfwitten@mit.edu>
Hi,
does --binary hurt?
Ciao,
Dscho
^ permalink raw reply
* Re: .gitignore and svn:ignore [WAS: git-svn and submodules]
From: Chris Shoemaker @ 2007-10-16 13:05 UTC (permalink / raw)
To: Eric Wong
Cc: Karl Hasselström, Benoit SIGOURE, git list,
Johannes Schindelin
In-Reply-To: <20071016075827.GB32348@soma>
On Tue, Oct 16, 2007 at 12:58:27AM -0700, Eric Wong wrote:
> Chris Shoemaker <c.shoemaker@cox.net> wrote:
> > On Mon, Oct 15, 2007 at 04:45:13PM +0200, Karl Hasselström wrote:
> > > On 2007-10-15 09:07:21 +0200, Benoit SIGOURE wrote:
> > >
> > > > - git svn create-ignore (to create one .gitignore per directory
> > > > from the svn:ignore properties. This has the disadvantage of
> > > > committing the .gitignore during the next dcommit,
> > >
> > > I built ignore support for git-svnignore a long time ago. It converts
> > > the per-directory svn:ignore to per-directory .gitignore at commit
> > > import time, which is very handy:
> > >
> > > -I <ignorefile_name>::
> > > Import the svn:ignore directory property to files with this
> > > name in each directory. (The Subversion and GIT ignore
> > > syntaxes are similar enough that using the Subversion patterns
> > > directly with "-I .gitignore" will almost always just work.)
> > >
> > > The only downside with that is that svn ignore patterns are
> > > non-recursive, while git ignore patterns are recursive. This could be
> > > solved by prefixing them with a "/".
> >
> > Has anyone put any thought into mapping the other direction?
> > i.e. .gitignore -> svn:ignore
>
> If we support .gitignore <-> svn:ignore in git-svn; bidirectional,
> transparent mapping is the only way I want to go.
>
>
> This means that *all* .gitignore files will be translated to svn:ignore
> files and vice versa; and the .gitignore files will be NOT be committed
> to SVN itself, but present in the git-svn created mirrors. Recursive
> .gitignore definitions will be mapped to svn:ignore recursively on the
> client side; and non-recursive ones will only map to one directory.
>
> Sound good?
>
> I may be sleepy at the moment, but the thought of implementing this is
> sounding complicated now...
>
OTOH, a general propset solution would probably be good enough that I
wouldn't even miss any transparent .gitignore -> svn:ignore mapping.
I would just accept that I'd have to explicitly specify the
svn:ignores.
> Since externals/submodules don't operate recursively in either
> system like .gitignore; supporting svn:externals <=> submodules
> will be much easier and done first[1] :)
>
> [1] - I've personally rarely bothered with putting svn:ignores in the
> repository and have been very much spoiled by .git/info/exclude;
> whereas externals support I have semi-immediate use for.
That's great. I'm eager to see/test the svn:externals support. Thanks.
-chris
^ permalink raw reply
* Re: Switching from CVS to GIT
From: David Kastrup @ 2007-10-16 12:47 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0710161335260.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> [culled make-w32, as per explicit request]
>
> On Tue, 16 Oct 2007, Eli Zaretskii wrote:
>
>> > Date: Tue, 16 Oct 2007 01:56:46 -0400 (EDT)
>> > From: Daniel Barkalow <barkalow@iabervon.org>
>> > cc: raa.lkml@gmail.com, Johannes.Schindelin@gmx.de, ae@op5.se,
>> > tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org
>> >
>> > Ah, that's helpful. We don't actually care too much about the
>> > particular info in stat; we just want to know quickly if the file has
>> > changed, so we can hash only the ones that have been touched and get
>> > the actual content changes.
>>
>> As I wrote in my other message, using native APIs improves
>> performance by at least a factor of two.
>
> Somehow this does not appeal to my "portability is good" side. You
> know, if we had to do such trickeries for every platform we support,
> we'd soon be as big as Subversion *cough*.
With a reasonable way of factoring out things, the per-platform
overhead should be tolerable.
> For me, this is the most annoying part about programming Win32.
> They went out of their way to make it incompatible with everything
> else, and as a consequence it is a PITA to maintain crossplatform
> programs.
Well, they certainly score high on the "almost, but not quite,
entirely unlike tea" metric. Enough compatibility to make it into
projects with cross-platform specifications, and enough
incompatibility to make it inconvenient to support anything but
Windows once they made it into the door.
--
David Kastrup
^ permalink raw reply
* Re: Switching from CVS to GIT
From: David Kastrup @ 2007-10-16 12:59 UTC (permalink / raw)
To: git
In-Reply-To: <E1IhlvV-0002qv-1K@fencepost.gnu.org>
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Tue, 16 Oct 2007 13:29:41 +0100 (BST)
>> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>>
>> On Linux, I would have hit Control-C already. Such an operation
>> typically takes less than 0.1 seconds.
>
> We were not comparing Linux with Windows, we were talking about
> Windows user experience. On Windows 4 seconds is not too long.
If it is accompanied by some animation of papers winging across the
screen or a progress bar or similar. Otherwise people might think
that Windows crashed and reboot.
Anyway, the problem is that 4 seconds for 32K files means 40 seconds
(at least) for 320K files. At some point of time, things become
really unpleasant.
--
David Kastrup
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Steffen Prohaska @ 2007-10-16 13:16 UTC (permalink / raw)
To: Git Mailing List, Robin Rosenberg, Johannes Schindelin
Cc: Eli Zaretskii, Daniel Barkalow, Alex Riesen, tsuna,
Andreas Ericsson
In-Reply-To: <Pine.LNX.4.64.0710161331440.25221@racer.site>
On Oct 16, 2007, at 2:33 PM, Johannes Schindelin wrote:
>> Maybe we need a configuration similar to core.autocrlf (which
>> controls
>> newline conversion) to control filename comparison and normalization?
>>
>> Most obviously for the case (in-)sensitivity on Windows, but I also
>> remember the unicode normalization happening on Mac's HFS filesystem
>> that caused trouble in the past.
>
> Robin Rosenberg has some preliminary code for that. The idea is to
> wrap
> all filesystem operations in cache.h, and do a filename normalisation
> first.
At that point we could add a safety check. Paths that differ only by
case, or whitespace, or ... (add general and project specific rules
here)
should be denied. This would guarantee that tree objects can always be
checked out. Even if the filesystem capabilities are limited.
Robin, what do you think?
Steffen
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-16 13:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ae, barkalow, raa.lkml, tsuna, git
In-Reply-To: <E1IhlvV-0002qv-1K@fencepost.gnu.org>
Hi,
On Tue, 16 Oct 2007, Eli Zaretskii wrote:
> > Date: Tue, 16 Oct 2007 13:29:41 +0100 (BST)
> > From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> > cc: Andreas Ericsson <ae@op5.se>, barkalow@iabervon.org, raa.lkml@gmail.com,
> > tsuna@lrde.epita.fr, git@vger.kernel.org
> >
> > > > removed: README
> > > > untracked: readme
> > >
> > > This is a non-issue, then: Windows filesystems are case-preserving, so
> > > if `README' became `readme', someone deliberately renamed it, in which
> > > case it's okay for git to react as above.
> >
> > No, it is not. On FAT filesystems, for example, I experienced Windows
> > happily naming a file "head" which was created under then name "HEAD".
>
> What program did that, and how did you see that the file was named
> "head" instead of "HEAD"?
Git and ... Git.
> > > Something for Windows users to decide, I guess. It's not hard to
> > > refactor this, it just needs a motivated volunteer.
> >
> > You?
>
> Maybe some day.
Cool.
> > > Unless that 10K is a typo and you really meant 100K, I don't think
> > > 10K files should take several seconds to scan on Windows. I just
> > > tried "find -print" on a directory with 32K files in 4K
> > > subdirectories, and it took 8 sec elapsed with a hot cache. So 10K
> > > files should take at most 2 seconds, even without optimizing file
> > > traversal code. Doing the same with native Windows system calls
> > > ("dir /s") brings that down to 4 seconds for 32K files.
> >
> > On Linux, I would have hit Control-C already. Such an operation
> > typically takes less than 0.1 seconds.
>
> We were not comparing Linux with Windows, we were talking about Windows
> user experience. On Windows 4 seconds is not too long.
Well, I was talking about user experience. In this case of a user who
happens to be on Windows, but knows Linux' speed.
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-16 13:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: barkalow, raa.lkml, ae, tsuna, git
In-Reply-To: <Pine.LNX.4.64.0710161335260.25221@racer.site>
> Date: Tue, 16 Oct 2007 13:39:12 +0100 (BST)
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> cc: Daniel Barkalow <barkalow@iabervon.org>, raa.lkml@gmail.com, ae@op5.se,
> tsuna@lrde.epita.fr, git@vger.kernel.org
>
> > As I wrote in my other message, using native APIs improves performance
> > by at least a factor of two.
>
> Somehow this does not appeal to my "portability is good" side. You know,
> if we had to do such trickeries for every platform we support, we'd soon
> be as big as Subversion *cough*.
You have to decide whether you care about performance enough to do
that or not. If you do, then introducing file I/O abstractions at
higher level than the normal ``use-library-functions'' method is not
such a hard problem, and doesn't make the binary larger because each
platform gets only its own backend. In practice, I have found that in
most cases a few well-designed and strategically placed macros is all
you need.
> For me, this is the most annoying part about programming Win32. They went
> out of their way to make it incompatible with everything else, and as a
> consequence it is a PITA to maintain crossplatform programs.
Portability is a two-way street. A program that wasn't designed to be
portable will by definition be hard to port. To me, what's annoying
is a program that was designed around a single-OS model of APIs.
Cross-platform programs are not that hard if you design them to be
like that from the ground up. I'm working for a firm that does that
for a living: we develop software that compiles and runs on Windows
and Linux from the same source.
> Explorer often accesses files it should not lock.
> On the machine I test msysGit on, this is the most common reason for a
> test case to fail: it cannot delete the temporary directory, which
> _should_ be unused. Indeed, a second after that, it _is_ unused.
One more reason not to launch Explorer, if you ask me ;-) But maybe
you have valid reasons to do that. All I can say is that I never saw
such problems, but then I don't usually run programs that rewrite
files in a frenzy.
^ 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