* Re: [PATCH 2/3] Quoting paths in tests
From: Jonathan del Strother @ 2007-10-15 14:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <47136F71.1050107@viscovery.net>
On 15 Oct 2007, at 14:47, Johannes Sixt wrote:
> Jonathan del Strother schrieb:
>> - svn import -m 'import for git-svn' . $svnrepo >/dev/null &&
>> + svn import -m 'import for git-svn' . '$svnrepo' >/dev/null &&
>> cd .. &&
>> rm -rf import &&
>> - git-svn init $svnrepo"
>> + git-svn init '$svnrepo'"
>
> I don't see the point in changing an incorrect quoting to a
> different incorrect quoting that you fix up in a follow-up patch.
> It's *two* large patches to review instead of just one. I'm stopping
> the review here.
If we want to support apostrophed paths in tests, I'll flatten 2 & 3
into a single patch. I thought I'd make the apostrophe part optional
since there seemed to be some resistance to having to bother about
quoting & escaping in tests..
^ permalink raw reply
* Re: RCS keyword expansion
From: Peter Karlsson @ 2007-10-15 14:03 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0710121231410.25221@racer.site>
Hi!
> Finding out which commit last changed that file is slow. That's why
> it breaks down.
That might be, but it only needs to be done when a file is updated.
> You are just to used to CVS/SVN to see that there is a much better
> way in git.
I can see that favouring the argument that having a $Id$ that gives me
the global state id when the file was last updated is a bad idea. Fair
enough. Give me a local state tham (which you did, hash id for the file
contents).
My problem now is the file date. That could possibly be fixed by having
it updated before I check in the file.
So, to summarize, if I've understood the responses here correctly, what
I really want is:
on commit:
- replace "$Date$" (or whatever) with the current time.
- store the contents.
on checkout:
- update the file.
- replace "$Id$" (ditto) with a magic identifier for the file state.
- update git's state so that it doesn't see the "$Id$" expansion
as a change in the file contents.
Now the question is: Where can I find documentation on how to do this
(i.e what should I search for--"hooks"?)?
And, if this goes into the ".git" directory, can I still have it
replicated when I clone a repository? I noticed that my ".git/ignore"
file wasn't replicated and that I had to replace it with a local
".gitignore" to get it under version control.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH 2/3] Quoting paths in tests
From: Johannes Sixt @ 2007-10-15 14:17 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: git
In-Reply-To: <8977E4C2-2C13-4C52-8FD9-CEEB5AA85B70@steelskies.com>
Jonathan del Strother schrieb:
> On 15 Oct 2007, at 14:47, Johannes Sixt wrote:
>> I don't see the point in changing an incorrect quoting to a different
>> incorrect quoting that you fix up in a follow-up patch. It's *two*
>> large patches to review instead of just one. I'm stopping the review
>> here.
>
> If we want to support apostrophed paths in tests,
I could ask, "if we want to support paths with blanks in tests", so...
> I'll flatten 2 & 3
> into a single patch. I thought I'd make the apostrophe part optional
> since there seemed to be some resistance to having to bother about
> quoting & escaping in tests..
You could also make a patch that reverses the quoting in t9100-* (and
probably others), i.e. instead of
"... '$foo'..." (which is incorrect)
or
"... \"$foo\"..."
make it
'... "$foo" ...'
It will be a large patch, too, but the result should be easier to read.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/3] Quoting paths in tests
From: David Kastrup @ 2007-10-15 14:03 UTC (permalink / raw)
To: git
In-Reply-To: <47136F71.1050107@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Jonathan del Strother schrieb:
>> - svn import -m 'import for git-svn' . $svnrepo >/dev/null &&
>> + svn import -m 'import for git-svn' . '$svnrepo' >/dev/null &&
>> cd .. &&
>> rm -rf import &&
>> - git-svn init $svnrepo"
>> + git-svn init '$svnrepo'"
>
> I don't see the point in changing an incorrect quoting to a different
> incorrect quoting that you fix up in a follow-up patch. It's *two*
> large patches to review instead of just one. I'm stopping the review
> here.
Since I consider it unlikely that Jonathan is making your life harder
on purpose, it might be somewhat more helpful to offer submission
advice:
Jonathan, try
git rebase -i HEAD~3
or so in order to consolidate the last 3 patches you did. Interactive
rebase is one useful manner of munging history until it looks
reasonably nice for submission. One major point of git's distributed
operation is that one can clean up the development history locally
before handing things out.
That makes the project repositories cleaner to understand.
--
David Kastrup
^ permalink raw reply
* Re: RCS keyword expansion
From: Johannes Schindelin @ 2007-10-15 14:28 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710151457131.1901@ds9.cixit.se>
Hi,
On Mon, 15 Oct 2007, Peter Karlsson wrote:
> I wrote:
>
> > Finding out which commit last changed that file is slow. That's why
> > it breaks down.
>
> That might be, but it only needs to be done when a file is updated.
Almost.
It also needs to be updated when switching branches. For every file.
Since the commit blamed for the current version could be different for
every file.
> > You are just to used to CVS/SVN to see that there is a much better way
> > in git.
>
> I can see that favouring the argument that having a $Id$ that gives me
> the global state id when the file was last updated is a bad idea. Fair
> enough. Give me a local state tham (which you did, hash id for the file
> contents).
>
> My problem now is the file date. That could possibly be fixed by having
> it updated before I check in the file.
>
>
> So, to summarize, if I've understood the responses here correctly, what
> I really want is:
>
> on commit:
> - replace "$Date$" (or whatever) with the current time.
I think that would be more "on edit".
> - store the contents.
>
> on checkout:
> - update the file.
> - replace "$Id$" (ditto) with a magic identifier for the file state.
> - update git's state so that it doesn't see the "$Id$" expansion
> as a change in the file contents.
>
> Now the question is: Where can I find documentation on how to do this
> (i.e what should I search for--"hooks"?)?
For the $Id$ thing: Documentation/gitattributes.txt. For the $Date$
thing: Documentation/hooks.txt, and Documentation/git-rev-list.txt.
You'll need to roll your own thing there, since Git oldtimers feel that
what you want to do is the wrong thing (see Randal's comment on generating
it as part of the build process).
What you want to do might be frowned upon by many on the list, but it is
certainly doable. See ExampleScripts on the wiki for inspiration.
> And, if this goes into the ".git" directory, can I still have it
> replicated when I clone a repository? I noticed that my ".git/ignore"
> file wasn't replicated and that I had to replace it with a local
> ".gitignore" to get it under version control.
No, there is not way to have it replicated into the .git directory. The
common way would be to either have it installed as templates, so that
every user of yours gets them automatically, or to check them in under
different names, and make every user install them by hand.
The rationale: every cloner is free to choose what hooks she wants to run.
So checking in such hooks is always understood as suggestion what hooks
to install.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] [BUG FIXED 2] git-add (-a|-u) and -n support
From: Karl Hasselström @ 2007-10-15 14:31 UTC (permalink / raw)
To: Michael Witten; +Cc: git, Matthieu Moy
In-Reply-To: <D44B7811-5A0F-4A31-9DB3-6D2BF645E543@MIT.EDU>
On 2007-10-14 18:00:44 -0400, Michael Witten wrote:
> Here's compromise that is backwards compatible. For both git-add and
> git-commit:
>
> -a dir [dir2 ...] => all changes in the given dirs.
> -a => all changes from the root.
>
> Then we can just leave -u in place for now, and mark it as
> deprecated.
>
> In any case, the goal is to make the intuition solid between
> git-commit and git-add.
As I recall, Junio had some specific reason for calling the flag -u
instead of -a. Search in the list archive for the patch that
introduced the flag, or wait till he gets back and ask him.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git-svn and submodules
From: Karl Hasselström @ 2007-10-15 14:45 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Eric Wong, git list, Johannes Schindelin
In-Reply-To: <05CAB148-56ED-4FF1-8AAB-4BA2A0B70C2C@lrde.epita.fr>
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 "/".
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] [BUG FIXED 2] git-add (-a|-u) and -n support
From: Michael Witten @ 2007-10-15 14:47 UTC (permalink / raw)
To: git; +Cc: Karl Hasselström
In-Reply-To: <20071015143137.GA7351@diana.vm.bytemark.co.uk>
On 15 Oct 2007, at 10:31:37 AM, Karl Hasselström wrote:
> On 2007-10-14 18:00:44 -0400, Michael Witten wrote:
>
>> Here's compromise that is backwards compatible. For both git-add and
>> git-commit:
>>
>> -a dir [dir2 ...] => all changes in the given dirs.
>> -a => all changes from the root.
>>
>> Then we can just leave -u in place for now, and mark it as
>> deprecated.
>>
>> In any case, the goal is to make the intuition solid between
>> git-commit and git-add.
>
> As I recall, Junio had some specific reason for calling the flag -u
> instead of -a. Search in the list archive for the patch that
> introduced the flag, or wait till he gets back and ask him.
I have a feeling it was because -u currently just updates modified
files in the current directory, while -a updated all modified files.
Fortunately, the suggestion above does not break anything.
Michael Witten
P.S.
When is Junio coming back? I know I know... Look through the
archives. :-P
^ permalink raw reply
* Re: [PATCH] [BUG FIXED 2] git-add (-a|-u) and -n support
From: Johannes Schindelin @ 2007-10-15 14:54 UTC (permalink / raw)
To: Michael Witten; +Cc: git, Karl Hasselström
In-Reply-To: <85EE4C64-2174-45D3-A459-69746C9CD51C@mit.edu>
Hi,
On Mon, 15 Oct 2007, Michael Witten wrote:
> When is Junio coming back? I know I know... Look through the archives.
> :-P-
It's not in the archives. Just send your stuff, and let the list be a
filter for Junio. He'll be overwhelmed with the amount of emails already.
If I were to give him some advice, it would be to just delete all git list
mails in his inbox and ask for people to resend their latest and greatest,
_after_ he had a look at what Lars collected.
Ciao,
Dscho
^ permalink raw reply
* .gitignore and svn:ignore [WAS: git-svn and submodules]
From: Chris Shoemaker @ 2007-10-15 15:14 UTC (permalink / raw)
To: Karl Hasselström
Cc: Benoit SIGOURE, Eric Wong, git list, Johannes Schindelin
In-Reply-To: <20071015144513.GB7351@diana.vm.bytemark.co.uk>
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
-chris
^ permalink raw reply
* Re: git blame crashes with internal error
From: Linus Torvalds @ 2007-10-15 15:39 UTC (permalink / raw)
To: Bj?rn Steinbrink; +Cc: gitster, git
In-Reply-To: <20071014143628.GA22568@atjola.homenet>
On Sun, 14 Oct 2007, Bj?rn Steinbrink wrote:
>
> git blame just decided to crash on me, when I tried to use it while
> resolving a merge conflict.
Yes. What's going on is that "ce_mode = 0" is a magic marker for an
unmerged entry (set up by things like diff-lib.c:do_diff_cache() and
builtin-read-tree.c:read_tree_unmerged()) and the ce_match_stat_basic()
function gets upset about this.
I'm not entirely sure that the whole "ce_mode = 0" case is a good idea to
begin with, and maybe the right thing to do is to remove that horrid
freakish special case, but removing the internal error seems to be the
simplest fix for now.
Linus
---
read-cache.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 56202d1..3b11aa7 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -149,6 +149,8 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
else if (ce_compare_gitlink(ce))
changed |= DATA_CHANGED;
return changed;
+ case 0: /* Special case: unmerged file in index */
+ return MODE_CHANGED | DATA_CHANGED | TYPE_CHANGED;
default:
die("internal error: ce_mode is %o", ntohl(ce->ce_mode));
}
^ permalink raw reply related
* Re: git-svn and submodules
From: Linus Torvalds @ 2007-10-15 15:53 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Eric Wong, git list, Johannes Schindelin
In-Reply-To: <05CAB148-56ED-4FF1-8AAB-4BA2A0B70C2C@lrde.epita.fr>
On Mon, 15 Oct 2007, 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, but when you import a repo with tons of ignores
> (>1000), using git svn show-ignore to build .git/info/exclude is *not* a good
> idea, because things like git-status will end up doing >1000 fnmatch *per
> file* in the repo, which leads to git-status taking more than 4s on my
> Core2Duo 2Ghz 2G RAM)
Ouch.
That sounds largely unavoidable.. *But*.
Maybe we have a bug here. In particular, we generally shouldn't care about
the exclude/.gitignore file for ay paths that we know about, which means
that during an import, we really shouldn't ever even care about
.gitignore, since all the files are files we are expected to know about.
So yes, in general, "git status" is going to be slow in a tree that has
been built (since things like object files etc will have to be checked
against the exclude list! (*)), but if it's a clean import with no
generated files and only files we already know about, that should not be
the case.
So maybe we have a totally unnecessary performance issue, and do all the
fnmatch() on every path, whether we know about it or not?
Linus
(*) It might be that we could also re-order the exclude list so that
entries that trigger are moved to the head of the list, because it's
likely that if you have tons of exclude entries, some of them trigger a
lot more than others (ie "*.o"), and trying those first is likely a good
idea.
^ permalink raw reply
* [PATCH] Make the output of "git svn clone" less confusing.
From: David Kågedal @ 2007-10-15 15:21 UTC (permalink / raw)
To: git
The problem is that the first thing it prints is
Initialized empty Git repository in .git/
even if actually created a subdirectory and changed into it first. But to the
user, it looks like it is creating a .git/ dir in the directory he/she is
started git from.
---
git-svn.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
This change makes it more chatty, which might not be a good thing. But
I think the previous output was worse.
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";
$ENV{GIT_DIR} = '.git';
--
1.5.3.4.213.gb3127-dirty
--
David Kågedal
^ permalink raw reply related
* Performance issue with excludes (was: Re: git-svn and submodules)
From: Benoit SIGOURE @ 2007-10-15 16:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git list
In-Reply-To: <alpine.LFD.0.999.0710150848380.6887@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 3024 bytes --]
On Oct 15, 2007, at 5:53 PM, Linus Torvalds wrote:
> On Mon, 15 Oct 2007, 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, but when you import a repo with tons of
>> ignores
>> (>1000), using git svn show-ignore to build .git/info/exclude is
>> *not* a good
>> idea, because things like git-status will end up doing >1000
>> fnmatch *per
>> file* in the repo, which leads to git-status taking more than 4s
>> on my
>> Core2Duo 2Ghz 2G RAM)
>
> Ouch.
>
> That sounds largely unavoidable.. *But*.
>
> Maybe we have a bug here. In particular, we generally shouldn't
> care about
> the exclude/.gitignore file for ay paths that we know about, which
> means
> that during an import, we really shouldn't ever even care about
> .gitignore, since all the files are files we are expected to know
> about.
>
> So yes, in general, "git status" is going to be slow in a tree that
> has
> been built (since things like object files etc will have to be checked
> against the exclude list! (*)), but if it's a clean import with no
> generated files and only files we already know about, that should
> not be
> the case.
I re-used the test that was posted some time ago:
------------------------------------------------------------------------
---
#
# first create a tree of roughly 100k files
#
mkdir bummer
cd bummer
for ((i=0;i<100;i++)); do
mkdir $i && pushd $i;
for ((j=0;j<1000;j++)); do
echo "$j" >$j; done; popd;
done
#
# init and add this to git
#
time git init
git config user.email "no@thx"
git config user.name "nothx"
time git add .
time git commit -m 'buurrrrn' -a
for ((j=0;j<1000;j++)); do
echo "/pattern$j" >.git/info/exclude
done
#
# git-status, tunes in at around ~8s for me
#
time git-status
time git-status
time git-status
------------------------------------------------------------------------
---
[...]
git commit -m 'buurrrrn' -a 5.62s user 16.84s system 87% cpu 25.634
total
# On branch master
nothing to commit (working directory clean)
git-status 2.48s user 5.97s system 96% cpu 8.718 total
# On branch master
nothing to commit (working directory clean)
git-status 2.48s user 5.94s system 97% cpu 8.646 total
# On branch master
nothing to commit (working directory clean)
git-status 2.48s user 5.95s system 96% cpu 8.720 total
My machine is a Core2Duo 2Ghz 2G RAM.
>
> So maybe we have a totally unnecessary performance issue, and do
> all the
> fnmatch() on every path, whether we know about it or not?
>
> Linus
>
> (*) It might be that we could also re-order the exclude list so that
> entries that trigger are moved to the head of the list, because it's
> likely that if you have tons of exclude entries, some of them
> trigger a
> lot more than others (ie "*.o"), and trying those first is likely a
> good
> idea.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: git-svn and submodules
From: Andreas Ericsson @ 2007-10-15 16:27 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: David Kastrup, git
In-Reply-To: <AA453A15-BBF1-4EA6-B1AC-1C4E00E89FB2@lrde.epita.fr>
Benoit SIGOURE wrote:
> On Oct 15, 2007, at 12:14 PM, David Kastrup wrote:
>
>> Benoit SIGOURE <tsuna@lrde.epita.fr> writes:
>>
>>> This week I'm probably going to start to dive in git-svn by
>>> implementing simpler things first:
>>> - 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, but when you
>>> import a repo with tons of ignores (>1000), using git svn show-ignore
>>> to build .git/info/exclude is *not* a good idea, because things like
>>> git-status will end up doing >1000 fnmatch *per file* in the repo,
>>> which leads to git-status taking more than 4s on my Core2Duo 2Ghz 2G
>>> RAM)
>>
>> Well, then this should be fixed in git general, by sorting the ignores
>> (wildcards in the first place where they can match), and then just
>> moving those patterns that can actually match according to sort order
>> to the list of fnmatch candidates (and moving those files that can't
>> match anymore die to the sort order out again).
>>
>> I don't think that the final "solution" for avoiding a lousy global
>> O(n^2) algorithm is to replace it with lousy local O(n^2) algorithms
>> and just hope for smaller values of n.
>
> That's entirely true, it's more of a workaround than a real solution.
> Anyways, there could be other situations in which someone would like to
> generate the .gitignore instead of using .git/info/exclude, so this
> feature could be useful anyways.
>
> I can try to address this issue later, if I have enough free time in my
> hands to do so.
>
Ah, finally found the thread. I sent a core.ignorefile patch to the list
(Let users decide the name of the ignore file) a while ago, but didn't
find this mail to respond to. My apologies.
It's one way of solving it, which I'm currently using, although not so
fitting for when you're importing svn repos permanently.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Performance issue with excludes (was: Re: git-svn and submodules)
From: Linus Torvalds @ 2007-10-15 16:34 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: git list
In-Reply-To: <C7EA8AD7-BACA-4116-9C6B-90BA23F0005C@lrde.epita.fr>
On Mon, 15 Oct 2007, Benoit SIGOURE wrote:
>
> I re-used the test that was posted some time ago:
I think your test is scrogged. You should add the ".gitignore" file
*before* you do the "git add .". That's when it's going to hurt (since
that's when you have new files you don't yet know about).
But then it should hurt only for the "git add ." phase, not for anything
else (unless we have the performance bug of doing the ignore matching even
on files we know about). And more importantly, it should hurt only once
(since afterwards, we'll know about the files and know not to ignore
them).
Linus
^ permalink raw reply
* Re: Performance issue with excludes (was: Re: git-svn and submodules)
From: Benoit SIGOURE @ 2007-10-15 16:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git list
In-Reply-To: <alpine.LFD.0.999.0710150928450.6887@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
On Oct 15, 2007, at 6:34 PM, Linus Torvalds wrote:
> On Mon, 15 Oct 2007, Benoit SIGOURE wrote:
>>
>> I re-used the test that was posted some time ago:
>
> I think your test is scrogged. You should add the ".gitignore" file
> *before* you do the "git add .". That's when it's going to hurt (since
> that's when you have new files you don't yet know about).
>
> But then it should hurt only for the "git add ." phase, not for
> anything
> else (unless we have the performance bug of doing the ignore
> matching even
> on files we know about). And more importantly, it should hurt only
> once
> (since afterwards, we'll know about the files and know not to ignore
> them).
There is no .gitignore, only .git/info/exclude.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Performance issue with excludes (was: Re: git-svn and submodules)
From: Linus Torvalds @ 2007-10-15 17:10 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: git list
In-Reply-To: <45410184-8D7D-47ED-AB10-1A4E52D0ADB0@lrde.epita.fr>
On Mon, 15 Oct 2007, Benoit SIGOURE wrote:
>
> There is no .gitignore, only .git/info/exclude.
They do exactly the same thing (apart from the nesting nature of
.gitignore wrt subdirectories), so that doesn't change anything.
Linus
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 17:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Dave Korn, 'Andreas Ericsson', 'git list',
'Make Windows'
In-Reply-To: <Pine.LNX.4.64.0710150059460.25221@racer.site>
Johannes Schindelin, Mon, Oct 15, 2007 02:01:00 +0200:
> On Sun, 14 Oct 2007, Dave Korn wrote:
> > On 14 October 2007 23:15, Alex Riesen wrote:
> > > - 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)
> >
> > Whuh?
> >
> > http://msdn2.microsoft.com/en-us/library/y5zz48s1(VS.80).aspx
>
> It does have an exec() call, yes, since that is required by the C
> standard. But internally, it converts that into one single command line.
>
> In corner cases, you find problems with that.
>
Like: "damn, it is just IMPOSSIBLE to implement without them corner
cases."
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 17:38 UTC (permalink / raw)
To: Michael Gebetsroither; +Cc: git, make-w32
In-Reply-To: <feud8j$kdg$1@ger.gmane.org>
Michael Gebetsroither, Mon, Oct 15, 2007 02:46:11 +0200:
> > - 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
>
> Thats true for linux too.
> /a/b/c and /a/b/c can be 2 totally different files depending on the vfs
> namespace you are one.
No it is not. A process will always see the same filesystem object
under the same path at the any given time (IOW, you can't have many
namespaces active at the same time).
^ permalink raw reply
* Re: Performance issue with excludes (was: Re: git-svn and submodules)
From: Benoit SIGOURE @ 2007-10-15 17:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git list
In-Reply-To: <alpine.LFD.0.999.0710151009460.6887@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 785 bytes --]
On Oct 15, 2007, at 7:10 PM, Linus Torvalds wrote:
> On Mon, 15 Oct 2007, Benoit SIGOURE wrote:
>>
>> There is no .gitignore, only .git/info/exclude.
>
> They do exactly the same thing (apart from the nesting nature of
> .gitignore wrt subdirectories), so that doesn't change anything.
I fail to see how the mechanism work then. You said that I needed to
add the .gitignore before adding all the other bummer stuff, fair
enough. AFAIK .git/info/exclude doesn't need to be added, it's just
there. But you can try to change the test, add the .git/info/exclude
*first* and then make a commit and then add all the bummer stuff and
then commit, and finally, do a git-status, for me it still takes 9s.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 17:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: ae, git, make-w32
In-Reply-To: <Pine.LNX.4.64.0710150936070.25221@racer.site>
Johannes Schindelin, Mon, Oct 15, 2007 10:44:12 +0200:
> On Mon, 15 Oct 2007, Eli Zaretskii wrote:
> > Can you show a test case where this penalty is clearly visible? I'm
> > curious to see the numbers. TIA
...
> Now, that is my _personal_ decision. If _you_ have no problem with
> Windows, just stick with it. (I always thought this goes without saying,
> but Windows users tend to be very religious about this issue, thinking
> just because I hate Windows that I want to make them switch. Hahaha, no.)
They tend to be so exactly because they know how pathetic they are.
They just want to have something where they don't suck and do
everything to find it. And fail. Then they resort to graphics and
user-friendly interface.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 17:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eli Zaretskii, ae, tsuna, git, make-w32
In-Reply-To: <Pine.LNX.4.64.0710150039120.25221@racer.site>
Johannes Schindelin, Mon, Oct 15, 2007 01:45:47 +0200:
> On Mon, 15 Oct 2007, Eli Zaretskii wrote:
> > Alex Riesen said:
> > > - 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)
> >
> > So what? on Unix "a/b/c" can be not the same. Both cases are simply not
> > complete file names, that's all. No one said there must be a single
> > root for all volumes, it's the Posix jingoism creeping in again.
>
> I think Alex means this: you can have C:\a\b\c and D:\a\b\c. So depending
> on which drive you are, you mean one or the other. Just comparing the
> paths is not enough.
Not really. I meant that "/a/b/c" and "/a/b/c". Note the leading
slash. On windoze it is _NOT_ absolute path. It is relative to the
root of the current drive.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 17:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Eli Zaretskii, ae, tsuna, make-w32
In-Reply-To: <Pine.LNX.4.64.0710150217120.25221@racer.site>
Johannes Schindelin, Mon, Oct 15, 2007 03:22:53 +0200:
> On Sun, 14 Oct 2007, Brian Dessent wrote:
> > Johannes Schindelin wrote:
> > > The problem is that on Windows, you cannot keep a file open and delete
> > > it at the same time. This is an issue in Windows' equivalent of VFS.
> > >
> > > A neat trick to work with temporary files without permission issues is
> > > to open the file and delete it right after that. This does not work
> > > on Windows.
> >
> > You can achieve the same thing on Windows with CreateFile() by setting
> > the dwShareMode parameter to zero and setting the
> > FILE_FLAG_DELETE_ON_CLOSE attribute on dwFlagsAndAttributes. This
> > results in a file that cannot be opened or read by any other process and
> > that will be automatically deleted when all open handles are closed.
>
> Aha. So to support Windows, we have to wrap all sites that use that
> trick, and special case that #ifdef __MINGW32__.
He misunderstood. It is not what you meant. You cannot remove the open
file. What he talks about is removing the file after it is _closed_.
Junk.
^ permalink raw reply
* [PATCH] git-rebase--interactive.sh: Quote arguments to test
From: Michael W. Olson @ 2007-10-15 17:48 UTC (permalink / raw)
To: git
If /bin/sh is /bin/dash, then the script will display an error if
$parent_sha1 is undefined. This patch works fixes the issue by
quoting both arguments to `test'. Arguments composed solely of
variable expansions should always be quoted, unless we know for
certain that the contents are defined.
Signed-off-by: Michael W. Olson <mwolson@gnu.org>
---
Resending, this time directly to the mailing list instead of via Gmane.
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 050140d..8a03062 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -110,7 +110,7 @@ pick_one () {
parent_sha1=$(git rev-parse --verify $sha1^) ||
die "Could not get the parent of $sha1"
current_sha1=$(git rev-parse --verify HEAD)
- if test $no_ff$current_sha1 = $parent_sha1; then
+ if test "$no_ff$current_sha1" = "$parent_sha1"; then
output git reset --hard $sha1
test "a$1" = a-n && output git reset --soft $current_sha1
sha1=$(git rev-parse --short $sha1)
--
1.5.3.4
^ permalink raw reply related
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