* [PATCH] Update the documentation for git-tag-script to reflect current behavior.
From: Ryan Anderson @ 2005-07-25 6:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
Documentation/git-tag-script.txt | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
8f1801c948cbf1187a192df1656709689ba46d61
diff --git a/Documentation/git-tag-script.txt b/Documentation/git-tag-script.txt
--- a/Documentation/git-tag-script.txt
+++ b/Documentation/git-tag-script.txt
@@ -4,18 +4,22 @@ v0.1, May 2005
NAME
----
-git-tag-script - An example script to create a tag object signed with GPG
+git-tag-script - Create a tag object signed with GPG
SYNOPSIS
--------
-'git-tag-script'
+'git-tag-script' [-s] [-f] <name>
DESCRIPTION
-----------
-This is an example script that uses "git-mktag" to create a tag object
-signed with GPG.
+Adds a "tag" reference in .git/refs/tags/
+
+Unless "-f" is given, the tag must not yet exist in ".git/refs/tags"
+
+If "-s" is passed, the user will be prompted for a tag message, and a GnuPG
+signed tag object will be created as well.
Author
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH] Add support for directories to git-rename-script.
From: Junio C Hamano @ 2005-07-25 6:21 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050725052646.GB6098@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> +open(F,"-|","git-ls-files")
> + or die "Failed to open pipe from git-ls-files: " . $!;
> +
> +@allfiles = <F>;
> +close(F);
We can afford to handle funny characters in the filename right
without pain in Perl, so let's do it right:
use vars qw($/);
$/ = "\0";
open F, '-|', 'git-ls-files', '-z'
or die "Failed to open pipe from git-ls-files: " . $!;
@allfiles = map { chomp; $_} <F>;
> +@srcfiles = grep /^$src/, @allfiles;
> +@dstfiles = @srcfiles;
> +s#^$src(/|$)#$dst$1# for @dstfiles;
Be careful with these regexps. Perhaps something like this?
@dstfiles = @srcfiles = grep /^\Q$src\E/, @allfiles;
s#^\Q$src\E(/|$)#$dst$1# for @dstfiles;
or perhaps a bit more readable:
my $qsrc = quotemeta($src);
@dstfiles = @srcfiles = grep /^$qsrc/, @allfiles;
for (@dstfiles) { s/^$qsrc(/|$)/$dst$1/; }
> +rename($src,$dst)
> + or die "rename failed: $!";
Making sure leading directories for $dst exists, perhaps?
Otherwise looks good.
> +sub usage($) {
This is just a style thing, but do you really care to force a
scalar contect when "usage" is used?
^ permalink raw reply
* [PATCH] debian/ binary package dependency fix.
From: Junio C Hamano @ 2005-07-25 6:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Ryan Anderson
Make sure that the binary debian package depends on shlibs it
uses. This point was raised by Alexey Nezhdanov.
The "Depends:" line in debian/control lacked ${shlibs:Depends},
which caused the resulting binary package not to depend on
libcurl3 nor even libc6 ;-).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Acked-by: Ryan Anderson <ryan@michonline.com>
---
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Standards-Version: 3.6.1
Package: git-core
Architecture: any
-Depends: ${misc:Depends}, shellutils, diff, rsync, rcs
+Depends: ${shlibs:Depends}, ${misc:Depends}, shellutils, diff, rsync, rcs
Description: The git content addressable filesystem
GIT comes in two layers. The bottom layer is merely an extremely fast
and flexible filesystem-based database designed to store directory trees
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Marco Costalba @ 2005-07-25 6:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano wrote:
>The list of patterns that is in effect at a given time is
>built and ordered in the following way:
>
> * --exclude=<pattern> and lines read from --exclude-from=<file>
> come at the beginning of the list of patterns, in the order
> given on the command line. Patterns that come from the file
> specified with --exclude-from are ordered in the same order
> as they appear in the file.
>
> * When --exclude-per-directory=<name> is specified, upon
> entering a directory that has such a file, its contents are
> appended at the end of the current "list of patterns". They
> are popped off when leaving the directory.
>
Are really necessary to have both --exclude-from=<file> and
--exclude-per-directory=<name> ?
Peraphs, if the file name of excluded list is the same for each directory,
e.g. .gitignore or something similar, instead of --exclude-per-directory
we can use a concept of file validity 'scope' and just use --exclude-from=<file>.
If entering in a directory <file> is found its contents are appended and
removed when leaving directory. A bad analogy can be with the use of
recursive Makefile.
>
>A pattern specified on the command line with --exclude or read
>from the file specified with --exclude-from is relative to the
>top of the directory tree. A pattern read from a file specified
>by --exclude-per-directory is relative to the directory that the
>pattern file appears in.
>
If we use the 'scope' logic we can just prepend path when adding entries
and serach with with FNM_PATHNAME flag.
> - if it does not contain a slash '/', it is a shell glob
> pattern and used to match against the filename without
> leading directories (i.e. the same way as the current
> implementation).
>
> - otherwise, it is a shell glob pattern, suitable for
> consumption by fnmatch(3) with FNM_PATHNAME flag. I.e. a
> slash in the pattern must match a slash in the pathname.
> "Documentation/*.html" matches "Documentation/git.html" but
> not "ppc/ppc.html". As a natural exception, "/*.c" matches
> "cat-file.c" but not "mozilla-sha1/sha1.c".
>
Same comment as above, if prepending path when adding per
directory contents we can simplify to always use FNM_PATHNAME flag.
We don't have even to special case base directory global
scope <file> if we use realtive paths so that we prepend its contents
with ./ and we have what we expect.
I am sorry to not be able to send a patch, better explaining what
proposed but I am just leaving today and I will be off line
for a couple of weeks.
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Junio C Hamano @ 2005-07-25 7:32 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050725064140.95259.qmail@web26304.mail.ukl.yahoo.com>
Marco Costalba <mcostalba@yahoo.it> writes:
> Are really necessary to have both --exclude-from=<file> and
> --exclude-per-directory=<name> ?
>
> Peraphs, if the file name of excluded list is the same for each directory,
> e.g. .gitignore or something similar, instead of --exclude-per-directory
> we can use a concept of file validity 'scope' and just use --exclude-from=<file>.
> If entering in a directory <file> is found its contents are appended and
> removed when leaving directory. A bad analogy can be with the use of
> recursive Makefile.
Pasky wants to have one of the files in ~/.git-something if I
understand correctly. I did not want to remove --exclude-from
for that reason.
> If we use the 'scope' logic we can just prepend path when
> adding entries and serach with with FNM_PATHNAME flag.
And I wanted for people's script and existing ignore files to
continue to work.
> Same comment as above, if prepending path when adding per
> directory contents we can simplify to always use FNM_PATHNAME flag.
Yes, but that means you need to always prepend the current
directory being looked at to get the original behaviour. The
way it was originally done without FNM_PATHNAME was far easier
to read, at least for me.
^ permalink raw reply
* Re: Problems Importing a CVS tree into FAUmachine
From: Thomas Glanzmann @ 2005-07-25 8:57 UTC (permalink / raw)
To: Matthias Urlichs, GIT
In-Reply-To: <20050724205601.GD2117@cip.informatik.uni-erlangen.de>
Hallo,
> git-cvsimport-script -d /var/lib/cvsd/cvsroots -C /var/lib/cvsd/gitroots/FAUmachine FAUmachine
> <Output of rlog and 'treated as before'>
> Committing initial tree e30105bb454c40a143689b37c11340f1a8f084b4
> Unknown: error
I isolated the error to the following:
<lib/pattern-matcher/input/Pic0.ppm> <1.1>
It tries to retrieve version 1.1 of lib/pattern-matcher/input/Pic0.ppm. However
I can't find a single reference to Pic0.ppm:
(faui02new) [/var/lib/cvsd/cvsroots] grep -rli Pic0.ppm FAUmachine
(faui02new) [/var/lib/cvsd/cvsroots] find . | grep Pic0.ppm
(faui02new) [/var/lib/cvsd/cvsroots]
Ideas?
Thomas
^ permalink raw reply
* Re: Problems Importing a CVS tree into FAUmachine
From: Thomas Glanzmann @ 2005-07-25 9:03 UTC (permalink / raw)
To: Matthias Urlichs, GIT
In-Reply-To: <20050725085756.GA25825@cip.informatik.uni-erlangen.de>
Hello,
> > git-cvsimport-script -d /var/lib/cvsd/cvsroots -C /var/lib/cvsd/gitroots/FAUmachine FAUmachine
> > <Output of rlog and 'treated as before'>
> > Committing initial tree e30105bb454c40a143689b37c11340f1a8f084b4
> > Unknown: error
> I isolated the error to the following:
> <lib/pattern-matcher/input/Pic0.ppm> <1.1>
> It tries to retrieve version 1.1 of lib/pattern-matcher/input/Pic0.ppm. However
> I can't find a single reference to Pic0.ppm:
> (faui02new) [/var/lib/cvsd/cvsroots] grep -rli Pic0.ppm FAUmachine
> (faui02new) [/var/lib/cvsd/cvsroots] find . | grep Pic0.ppm
> (faui02new) [/var/lib/cvsd/cvsroots]
---------------------
PatchSet 10688
Date: 2005/04/28 17:34:58
Author: sistsigw
Branch: HEAD
Tag: (none)
Log:
added some screenshots for development / testing purposes
Members:
lib/pattern-matcher/input/Pic0.ppm:INITIAL->1.1
lib/pattern-matcher/input/Pic1.ppm:INITIAL->1.1
lib/pattern-matcher/input/Pic2.ppm:INITIAL->1.1
lib/pattern-matcher/input/Pic3.ppm:INITIAL->1.1
But I see the PatchSet if I run cvsps manually. Very strange.
Thomas
^ permalink raw reply
* Re: [PATCH] debian/ binary package dependency fix. [u]
From: Andreas Jellinghaus [c] @ 2005-07-25 8:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ryan Anderson
In-Reply-To: <7vackbz9g5.fsf@assigned-by-dhcp.cox.net>
rsync should be Recommended: or Suggested: only,
as git can be used local only as well, and then
rsync is not needed, right?
Regards, Andreas
^ permalink raw reply
* Re: Problems Importing a CVS tree into FAUmachine
From: Matthias Urlichs @ 2005-07-25 9:15 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20050725090313.GB25825@cip.informatik.uni-erlangen.de>
[-- Attachment #1: Type: text/plain, Size: 906 bytes --]
Hi,
Thomas Glanzmann:
> Members:
> lib/pattern-matcher/input/Pic0.ppm:INITIAL->1.1
> lib/pattern-matcher/input/Pic1.ppm:INITIAL->1.1
> lib/pattern-matcher/input/Pic2.ppm:INITIAL->1.1
> lib/pattern-matcher/input/Pic3.ppm:INITIAL->1.1
>
If there's no lib/pattern-matcher/input/Pic0.ppm,v nor
lib/pattern-matcher/input/Attic/Pic0.ppm,v file ...
> But I see the PatchSet if I run cvsps manually. Very strange.
>
... then, congratulations, you've found a bug in cvsps.
Please talk to its author.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I believe that the moment is near when by a procedure of active paranoiac
thought, it will be possible to systematize confusion and contribute to the
total discrediting of the world of reality.
-- Salvador Dali
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Catalin Marinas @ 2005-07-25 9:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Linus Torvalds, git, Marco Costalba
In-Reply-To: <7vd5p73jlu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> * When --exclude-per-directory=<name> is specified, upon
> entering a directory that has such a file, its contents are
> appended at the end of the current "list of patterns". They
> are popped off when leaving the directory.
[...]
> A pattern specified on the command line with --exclude or read
> from the file specified with --exclude-from is relative to the
> top of the directory tree. A pattern read from a file specified
> by --exclude-per-directory is relative to the directory that the
> pattern file appears in.
I think it would make more sense for the exclude-per-directory
patterns to be local to that directory only, without recursively
preserving them for subdirectories. One would, in general, put the
common exclude patterns like *.o *~ etc. in the global file
(.git/exclude). The patterns local to a directory only (take the
vmlinux file for example), one would write it in the .gitignore file
but this should be used for subdirectories.
> An exclude pattern is of the following format:
[...]
That's fine. Actually, the Porcelain would care much about it since it
gets the information already filtered by git.
> $ cat Documentation/.gitignore
> # ignore generated html files,
> # except foo.html which is maintained by hand
> !foo.html
> *.html
Wouldn't it be clearer to have the general rules first (*.html),
overridden by the more specific ones (!foo.html)? Just my opinion, I
don't know what others think.
--
Catalin
^ permalink raw reply
* Re: Problems Importing a CVS tree into FAUmachine
From: Thomas Glanzmann @ 2005-07-25 9:20 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: GIT
In-Reply-To: <20050725091505.GA5680@kiste.smurf.noris.de>
Hello,
> If there's no lib/pattern-matcher/input/Pic0.ppm,v nor
> lib/pattern-matcher/input/Attic/Pic0.ppm,v file ...
no there isn't.
> ... then, congratulations, you've found a bug in cvsps. Please talk
> to its author.
yes, it seems so. My currently theory is that cvsps extracts the
information out of the log message of the Pic1.ppm file. However I
wonder why my grep didn't came with something up.
Thomas
^ permalink raw reply
* Re: Problems Importing a CVS tree into FAUmachine
From: Thomas Glanzmann @ 2005-07-25 9:41 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: GIT
In-Reply-To: <20050725092020.GC25825@cip.informatik.uni-erlangen.de>
Hello,
> yes, it seems so. My currently theory is that cvsps extracts the
> information out of the log message of the Pic1.ppm file. However I
> wonder why my grep didn't came with something up.
bullshit. It was an corrupted / outdates cvsps cache file. Everything
seems to work as expected right now.
Thomas
^ permalink raw reply
* Re: [PATCH] debian/ binary package dependency fix. [u]
From: Junio C Hamano @ 2005-07-25 16:27 UTC (permalink / raw)
To: Andreas Jellinghaus [c]; +Cc: git, Ryan Anderson
In-Reply-To: <200507251052.37618.aj@dungeon.inka.de>
"Andreas Jellinghaus [c]" <aj@dungeon.inka.de> writes:
> rsync should be Recommended: or Suggested: only,
> as git can be used local only as well, and then
> rsync is not needed, right?
I suspect we still use rsync even in some local cases (rsync
between two local directories). At least we once used to and I
do not remeber touching that piece of code..
^ permalink raw reply
* updating the git documentation on http://www.kernel.org/pub/software/scm/git/docs/
From: Thomas Glanzmann @ 2005-07-25 18:57 UTC (permalink / raw)
To: David Woodhouse, GIT
Hello David,
I hope you're the right contact person for this. Could you please update
the documentation on http://www.kernel.org/pub/software/scm/git/docs/ .
It is a bit outdated. I just wanted to send a co-worker a link to the
'migration from cvs' URL and couldn't find one.
Thanks,
Thomas
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Junio C Hamano @ 2005-07-25 19:56 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050725064140.95259.qmail@web26304.mail.ukl.yahoo.com>
Marco Costalba <mcostalba@yahoo.it> writes:
> Peraphs, if the file name of excluded list is the same for each directory,
> e.g. .gitignore or something similar, instead of --exclude-per-directory
> we can use a concept of file validity 'scope' and just use --exclude-from=<file>.
> If entering in a directory <file> is found its contents are appended and
> removed when leaving directory. A bad analogy can be with the use of
> recursive Makefile.
I do not know if you noticed it, but the patch already have the
concept of "scope". If a pattern has a slash '/' it is scoped
to the named directory by using FNM_PATHNAME. "The named
directory" for command line --exclude and --exclude-from are
relative to the project top while it is relative to the
directory the file being used is in for --exclude-per-directory
case.
> If we use the 'scope' logic we can just prepend path when adding entries
> and serach with with FNM_PATHNAME flag.
You suggest to always use FNM_PATHNAME by adjusting the pattern
by prefixing the scope. While that can theoretically be made to
work just as the posted patch does, you need to realize it is a
lot more cumbersome to deal with metacharacters in pathnames
your way. If the prefix you need to add (because you are now
looking at a path for that directory which has a funny name) is
"foo*bar", you need to add "foo\*bar" to the pattern in order to
make sure that the asterisk is not used to match anything other
than a literal asterisk, for example.
You could argue that nobody should use funny characters in
pathnames, and you could further argue that current Porcelains
do not handle certain characters in pathnames anyway so why
bother. But ls-files being core, which is "the funny filesystem
layer to build SCM on", I would like to be careful not to be
unnecessarily restrictive.
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Junio C Hamano @ 2005-07-25 19:58 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Petr Baudis, Linus Torvalds, git, Marco Costalba
In-Reply-To: <tnxmzobutsf.fsf@arm.com>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> I think it would make more sense for the exclude-per-directory
> patterns to be local to that directory only, without recursively
> preserving them for subdirectories.
I personally do not have preference either way, but am slightly
biased towards the "cumulative" behaviour the patch attempts to
implement, which was what Pasky said he wanted to have.
Date: Fri, 22 Jul 2005 22:59:48 +0200
From: Petr Baudis <pasky@suse.cz>
Subject: Re: [PATCH 1/1] Tell vim the textwidth is 75.
Message-ID: <20050722205948.GE11916@pasky.ji.cz>
> *3* .gitignore in the cwd is used in Cogito, if I am not
> mistaken.
Yes. There were several discussions about this in the past, with no
clear outcome, IIRC. I would prefer:
~/.git/ignore per-user
/.git/ignore per-repository
.gitignore per-directory (cummulative with parent directories)
>> An exclude pattern is of the following format:
> [...]
>
> That's fine. Actually, the Porcelain would care much about it since it
> gets the information already filtered by git.
Your saying "fine" is a relief. This change aims at helping
Porcelain people by making it less likely for Porcelain to need
its own filtering. As you say, if ls-files filters more than
the Porcelain wants, that's a bigger problem.
>> $ cat Documentation/.gitignore
>> # ignore generated html files,
>> # except foo.html which is maintained by hand
>> !foo.html
>> *.html
>
> Wouldn't it be clearer to have the general rules first (*.html),
> overridden by the more specific ones (!foo.html)? Just my opinion, I
> don't know what others think.
I do not know, either, but I do know it is consistent with the
"first match determines fate" rule and cleaner to implement.
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Linus Torvalds @ 2005-07-25 20:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Catalin Marinas, Petr Baudis, git, Marco Costalba
In-Reply-To: <7vk6jelkty.fsf@assigned-by-dhcp.cox.net>
On Mon, 25 Jul 2005, Junio C Hamano wrote:
>
> I personally do not have preference either way, but am slightly
> biased towards the "cumulative" behaviour the patch attempts to
> implement, which was what Pasky said he wanted to have.
I think that makes sense.
Imagine, for example, that you have separate subdirectory structures for
Documentation and for source - maybe you'd put the "*.o" rule in the
source directory, and a "*.1" rule in the Docs subdirectory.
Linus
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Junio C Hamano @ 2005-07-25 20:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Catalin Marinas, Petr Baudis, git, Marco Costalba
In-Reply-To: <Pine.LNX.4.58.0507251306420.6074@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 25 Jul 2005, Junio C Hamano wrote:
>>
>> I personally do not have preference either way, but am slightly
>> biased towards the "cumulative" behaviour the patch attempts to
>> implement, which was what Pasky said he wanted to have.
>
> I think that makes sense.
>
> Imagine, for example, that you have separate subdirectory structures for
> Documentation and for source - maybe you'd put the "*.o" rule in the
> source directory, and a "*.1" rule in the Docs subdirectory.
I imagined it, but it appears to me that this is a bad example.
My understanding of what Catalin and the proposed patch
disagrees is whether the patterns in .gitignore at the top level
should govern files under ppc/ and mozilla-sha1/ subdirectories;
Catalin thinks they should not.
What I meant by "cumulative" (now I realize I might have
misunderstood what Pasky wanted to mean by that word, though)
was not just .gitignore in subdirectory being added, but the
effect of patterns being added so far, either from the command
line or by parent directories, last while in the deeper
directories.
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Catalin Marinas @ 2005-07-25 20:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Petr Baudis, git, Marco Costalba
In-Reply-To: <7vll3uk4w7.fsf@assigned-by-dhcp.cox.net>
On Mon, 2005-07-25 at 13:27 -0700, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
> > Imagine, for example, that you have separate subdirectory structures for
> > Documentation and for source - maybe you'd put the "*.o" rule in the
> > source directory, and a "*.1" rule in the Docs subdirectory.
>
> I imagined it, but it appears to me that this is a bad example.
> My understanding of what Catalin and the proposed patch
> disagrees is whether the patterns in .gitignore at the top level
> should govern files under ppc/ and mozilla-sha1/ subdirectories;
> Catalin thinks they should not.
I really don't have a strong preference for this. Linus' example makes
sense as well. It's up to you how you implement its behaviour,
Porcelains shouldn't be affected by this.
Since I'm the only one with this idea, you can forget about it (I don't
mind :-) ). If others express a preference for this, you could implement
a 'cut' label (similar to Prolog's cut operator) which clears the
pattern stack before diving into subdirectories. Anyway, I don't think
it's worse the hassle since it might never be used.
--
Catalin
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Catalin Marinas @ 2005-07-25 20:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Linus Torvalds, git, Marco Costalba
In-Reply-To: <7vk6jelkty.fsf@assigned-by-dhcp.cox.net>
On Mon, 2005-07-25 at 12:58 -0700, Junio C Hamano wrote:
> Catalin Marinas <catalin.marinas@gmail.com> writes:
> >> An exclude pattern is of the following format:
> > [...]
> >
> > That's fine. Actually, the Porcelain would care much about it since it
> > gets the information already filtered by git.
>
> Your saying "fine" is a relief. This change aims at helping
> Porcelain people by making it less likely for Porcelain to need
> its own filtering. As you say, if ls-files filters more than
> the Porcelain wants, that's a bigger problem.
I don't plan to add any additional filtering in StGIT. What I meant
above was that Porcelain would not care much about the patterns. The
user should cope with what git provides, nothing more. With these git
patches, I think there are enough features for filtering.
> > Wouldn't it be clearer to have the general rules first (*.html),
> > overridden by the more specific ones (!foo.html)? Just my opinion, I
> > don't know what others think.
>
> I do not know, either, but I do know it is consistent with the
> "first match determines fate" rule and cleaner to implement.
I also don't have a strong preference for this and the "first match"
rule clarifies it (otherwise, you could have pushed them on a list in
reverse order).
--
Catalin
^ permalink raw reply
* Fwd: Re: [RFC] extending git-ls-files --exclude.
From: Marco Costalba @ 2005-07-25 21:39 UTC (permalink / raw)
To: git
--- Marco Costalba <mcostalba@yahoo.it> wrote:
> Date: Mon, 25 Jul 2005 14:34:56 -0700 (PDT)
> From: Marco Costalba <mcostalba@yahoo.it>
> Subject: Re: [RFC] extending git-ls-files --exclude.
> To: Junio C Hamano <junkio@cox.net>
> CC: Linus Torvalds <torvalds@osdl.org>,
> Catalin Marinas <catalin.marinas@gmail.com>, Petr Baudis <pasky@suse.cz>
>
> Junio C Hamano wrote:
>
> >Linus Torvalds <torvalds@osdl.org> writes:
> >
> >>On Mon, 25 Jul 2005, Junio C Hamano wrote:
> >>
> >I imagined it, but it appears to me that this is a bad example.
> >My understanding of what Catalin and the proposed patch
> >disagrees is whether the patterns in .gitignore at the top level
> >should govern files under ppc/ and mozilla-sha1/ subdirectories;
> >Catalin thinks they should not.
> >
> >What I meant by "cumulative" (now I realize I might have
> >misunderstood what Pasky wanted to mean by that word, though)
> >was not just .gitignore in subdirectory being added, but the
> >effect of patterns being added so far, either from the command
> >line or by parent directories, last while in the deeper
> >directories.
> >
>
> This cumulative effect brakes local scoping of .gitignore files in
> corresponding subdirectory.
>
> As example in a directory A we can have a .gitignore file with
>
> !foo.html
> *.html
>
> because we want to special case 'that' foo.html
> in 'that' directory.
>
> If for any reason in any of part of subdirectories tree
> with base A there is (or there will be in the future) another
> foo.html this will be automatically special cased because
> of cumulative adding of patterns.
>
> This can be powerful and flexible but also prone to errors.
>
> Peraphs can be better to use just one file with global scope
> (as example .git/exclude) and all the others .gitignore files
> with scope local to their directory.
>
>
> Marco
>
>
>
>
>
>
>
>
> ____________________________________________________
> Start your day with Yahoo! - make it your home page
> http://www.yahoo.com/r/hs
>
>
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Junio C Hamano @ 2005-07-25 22:06 UTC (permalink / raw)
To: Marco Costalba; +Cc: Linus Torvalds, Catalin Marinas, Petr Baudis, git
In-Reply-To: <20050725213456.23910.qmail@web26310.mail.ukl.yahoo.com>
Marco Costalba <mcostalba@yahoo.it> writes:
> This cumulative effect brakes local scoping of .gitignore files in
> corresponding subdirectory.
>
> As example in a directory A we can have a .gitignore file with
>
> !foo.html
> *.html
>
> because we want to special case 'that' foo.html in 'that'
> directory.
I guess that !foo.html I wrote was a bad example of special case
not being specific enough. Saying "!/foo.html" should work
[*1*], so I think "cumulative effect _breaks_" is a bit too strong
a word.
Having said that,...
> This can be powerful and flexible but also prone to errors.
While I also suspect it _might_ be prone to user errors, at
least to some classes of users, Catalin (and Peter as well I
suspect, although I may be mistaken by what he originally meant
by "cumulative") seems to think it is OK. As a developer of
another Porcelain (qgit), your input is as valuable as others,
so...
BTW, I am CC'ing git list because I saw you forwarded your
entire message to the list as a quoted message form. Please do
not do that. I cannot distinguish a message like that with a
message with nothing but quote and no original contents, which I
normally discard without even reading.
[Footnote]
*1* I just tried, and it seems to work.
$ rm -f .gitignore ppc/.gitignore
$ (echo '!/foo.bar'; echo '*.bar') >.gitignore
$ for i in foo.bar baz.bar; do date >$i; date >ppc/$i; done
$ git-ls-files --others --exclude-per-directory=.gitignore | grep '\.bar'
foo.bar
$ rm -f .gitignore ppc/.gitignore
^ permalink raw reply
* Re: Using git with http behind proxy with authentification?
From: Darrin Thompson @ 2005-07-25 22:14 UTC (permalink / raw)
To: Dirk Behme; +Cc: git
In-Reply-To: <42E21A33.6010804@de.bosch.com>
On Sat, 2005-07-23 at 12:21 +0200, Dirk Behme wrote:
> In the past, for bk I used
>
> $ export http_proxy=http://user:password@someproxy.some.where:8080/
>
> which worked. But no luck with cogito/git.
>
> Looking into recent cogito/git, the reason for this seems to be that
> cogito/git uses a combination of wget in scripts and curl in compiled
> executables. Having a look to cg-pull script, this script uses wget.
> Then, it calls git-http-pull if it thinks that http should be used.
> Looking at http-pull.c shows that there curl is used for http access. If
> I understand it correctly from man pages, wget understands user:password
> syntax of http_proxy environment, but curl doesn't. As I understand it
> curl understands only 'someproxy.some.where:8080' and wants the user and
> password given as parameter of curl_easy_setopt. The curl_easy_setopt
> man page tells something about CURLOPT_PROXYUSERPWD parameter.
>
For git itself everything is curl only now as far as I know. That's new
as of hours after you sent this.
Git turns on .netrc for doing 401 http auth. I wonder if curl will
consult .netrc for 407 proxy credentials as well?
Somebody would have to read code and/or try it.
--
Darrin
^ permalink raw reply
* Re: [PATCH] git-cvsimport-script: parse multidigit revisions
From: Linus Torvalds @ 2005-07-25 23:00 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Sven Verdoolaege, Git Mailing List
In-Reply-To: <20050713011818.GM9915@kiste.smurf.noris.de>
On Wed, 13 Jul 2005, Matthias Urlichs wrote:
>
> Sven Verdoolaege:
> > Previously, git-cvsimport-script would fail
> > on revisions with more than one digit.
> >
> Ouch. Thanks.
Hmm.. I finally tried to import the bkcvs kernel tree into git, and while
I'm cursing the slowness of CVS (I'm _hoping_ that part of the problem is
just that CVS is especially slow with old versions of files, and that the
import will eventually start speeding up), there's definitely something
wrong going on with new files in an archive...
In particular, they always end up being imported as zero-sized empty
files, and will be filled in only later if that file is ever touched
again. In other words, the resulting git tree ends up being bogus.
The command line I used was
git cvsimport -d /home/torvalds/bkcvs -p --bkcvs linux-2.5
and I wonder if it's the "--bkcvs" thing that confuses cvsimport, but I
also wonder if anybody has actually tried this before. With or without
the --bkcvs line, I get
Argument "28213 has collisions" isn't numeric in addition (+) at /home/torvalds/bin/git-cvsimport-script line 600, <CVS> line 1.
* UNKNOWN LINE * PatchSet 28209 has collisions
* UNKNOWN LINE * PatchSet 28194 has collisions
* UNKNOWN LINE * PatchSet 28181 has collisions
* UNKNOWN LINE * PatchSet 28180 has collisions
...
Sadly, since I don't know perl, I can't tell whether this is a problem
with cvsps on the kernel, or the cvsimport perl script. I'm going to try
my old hacky C + shell alternative next just to see, but I thought I'd ask
whether people have tried this before and already know what's wrong.
Btw, looking at what the perl script _seems_ to do, it does seem to do
insane things for the local CVS archive case. As far as I can tell from
the spaghetti that is perl, it uses a CVS server to handle even the local
file case, which just _can't_ be right. I realize you'd want to do that to
avoid connecting millions of times, but maybe it's better to use something
like cvsnup to download the whole thing, and then always use a local CVS
archive?
Linus
^ permalink raw reply
* [PATCH] git-tag-script updates.
From: Junio C Hamano @ 2005-07-25 23:02 UTC (permalink / raw)
To: git
This adds -a (annotate only but not sign) option "A Large Angry
SCM" <gitzilla@gmail.com> sent to the list, after fixing up the
whitespace corruption in the patch, with some of my own fixes.
Namely, changes are:
* A new flag '-a' can be used to create an unsigned tag
object;
* The '-f' flag logic did not do the right thing;
* When creating a signed tag, we did not check for GPG failure
as we should;
* Try to use the key for the tagger identity when signing the
tag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-tag-script | 32 ++++++++++++++++++++++++++------
1 files changed, 26 insertions(+), 6 deletions(-)
0fad0fdd4beadb2ff06af8d5a16d509cd8796ee4
diff --git a/git-tag-script b/git-tag-script
--- a/git-tag-script
+++ b/git-tag-script
@@ -3,17 +3,30 @@
. git-sh-setup-script || die "Not a git archive"
+usage () {
+ echo >&2 "Usage: git-tag-script [-a | -s] [-f] tagname"
+ exit 1
+}
+
+annotate=
signed=
force=
while case "$#" in 0) break ;; esac
do
case "$1" in
+ -a)
+ annotate=1
+ ;;
-s)
+ annotate=1
signed=1
;;
-f)
force=1
;;
+ -*)
+ usage
+ ;;
*)
break
;;
@@ -22,16 +35,19 @@ do
done
name="$1"
-[ "$name" ] || die "I need a tag-name"
-[ -e "$GIT_DIR/refs/tags/$name" ] &&
- [ "$force" ] || die "tag '$name' already exists"
+[ "$name" ] || usage
+if [ -e "$GIT_DIR/refs/tags/$name" -a -z "$force" ]; then
+ die "tag '$name' already exists"
+fi
shift
object=$(git-rev-parse --verify --revs-only --default HEAD "$@") || exit 1
type=$(git-cat-file -t $object) || exit 1
tagger=$(git-var GIT_COMMITTER_IDENT) || exit 1
-if [ "$signed" ]; then
+trap 'rm -f .tmp-tag* .tagmsg .editmsg' 0
+
+if [ "$annotate" ]; then
( echo "#"
echo "# Write a tag message"
echo "#" ) > .editmsg
@@ -43,9 +59,13 @@ if [ "$signed" ]; then
( echo -e "object $object\ntype $type\ntag $name\ntagger $tagger\n"; cat .tagmsg ) > .tmp-tag
rm -f .tmp-tag.asc .tagmsg
- gpg -bsa .tmp-tag && cat .tmp-tag.asc >> .tmp-tag
+ if [ "$signed" ]; then
+ me=$(expr "$tagger" : '\(.*>\)') &&
+ gpg -bsa -u "$me" .tmp-tag &&
+ cat .tmp-tag.asc >>.tmp-tag ||
+ die "failed to sign the tag with GPG."
+ fi
object=$(git-mktag < .tmp-tag)
- rm -f .tmp-tag .tmp-tag.sig
fi
mkdir -p "$GIT_DIR/refs/tags"
^ 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