* Re: [PATCH] diff-cache path restriction fix.
From: Junio C Hamano @ 2005-05-25 1:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505241757280.2307@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> No, it's more broken than that.
I'll take a look at this later and submit an update, but an OT
point I feel I should address.
LT> Btw, that "1 < argc" order is very unintuitive to most humans.
Yeah? Not to people around where I come from, I do not know
why. It is not done for the assignment confusion avoidance
"1==a".
The comparison lists things in the ascending order from left to
right. The fact that 1 comes before argc on that line of code
visually makes it obvious that I am talking about argc being
larger than one and that is the reason. I'd write (argc < 4)
not (4 > argc) for the same reason.
^ permalink raw reply
* Re: [PATCH] diff-cache path restriction fix.
From: Linus Torvalds @ 2005-05-25 1:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0ksrv1v.fsf@assigned-by-dhcp.cox.net>
On Tue, 24 May 2005, Junio C Hamano wrote:
>
> It advertises the path restriction in documentation and usage
> string, but the argument parsing code was not updated and was
> causing it to refuse to run. One liner fix is here.
No, it's more broken than that. Look at how it uses "argv[1]" for the tree
SHA1, then does "argv++" and then uses "argv[1]" (which is a totally
different argument entirely) for error reporting when the tree SHA1 is bad
> - while (argc > 2) {
> + while (1 < argc && argv[1][0] == '-') {
Btw, that "1 < argc" order is very unintuitive to most humans. Like it or
not, people get used to things one way, and have a hard time seeing what
it means when it's the other way around.
And when people have a hard time seeing what it means, you get more bugs.
This is why it is _not_ better to do
if (1 == a)
like some people teach, even if that protects against the "single equal
sign" bug. There are better ways to protect against that one bug (like
having compiler warnings enabled) that don't make the code less obvious.
Linus
^ permalink raw reply
* Re: [PATCH] Allow dot files in ls-files as well.
From: Linus Torvalds @ 2005-05-25 0:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x7wt9qm.fsf_-_@assigned-by-dhcp.cox.net>
On Tue, 24 May 2005, Junio C Hamano wrote:
>
> No matter what you end up doing, you would need something like
> this as well (I am not screening .git here but that should be
> easy for you to add).
Ehh, this will do bad things for "git-show-files --others", no?
You really _do_ want to strip out the ".git" file.
Linus
^ permalink raw reply
* Re: git-update-cache: allow dot-files
From: Linus Torvalds @ 2005-05-25 0:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8y24taai.fsf@assigned-by-dhcp.cox.net>
On Tue, 24 May 2005, Junio C Hamano wrote:
> >>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
>
> LT> I considered it, but it's so much easier to allow things
> LT> later than deny them, that I preferred being anal about it.
>
> That is not the point. GIT_DIR set to "GIT" would happily suck
> index file in. You are not being anal enough.
Heh. There's a difference between being anal, and allowing people to shoot
themselves in the foot.
I'll happily allow people who _try_ to do stupid things to do them ;)
It's the
find . -type f | cut -d/ -f2- | xargs git-update-cache --add --
kinds of "unintentionally stupid" scripts I want to avoid (and the reason
I do that is because that's basically _exactly_ the script I used when
testing something ;)
Linus
^ permalink raw reply
* [PATCH] diff-cache path restriction fix.
From: Junio C Hamano @ 2005-05-25 0:47 UTC (permalink / raw)
To: torvalds; +Cc: git
It advertises the path restriction in documentation and usage
string, but the argument parsing code was not updated and was
causing it to refuse to run. One liner fix is here.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
# - linus: git-update-cache: allow dot-files
# + (working tree)
diff --git a/diff-cache.c b/diff-cache.c
--- a/diff-cache.c
+++ b/diff-cache.c
@@ -164,7 +164,7 @@ int main(int argc, const char **argv)
int ret;
read_cache();
- while (argc > 2) {
+ while (1 < argc && argv[1][0] == '-') {
const char *arg = argv[1];
argv++;
argc--;
^ permalink raw reply
* [PATCH] Allow dot files in ls-files as well.
From: Junio C Hamano @ 2005-05-25 0:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v8y24taai.fsf@assigned-by-dhcp.cox.net>
>>>>> "JCH" == Junio C Hamano <junkio@cox.net> writes:
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> I considered it, but it's so much easier to allow things
LT> later than deny them, that I preferred being anal about it.
JCH> That is not the point. GIT_DIR set to "GIT" would happily suck
JCH> index file in. You are not being anal enough.
... which makes me feel that, since you cannot be anal enough
anyway, it would be more consistent not to be more restrictive
than necessary (the user has every right to screw himself
anyway).
No matter what you end up doing, you would need something like
this as well (I am not screening .git here but that should be
easy for you to add).
------------
Allow dot files in ls-files as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cd /opt/packrat/playpen/public/in-place/git/git.junio/
PATH=.:$PATH jit-diff 1: ls-files.c
# - linus: git-update-cache: allow dot-files
# + (working tree)
diff --git a/ls-files.c b/ls-files.c
--- a/ls-files.c
+++ b/ls-files.c
@@ -136,7 +136,9 @@ static void read_directory(const char *p
while ((de = readdir(dir)) != NULL) {
int len;
- if (de->d_name[0] == '.')
+ if (de->d_name[0] == '.' &&
+ (de->d_name[1] == 0 ||
+ (de->d_name[1] == '.' && de->d_name[2] == 0)))
continue;
if (excluded(de->d_name) != show_ignored)
continue;
^ permalink raw reply
* Re: git-update-cache: allow dot-files
From: Junio C Hamano @ 2005-05-25 0:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505241723060.2307@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> I considered it, but it's so much easier to allow things
LT> later than deny them, that I preferred being anal about it.
That is not the point. GIT_DIR set to "GIT" would happily suck
index file in. You are not being anal enough.
^ permalink raw reply
* Re: gitweb wishlist
From: Junio C Hamano @ 2005-05-25 0:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Edgar Toernig, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505241711590.2307@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> The sad part is that I don't even have an excuse like "I use
LT> perl all the time". No, shell is my _forte_ when it comes to
LT> scripting.
You are allowed to suck at scripting when you are so good at C
;-).
By the by, are you still having problem with "whatchanged -s"?
I see a few of my patches still not in your tree, and I do not
care too much about the last one (rename/copy similarity
estimator update) after you made it clear that -M and -C are of
lower priority, I would like to know if the "diff-tree -s" fix I
sent you was missing the point, and if so how. Also the test
scripts to verify your fix to the "checkout-cache --prefix
pointing at some directory via symlink" along with your fix is
something I feel ready to go.
Hoping it would be easy to look for a message by message-ID,
here they are. The first one is the proposed "diff-tree -s"
fix.
Subject: Re: [PATCH 3/3] Diff overhaul, adding the other half...
Message-ID: <7vr7fxuh8b.fsf@assigned-by-dhcp.cox.net>
Subject: Squelch compiler warning
Message-ID: <7vis18v4ea.fsf_-_@assigned-by-dhcp.cox.net>
Subject: [PATCH] Allow symlinks in the leading path in checkout-cache --prefix=
Message-ID: <7vacmlvwfk.fsf_-_@assigned-by-dhcp.cox.net>
Subject: [PATCH] Update rename/copy similarity estimator.
Message-ID: <7vbr70v3tf.fsf@assigned-by-dhcp.cox.net>
^ permalink raw reply
* Re: git-update-cache: allow dot-files
From: Linus Torvalds @ 2005-05-25 0:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhdgstb7x.fsf@assigned-by-dhcp.cox.net>
On Tue, 24 May 2005, Junio C Hamano wrote:
>
> Linus, I think this is wrong. GIT_DIR could be something other
> than ".git".
I considered it, but it's so much easier to allow things later than deny
them, that I preferred being anal about it.
Linus
^ permalink raw reply
* Re: gitweb wishlist
From: Linus Torvalds @ 2005-05-25 0:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Edgar Toernig, Git Mailing List
In-Reply-To: <7vk6lotbil.fsf@assigned-by-dhcp.cox.net>
On Tue, 24 May 2005, Junio C Hamano wrote:
>
> Test scripts in your t/ uses <<\EOF all over the place.
Yeah, yeah, rub it in. I suck at shell.
The sad part is that I don't even have an excuse like "I use perl all the
time". No, shell is my _forte_ when it comes to scripting.
Linus "crawl under a rock" Torvalds
^ permalink raw reply
* Re: git-update-cache: allow dot-files
From: Junio C Hamano @ 2005-05-25 0:12 UTC (permalink / raw)
To: torvalds; +Cc: git
Linus, I think this is wrong. GIT_DIR could be something other
than ".git". I'd rather allow everything other than . and .. in
the core layer, and have Porcelain layer ignore-paths logic to
deal with "^.git/" (only when GIT_DIR is .git; otherwise
ignore-path configuration file for that particular tree needs to
say what to ignore).
git-update-cache: allow dot-files
diff --git a/update-cache.c b/update-cache.c
--- a/update-cache.c
+++ b/update-cache.c
@@ -238,13 +238,42 @@ static int refresh_cache(void)
/*
* We fundamentally don't like some paths: we don't want
- * dot or dot-dot anywhere, and in fact, we don't even want
- * any other dot-files (.git or anything else). They
- * are hidden, for chist sake.
+ * dot or dot-dot anywhere, and for obvious reasons don't
+ * want to recurse into ".git" either.
*
* Also, we don't want double slashes or slashes at the
* end that can make pathnames ambiguous.
*/
+static int verify_dotfile(const char *rest)
+{
+ /*
^ permalink raw reply
* Re: gitweb wishlist
From: Junio C Hamano @ 2005-05-25 0:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Edgar Toernig, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505241602330.2307@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> On Wed, 25 May 2005, Edgar Toernig wrote:
>>
>> Nothing is expanded when you quote the EOF-word:
LT> Oh, wow.
Test scripts in your t/ uses <<\EOF all over the place.
^ permalink raw reply
* Re: gitweb wishlist
From: Linus Torvalds @ 2005-05-24 23:05 UTC (permalink / raw)
To: Edgar Toernig; +Cc: Git Mailing List
In-Reply-To: <20050525003917.40700d19.froese@gmx.de>
On Wed, 25 May 2005, Edgar Toernig wrote:
>
> Nothing is expanded when you quote the EOF-word:
Oh, wow.
It's even documented in the bash man-page, now that I understand what to
look for.
Anyway, that doc also tells me that I'm quoting the right characters, so
now it's not worth fixing any more.
Linus
^ permalink raw reply
* Re: gitweb wishlist
From: Edgar Toernig @ 2005-05-24 22:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505241212190.2307@ppc970.osdl.org>
Linus Torvalds wrote:
> > - Some Shell escapes (I didn't looked into them yet)
>
> Ok, I'll check it out. I didn't figure out what characters are
> shell-expanded by "<<EOF" handling, and only did '$' because that showed
> up in the syslinux archives.
Nothing is expanded when you quote the EOF-word:
cat <<"EOF"
`foo` $PATH
bar \
baz
EOF
gives:
`foo` $PATH
bar \
baz
Ciao, ET.
^ permalink raw reply
* Re: gitweb wishlist
From: David Mansfield @ 2005-05-24 22:25 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Glanzmann, H. Peter Anvin, Kay Sievers, Petr Baudis,
Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505241502160.2307@ppc970.osdl.org>
>Linus Saith,
>
> Anyway, what worries me more is that cvsps might have re-ordered other
> changesets than just the first two. It probably doesn't _matter_, but
> still...
>
I think I have an idea to prevent this incorrect ordering of patchsets.
We'll see in the morning how it works out.
David
^ permalink raw reply
* Re: gitweb wishlist
From: Linus Torvalds @ 2005-05-24 22:11 UTC (permalink / raw)
To: Thomas Glanzmann
Cc: David Mansfield, H. Peter Anvin, Kay Sievers, Petr Baudis,
Git Mailing List
In-Reply-To: <20050524215238.GG25606@cip.informatik.uni-erlangen.de>
On Tue, 24 May 2005, Thomas Glanzmann wrote:
>
> I did one sampling and though it would be representative which it isn't.
> What I don't understand why noone ever fixed this? cvs has its own rcs
> implementation anyway to speed things up, hasn't it?
CVS has so many warts, that people can't even be bothered to fix things
like this. It's file-based, and that's that.
Using "-z 1" with cvsps doesn't seem to work well for me, but "-z 5" seems
ok, and together with the new git that allows .cvsignore, it doesn't
generate any warnings, nor any unreachable blobs. It does generate 300 new
changesets, and how many of those are required, I dunno. Clearly 102 of
them were, to disambiguate those changelog things.
Maybe "-z 10" would have generated a better thing with fewer changes yet
still unique changesets without dup files.
That's a bit irritating, that there's this magic tweakable that generates
different trees. Oh, well.
Anyway, what worries me more is that cvsps might have re-ordered other
changesets than just the first two. It probably doesn't _matter_, but
still...
Linus
^ permalink raw reply
* Re: gitweb wishlist
From: Thomas Glanzmann @ 2005-05-24 21:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Mansfield, H. Peter Anvin, Kay Sievers, Petr Baudis,
Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505241345280.2307@ppc970.osdl.org>
Hello,
> Ahh, the mutt people really use something else for development, and this
> is just an export into CVS (like the Linux bkcvs tree)? Or do they just
> have fast machines and no networking? Or are there good versions of CVS
> around that re-use the same time across one whole commit?
I did one sampling and though it would be representative which it isn't.
What I don't understand why noone ever fixed this? cvs has its own rcs
implementation anyway to speed things up, hasn't it?
Thomas
^ permalink raw reply
* Re: gitweb wishlist
From: Linus Torvalds @ 2005-05-24 21:43 UTC (permalink / raw)
To: Kay Sievers
Cc: Thomas Glanzmann, David Mansfield, H. Peter Anvin, Petr Baudis,
Git Mailing List
In-Reply-To: <20050524213102.GB19180@vrfy.org>
On Tue, 24 May 2005, Kay Sievers wrote:
>
> What about allowing to put some file inside of .git/ under revision-control
> too? Wouldn't it be nice to have something like an "ignore" file or other
> repository meta-data managed by git itself.
Put them into ".git-ignore" if so..
Linus
^ permalink raw reply
* Re: gitweb wishlist
From: Thomas Glanzmann @ 2005-05-24 21:41 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, David Mansfield, Kay Sievers, Petr Baudis,
Git Mailing List
In-Reply-To: <42939942.9080807@zytor.com>
[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]
Hello,
> I was considering using CVS for that at one point, but the way CVS
> distributes its metadata and recurses makes that insane. For git, it
> would be trivial.
I have a shared environment, and handle it this way:
- I edit all files on my machine on university or at least put
it there per scp when I am done modifing them local.
- I have file called .env in my home which contains a list with
all files I want to 'distribute'.
- There is a script called envup, which updates all files which
are not up2date. It uses perl because perl is everywhere I
have an account on. After that I call a perl preprocessor to
generate ssh config files (there are floating so much ssh
versions out there) and one to adopt my .screenrc (for the
machine local screen) to my needs.
my .bash_profile does a lot of testing to add paths and sets aliases
based on the environment of the machine and not based on host/domain
names. Files with lot of deltas like my .fvwm2rc or .bash_profile are
all version controled using rcs on a per file basis of course. This
works very well for me on Linux, Solaris, OpenBSD, FreeBSD, NetBSD, OSF,
AIX, MacOSX, name it ...
Oh and to bootstrap my environment on a 'new' machine:
tar cfz env.tgz `cat .env`, move it over, unpack and re login.
A while ago I also distributed binaries (bash, rar, fvwm) via envup for
my environment, but I adopted now to something that works everywhere,
and if it doesn't I do that manual. So envup only transfers stuff which
is new. (I have some accounts on low bandwidth sites). One known side
effect. If envup doesn't find md5sum binary it just transfers all files.
Oh and a friend and colleague has a similliar script only that he pushes
his environment out.
Thomas
[-- Attachment #2: envup --]
[-- Type: text/plain, Size: 1293 bytes --]
#!/usr/bin/perl -w
use strict;
use integer;
my $command = '';
my %local = ();
my %remote = ();
my @sums = ();
my @transfer = ();
if ( -f '/home/cip/adm/sithglan/bin/envup.server'
|| -f "$ENV{HOME}/bin/envup.server" ) {
die "NEVER EVER RUN THIS IN THE CIP POOL: YOU SUCK :-)";
exit; # way to secure\x17redundant
}
# [remote] ------------------------------------------
@sums = `ssh 131.188.30.105 bin/envup.server`;
foreach $_ (@sums) {
chomp;
if (/(^[a-f0-9]{32})[ ]{2}([^\s]+)$/) {
$remote{$2} = $1;
# print "$1 -> $2\n";
} else {
print "remote: can't match: <$_>\n";
}
}
# [local] ------------------------------------------
$command = 'md5sum ' . join(' ', keys(%remote));
@sums = qx($command 2> /dev/null);
foreach $_ (@sums) {
chomp;
if (/(^[a-f0-9]{32})[ ]{2}([^\s]+)$/) {
$local{$2} = $1;
#print "$1 -> $2\n";
} else {
print "local can't match: <$_>\n";
}
}
foreach my $file (keys(%remote)) {
if (exists($local{$file})) {
if ($remote{$file} ne $local{$file}) {
push(@transfer, $file);
}
} else {
push(@transfer, $file);
}
}
if (@transfer) {
$command = "ssh 131.188.30.105 -- tar cf - " . join(' ', @transfer) . " | tar xf -";
system($command);
}
[-- Attachment #3: envup.server --]
[-- Type: text/plain, Size: 53 bytes --]
#!/bin/bash
md5sum $(find `cat $HOME/.env` -type f)
^ permalink raw reply
* Re: gitweb wishlist
From: Kay Sievers @ 2005-05-24 21:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Glanzmann, David Mansfield, H. Peter Anvin, Petr Baudis,
Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505241410380.2307@ppc970.osdl.org>
On Tue, May 24, 2005 at 02:13:26PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 24 May 2005, Thomas Glanzmann wrote:
> >
> > btw:
> >
> > For the mutt tree there are a few 'empty commits' eg were the
> > parent tree is the same as the current. This is because git ignores
> > .cvsignore and they commited some .cvsignore files without any other
> > deltas. I don't know if you want to handle this. Just a note.
>
> I don't like source repositories with dot-files, and I thought it was a
> good idea to disallow them, but on the other hand I'd like it even less if
> some CVS-weenie goes and says "I can't convert my project to git without
> potentially losing information".
>
> So in the name of furthering humanity through allowing people to migrate
> away from CVS, I'm considering making the git dot-file check be more
> specific to "." ".." and ".git". After all, project-specific rules might
> have their own porcelain-related ignore-files that cause dot-files to
> never appear..
What about allowing to put some file inside of .git/ under revision-control
too? Wouldn't it be nice to have something like an "ignore" file or other
repository meta-data managed by git itself.
Kay
^ permalink raw reply
* Re: gitweb wishlist
From: Thomas Glanzmann @ 2005-05-24 21:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Mansfield, H. Peter Anvin, Kay Sievers, Petr Baudis,
Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505241410380.2307@ppc970.osdl.org>
Hello,
> So in the name of furthering humanity through allowing people to migrate
> away from CVS, I'm considering making the git dot-file check be more
> specific to "." ".." and ".git". After all, project-specific rules might
> have their own porcelain-related ignore-files that cause dot-files to
> never appear..
Allowing dot files is a good thing, I think. But there is another issue
I want to hear your comment on. My git frontend uses regular expressions
from .git/ignore to filter orphan files I know about when calling 'git
status' or 'git orhpan'. However, I thought to add this file to
versioning. Because I think it belongs there. However I have to think
that through.
So if there would be a .git/etc or something were I can put files which
stay under revision control and maybe add some options to the frontend
or git core to don't diff against them per default. But this sounds just
ugly. Maybe I should just retrieve the ignore list when doing
push/pulls. But I dislike this idea to. However I have to think a bit
longer over this.
Comments, anyone?
Thomas
^ permalink raw reply
* Re: gitweb wishlist
From: H. Peter Anvin @ 2005-05-24 21:14 UTC (permalink / raw)
To: Linus Torvalds
Cc: Thomas Glanzmann, David Mansfield, Kay Sievers, Petr Baudis,
Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505241410380.2307@ppc970.osdl.org>
Linus Torvalds wrote:
>
> I don't like source repositories with dot-files, and I thought it was a
> good idea to disallow them, but on the other hand I'd like it even less if
> some CVS-weenie goes and says "I can't convert my project to git without
> potentially losing information".
>
> So in the name of furthering humanity through allowing people to migrate
> away from CVS, I'm considering making the git dot-file check be more
> specific to "." ".." and ".git". After all, project-specific rules might
> have their own porcelain-related ignore-files that cause dot-files to
> never appear..
>
There is another good reason to allow dot files: since git handles
sparse trees well, and only needs metadata at the top level, it's pretty
ideal for keeping track of people's account profiles across accounts,
and that's mostly dot files.
I was considering using CVS for that at one point, but the way CVS
distributes its metadata and recurses makes that insane. For git, it
would be trivial.
-hpa
^ permalink raw reply
* Re: gitweb wishlist
From: Linus Torvalds @ 2005-05-24 21:13 UTC (permalink / raw)
To: Thomas Glanzmann
Cc: David Mansfield, H. Peter Anvin, Kay Sievers, Petr Baudis,
Git Mailing List
In-Reply-To: <20050524202846.GC25606@cip.informatik.uni-erlangen.de>
On Tue, 24 May 2005, Thomas Glanzmann wrote:
>
> btw:
>
> For the mutt tree there are a few 'empty commits' eg were the
> parent tree is the same as the current. This is because git ignores
> .cvsignore and they commited some .cvsignore files without any other
> deltas. I don't know if you want to handle this. Just a note.
I don't like source repositories with dot-files, and I thought it was a
good idea to disallow them, but on the other hand I'd like it even less if
some CVS-weenie goes and says "I can't convert my project to git without
potentially losing information".
So in the name of furthering humanity through allowing people to migrate
away from CVS, I'm considering making the git dot-file check be more
specific to "." ".." and ".git". After all, project-specific rules might
have their own porcelain-related ignore-files that cause dot-files to
never appear..
Hmm.
Linus
^ permalink raw reply
* Re: gitweb wishlist
From: Linus Torvalds @ 2005-05-24 20:47 UTC (permalink / raw)
To: Thomas Glanzmann
Cc: David Mansfield, H. Peter Anvin, Kay Sievers, Petr Baudis,
Git Mailing List
In-Reply-To: <20050524202846.GC25606@cip.informatik.uni-erlangen.de>
On Tue, 24 May 2005, Thomas Glanzmann wrote:
>
> Just call cvsps with -z "20" for the mutt repository also -z 1 should
> work because the timestamps of one 'commit' are all set to the same
> value.
Ahh, the mutt people really use something else for development, and this
is just an export into CVS (like the Linux bkcvs tree)? Or do they just
have fast machines and no networking? Or are there good versions of CVS
around that re-use the same time across one whole commit?
Linus
^ permalink raw reply
* Re: gitweb wishlist
From: Linus Torvalds @ 2005-05-24 20:44 UTC (permalink / raw)
To: David Mansfield
Cc: Thomas Glanzmann, H. Peter Anvin, Kay Sievers, Petr Baudis,
Git Mailing List
In-Reply-To: <42938C5B.4000906@cobite.com>
On Tue, 24 May 2005, David Mansfield wrote:
>
> Sounds possible. Unfortunately, the 'uniqueness' of a commit actually
> doesn't exist. It's all smoke-and-mirrors. In order to disallow this
> (which I think need to do) I'd need to use some commit member
> information, and add some heuristic: if this file is already in the
> commit, then this MUST be a different commit. Unfortunately, it's
> possible that the 'member' already in the commit is the wrong one and
> this is the right one, which just sounds horribly ugly to me.
>
> I'll think on it.
I think it's a fundamentally hard problem to fix, but it may be that the
fix is to give hints about command line options and in particular the time
fuzz thing to try.
So maybe just _detection_ logic in cvsps, along with a warning like
"time fuzz is 600 seconds, and the time difference between the two
commits of this file was 431 seconds. You may want to try a lower
-z argument"
or something.
It might also be possible to try to sort all the names by date of commit
first, and see if they "bunch up" into groups of low fuzz with much bigger
fuzz in between groups..
Linus
^ 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