Signed-off-by: Ryan Anderson [EMAIL PROTECTED]
---
Documentation/git-rename-script.txt | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-rename-script.txt
715924203401309ceb2f696e507b8b2c18244d08
diff --git
Signed-off-by: Ryan Anderson [EMAIL PROTECTED]
---
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
---
Ryan Anderson [EMAIL PROTECTED] writes:
+open(F,-|,git-ls-files)
+ or die Failed to open pipe from git-ls-files: . $!;
+
[EMAIL PROTECTED] = 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($/);
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
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
Marco Costalba [EMAIL PROTECTED] 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
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:
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:
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
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
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
Junio C Hamano [EMAIL PROTECTED] 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
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
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
Andreas Jellinghaus [c] [EMAIL PROTECTED] 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
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,
Catalin Marinas [EMAIL PROTECTED] 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
Marco Costalba [EMAIL PROTECTED] 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
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
Linus Torvalds [EMAIL PROTECTED] 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
On Mon, 2005-07-25 at 13:27 -0700, Junio C Hamano wrote:
Linus Torvalds [EMAIL PROTECTED] 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
On Mon, 2005-07-25 at 12:58 -0700, Junio C Hamano wrote:
Catalin Marinas [EMAIL PROTECTED] 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
--- Marco Costalba [EMAIL PROTECTED] wrote:
Date: Mon, 25 Jul 2005 14:34:56 -0700 (PDT)
From: Marco Costalba [EMAIL PROTECTED]
Subject: Re: [RFC] extending git-ls-files --exclude.
To: Junio C Hamano [EMAIL PROTECTED]
CC: Linus Torvalds [EMAIL PROTECTED],
Catalin Marinas [EMAIL
On Sat, 2005-07-23 at 12:21 +0200, Dirk Behme wrote:
In the past, for bk I used
$ export http_proxy=http://user:[EMAIL PROTECTED]: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
This adds -a (annotate only but not sign) option A Large Angry
SCM [EMAIL PROTECTED] 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
Hi,
Linus Torvalds:
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.
That's a problem with the bkcvs tree. Remember tht Bitkeeper does
Thomas Glanzmann [EMAIL PROTECTED] writes:
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
Since both of you seem to be in favor of using 'A' instead of
'N' for added files in the diff-raw output, here are two patches
requesting for test.
[PATCH] Use symbolic constants for diff-raw status indicators.
[PATCH] diff-raw: Use 'A' instead of 'N' for added files.
-
To unsubscribe from
Both Cogito and StGIT prefer to see 'A' for new files. The
current 'N' is visually harder to distinguish from 'M', which is
used for modified files. Prepare the internals to use symbolic
constants to make the change easier.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
diff-helper.c |
This actually changes the diff-raw status letter from N to A
for added files.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
diff.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
ca8c9156f8f980455f64e2cedcf0347328e46029
diff --git a/diff.h b/diff.h
--- a/diff.h
+++ b/diff.h
On Tue, 26 Jul 2005, Matthias Urlichs wrote:
That's a problem with the bkcvs tree. Remember tht Bitkeeper does
exactly the same thing -- the 1.0 version of *any* file is empty, and
content appears only in version 1.1.
Not really. That may be how the SCCS _deltas_ end up being done
On Tue, Jul 26, 2005 at 01:42:57AM +0200, Matthias Urlichs wrote:
(Side question - why aren't you doing a direct bk2git import?)
The last time I went looking for a tool to do this, I failed to find it
- where can I get this?
--
Ryan Anderson
sometimes Pug Majere
-
To unsubscribe from this
Whenever I pull a local repository, such as
cd /spare/repo/libata-dev
git pull /spare/repo/linux-2.6/.git
git will pack, then unpack, the objects being pulled. AFAICT this is
just a complete waste of time. Why does this occur?
Packing 1394 objects
Unpacking 1394 objects
On Tue, 26 Jul, Jeff Garzik wrote:
AFAICT this is
just a complete waste of time. Why does this occur?
Packing 1394 objects
Unpacking 1394 objects
100% (1394/1394) done
It doesn't seem to make any sense to perform work, then immediately undo
that work,
Linus Torvalds wrote:
First, make sure you have a recent git, it does better at optimizing the
I was using vanilla git, as of 10 minutes before I sent the email. Top
of tree is 154d3d2dd2656c23ea04e9d1c6dd4e576a7af6de.
Secondly, what's the problem? Sure, I could special-case the local
34 matches
Mail list logo
