Also, restore support for the GIT_DIR
Signed-off-by: Ryan Anderson <[EMAIL PROTECTED]>
---
git-rename-script | 26 ++
1 files changed, 10 insertions(+), 16 deletions(-)
1ed66638c7ce328d882639447b80099f096c2993
diff --git a/git-rename-script b/git-rename-script
--- a/g
Linus Torvalds <[EMAIL PROTECTED]> writes:
> See? Trying to have one really solid code-path is not a waste of time.
An alternative code path specialized for local case would not be
too bad.
First, finding the list of objects to copy. You can use
alternate object pool to cover the upstream repo
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 case
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
> th
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
10
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
On Mon, 25 Jul 2005, Linus Torvalds wrote:
>
> And they are in the wrong order, so "cvsimport" ends up committing the
> last one, which is the _empty_ one.
>
> Notice? We'll end up committing "COPYING 1.1" (the empty initial create)
> even though we _should_ have committed "COPYING 1.2" (the a
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
interna
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
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 |
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 th
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 c
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 do
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
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 _hop
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 o
Marco Costalba <[EMAIL PROTECTED]> 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'
> d
--- 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
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.
>
>
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
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 t
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 ha
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=.
> If entering in a di
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
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
"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 u
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
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
informat
Junio C Hamano <[EMAIL PROTECTED]> wrote:
> * When --exclude-per-directory= 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 specif
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
>
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 http://vger.kernel.or
Hello,
> > git-cvsimport-script -d /var/lib/cvsd/cvsroots -C
> > /var/lib/cvsd/gitroots/FAUmachine FAUmachine
> >
> > Committing initial tree e30105bb454c40a143689b37c11340f1a8f084b4
> > Unknown: error
> I isolated the error to the following:
> <1.1>
> It tries to retrieve v
Hallo,
> git-cvsimport-script -d /var/lib/cvsd/cvsroots -C
> /var/lib/cvsd/gitroots/FAUmachine FAUmachine
>
> Committing initial tree e30105bb454c40a143689b37c11340f1a8f084b4
> Unknown: error
I isolated the error to the following:
<1.1>
It tries to retrieve version 1
Marco Costalba <[EMAIL PROTECTED]> writes:
> Are really necessary to have both --exclude-from= and
> --exclude-per-directory= ?
>
> 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
34 matches
Mail list logo
