* Re: [PATCH] Add a custom ./configure script
From: Alex Riesen @ 2006-07-05 16:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git
In-Reply-To: <20060704215747.GQ29115@pasky.or.cz>
On 7/4/06, Petr Baudis <pasky@suse.cz> wrote:
> >
> > If you named it for example configure.sh, then autoconf generated version,
> > and your by hand created version could coexist.
>
> I'm not opposed to it per se, but I'm just not sure if it makes any
> sense to support them both in parallel, since then you have parallel
> infrastructure doing the exactly same thing, or worse yet - performing
> a subtly different set of tests. The benefit is unclear to me.
The benefit is on user side: he'll take what works for him, without waiting
for you or Jakub to fix it for him.
> Another thing is that it's named *everywhere* ./configure and if I use a
> different name now then it will be hard to rename.
but it not the same configure as "everywhere". It's your very own script.
That said, I like your script better than the autoconf thing.
^ permalink raw reply
* git reset --hard include/linux/config.h
From: Sam Ravnborg @ 2006-07-05 16:58 UTC (permalink / raw)
To: git
While working on something unrelated I just did a quick hack
in include/linux/config.h
When done I wanted to get rid of the changes so I did:
git reset --hard include/linux/config.h
And the changes made to include/linux/config.h was indeed gone, with
all the other changes I had in other files.
Now git reset is maybe supposed to work on commit level only, but it
would have been nice if it erroroed out when it saw an argument that
it did not know about. In this case I assume git reset used
"include/linux/config.h" as <commitish>.
Also what is the right command to bring back a file to the original
state after doing some modifications that was not needed anyway?
Sam
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Johannes Schindelin @ 2006-07-05 17:04 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git, Junio C Hamano
In-Reply-To: <44ABE596.40103@gmail.com>
Hi,
On Wed, 5 Jul 2006, A Large Angry SCM wrote:
> If grafts in your repository create a cycle, the misbehavior of merge-base
> should be among the least of your concerns.
Right. BUT grafts can be very helpful to connect branches which were
independently imported into git. And in these cases, the clockSkew really
is no clockSkew. But in that case, the generation number would have to be
recalculated also.
Anyway, I think that it should be a configurable, which defaults to off,
i.e. in the normal case merge-base should behave as it does now. And if we
have that configurable, we might as well take the safe but dumb approach
to just traverse _everything_.
Ciao,
Dscho
^ permalink raw reply
* Re: git reset --hard include/linux/config.h
From: Alex Riesen @ 2006-07-05 17:05 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20060705165801.GA11822@mars.ravnborg.org>
On 7/5/06, Sam Ravnborg <sam@ravnborg.org> wrote:
> Also what is the right command to bring back a file to the original
> state after doing some modifications that was not needed anyway?
git checkout HEAD include/linux/config.h
^ permalink raw reply
* Re: git reset --hard include/linux/config.h
From: Sam Ravnborg @ 2006-07-05 17:14 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0607051005s59315296tfb68345959a14c1b@mail.gmail.com>
On Wed, Jul 05, 2006 at 07:05:27PM +0200, Alex Riesen wrote:
> On 7/5/06, Sam Ravnborg <sam@ravnborg.org> wrote:
> >Also what is the right command to bring back a file to the original
> >state after doing some modifications that was not needed anyway?
>
> git checkout HEAD include/linux/config.h
Thanks!
By the way - the modifications to include/linux/config.h was not lost.
But git apperantly managed to be fooled to think the file was
up-to-date.
Sam
^ permalink raw reply
* Re: git reset --hard include/linux/config.h
From: Alex Riesen @ 2006-07-05 17:29 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20060705171406.GA17834@mars.ravnborg.org>
On 7/5/06, Sam Ravnborg <sam@ravnborg.org> wrote:
> On Wed, Jul 05, 2006 at 07:05:27PM +0200, Alex Riesen wrote:
> > On 7/5/06, Sam Ravnborg <sam@ravnborg.org> wrote:
> > >Also what is the right command to bring back a file to the original
> > >state after doing some modifications that was not needed anyway?
> >
> > git checkout HEAD include/linux/config.h
>
> Thanks!
>
> By the way - the modifications to include/linux/config.h was not lost.
> But git apperantly managed to be fooled to think the file was
> up-to-date.
After that checkout or after reset --hard? Both is quiet unusual, though
^ permalink raw reply
* Re: Why's Git called Git ?
From: Aaron Gray @ 2006-07-05 19:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607032022050.12404@g5.osdl.org>
Anyway good going, I am glad Linux has an open source VCS again now.
I do not know how BitKeeper are going to fell knowing they have been
replaced by a Git :)
I am toying with using a VCS for a set of related projects, either CVS
because its well known, SubVersion for ease of use, or Git as it is new.
Lots to descide upon, any pointers would be appreciated.
All the best to the Git team.
Regards,
Aaron
----- Original Message -----
From: "Linus Torvalds" <torvalds@osdl.org>
To: "Aaron Gray" <angray@beeb.net>
Cc: "Git Mailing List" <git@vger.kernel.org>
Sent: Tuesday, July 04, 2006 4:28 AM
Subject: Re: Why's Git called Git ?
>
>
> On Tue, 4 Jul 2006, Aaron Gray wrote:
>>
>> Why the name I could not find any answer in the documentation ?
>
> It's really quite random. It needs to be a two- or three-letter thing just
> because I end up typing a lot.
>
> My favourite explanation is "I name all my projects after myself: first
> 'Linux', now 'git'".
>
> Which only makes sense if you know british slang.
>
> The runner up was "Because 'twerp' was too hard to type".
>
> But really, there's not a lot of real thinking behind it. The made-up
> acronym was "global information tracker", but that's a pretty bad excuse
> too.
>
> It just happened. Don't ask me why. All the explanations are really made
> up after the fact.
>
> Linus
^ permalink raw reply
* Re: Why's Git called Git ?
From: Jakub Narebski @ 2006-07-05 19:33 UTC (permalink / raw)
To: git
In-Reply-To: <001001c6a06d$6e7b94b0$0200a8c0@AMD2500>
Aaron Gray wrote:
> Anyway good going, I am glad Linux has an open source VCS again now.
>
> I do not know how BitKeeper are going to fell knowing they have been
> replaced by a Git :)
>
> I am toying with using a VCS for a set of related projects, either CVS
> because its well known, SubVersion for ease of use, or Git as it is new.
> Lots to descide upon, any pointers would be appreciated.
CVS is showing it's age; mainly the fact that IIRC it began as a series of
scripts over RCS, file level version control system, extending version
control to sets of files, somewhat. Branching in CVS is serious PITA.
Renaming _with_ retaining full and correct history: forget about it.
Subversion is "better CVS": still centralized, CVS infernal branching
replaced by "cheap copy" branching. Well known, replaces CVS thorough OSS
projects.
Git, Mercurial, Monotone, Bazaar-NG, Darcs are new brand of distributed VCS.
I really like notion of branching in Git; but be warned about tracking and
not recording renames, and the need of explicit packing (the latter very
minor). Powerfull, perhaps too powerfull for newbie user: but that is what
Cogito is for (although now Git contains fairly large set of high-level
commands).
http://git.or.cz/
http://git.or.cz/gitwiki
http://git.or.cz/gitwiki/Git
and "Other version control software" at
http://git.or.cz/gitwiki/GitLinks
P.S. If you decide to use Git as VCS for your project, consider adding entry
about it on http://git.or.cz/gitwiki/GitProjects wiki page.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git (at FreeNode)
^ permalink raw reply
* Re: Strange date format in git-send-email
From: Junio C Hamano @ 2006-07-05 21:22 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <e8fv2o$khv$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> There were two patches on the list: one hacky adding setlocale
> call (not applied), second implementing rfc-822 date in Perl.
> Should be in current.
What do you mean by "should be in current"?
I specifically asked you about this issue a few days ago, even
with a patch to test out for people who are having problems, but
haven't heard back anything yet. The issue is still on hold and
not in "current" as far as I am concerned.
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org, Eric Wong <normalperson@yhbt.net>
From: Junio C Hamano <junkio@cox.net>
Subject: Re: [PATCH] send-email: Use setlocale in addition to
$ENV{LC_ALL} to set locale
Date: Sun, 02 Jul 2006 19:49:50 -0700
Message-ID: <7vd5cnv1v5.fsf@assigned-by-dhcp.cox.net>
I was reviewing old log and noticed this topic has never been
resolved. Your proposal was to use POSIX::setlocale(), and
Eric's counter-proposal was to mimic what 822-date script does,
doing it by hand without mucking with locales, and the
discussion seemed to have died there. Does this still need to
be addressed?
My gut feeling is that it would probably be less problematic if
we do not muck with locales at all (so drop POSIX::strftime as
well).
So maybe something like this (totally untested)?
...
^ permalink raw reply
* Logo your Business Identity (ID4949330)
From: Lynne Ellis @ 2006-07-05 21:44 UTC (permalink / raw)
To: geogirb
z6b
Our art team creates a custom logo for you, based on your needs. Years of experience have taught us how to create a logo that makes a statement that is unique to you.
In a professional manner we learn about your image and how you would like the world to perceive you and your company. With this information we then create a logo that is not only unique but reflects the purpose of you and your company.
For value and a logo that reflects your image, take a few minutes and visit Logo Maker!
http://bilge.biz.try-logosxb.biz
Sincerely,
Logo Design Team
appropriate ambient betatron
^ permalink raw reply
* Re: merge-base: update the clean-up postprocessing
From: Junio C Hamano @ 2006-07-05 23:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: A Large Angry SCM, git
In-Reply-To: <Pine.LNX.4.63.0607050946390.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 4 Jul 2006, Junio C Hamano wrote:
>
>> This is "for concepts" only -- it still seems to have bugs
>> somewhere to break other tests, although it passes your new
>> tests.
>
> Doesn't this introduce a nasty O(n*m) performance (where m is the
> number of merge bases, and n the number of traversed commits)? I think
> possibly many commits are traversed multiple times.
In practice m is small and the recomputation of bases between
bases does not require the minimalization so O(m^2). I've given
the numbers from a small real world example on the fixed code.
^ permalink raw reply
* Re: merge-base: update the clean-up postprocessing
From: Junio C Hamano @ 2006-07-05 23:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: A Large Angry SCM, git
In-Reply-To: <Pine.LNX.4.63.0607050946390.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> BTW ALAS' argument about grafts not only shot down my maximumSkew, but
> AFAICT also the generation number thing. Besides, the generation number
> could be manipulated by a mean-spirited person also.
I think with the fixed-up version of "concepts only" patch,
generation number approach is already moot.
^ permalink raw reply
* Does Git run on Windows ?
From: Aaron Gray @ 2006-07-06 2:55 UTC (permalink / raw)
To: Git Mailing List
This maybe a stupid question but does Git run on Windows ?
Are there better options ?
If not how much work would it be to port it ?
Its got lots of C code, and Bash scripts, with a couple of Perl scripts.
So should run on Cygwin okay, maybe even MinGW. Anyone tried either ?
This maybe the crunch and reason to use CVS for now :(?)
Aaron
^ permalink raw reply
* Re: Does Git run on Windows ?
From: Christopher Faylor @ 2006-07-06 2:08 UTC (permalink / raw)
To: Aaron Gray, Git Mailing List
In-Reply-To: <01c001c6a0a7$a2783f90$0200a8c0@AMD2500>
On Thu, Jul 06, 2006 at 03:55:25AM +0100, Aaron Gray wrote:
>This maybe a stupid question but does Git run on Windows ?
Yes.
cgf
^ permalink raw reply
* Why's Git called Git ?
From: Aaron Gray @ 2006-07-06 2:18 UTC (permalink / raw)
To: Git Mailing List
>> I am toying with using a VCS for a set of related projects, either CVS
>> because its well known, SubVersion for ease of use, or Git as it is new.
>> Lots to descide upon, any pointers would be appreciated.
>
> CVS is showing it's age; mainly the fact that IIRC it began as a series of
> scripts over RCS, file level version control system, extending version
> control to sets of files, somewhat. Branching in CVS is serious PITA.
> Renaming _with_ retaining full and correct history: forget about it.
Okay, we like branching and forking.
> Subversion is "better CVS": still centralized, CVS infernal branching
> replaced by "cheap copy" branching. Well known, replaces CVS thorough OSS
> projects.
Okay.
> Git, Mercurial, Monotone, Bazaar-NG, Darcs are new brand of distributed
> VCS.
> I really like notion of branching in Git; but be warned about tracking and
> not recording renames, and the need of explicit packing (the latter very
> minor). Powerfull, perhaps too powerfull for newbie user: but that is what
> Cogito is for (although now Git contains fairly large set of high-level
> commands).
We like to move forward.
>
> http://git.or.cz/
> http://git.or.cz/gitwiki
> http://git.or.cz/gitwiki/Git
> and "Other version control software" at
> http://git.or.cz/gitwiki/GitLinks
Yes, been there, thanks though.
> P.S. If you decide to use Git as VCS for your project, consider adding
> entry
> about it on http://git.or.cz/gitwiki/GitProjects wiki page.
Looks like I maybe doing a preliminary Windows Git HOWTO on the GitWiki, if
no one else has trod this ground :) (Might need some proper help testing
though)
Thanks,
Aaron
^ permalink raw reply
* Re: git reset --hard include/linux/config.h
From: Junio C Hamano @ 2006-07-06 2:45 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20060705165801.GA11822@mars.ravnborg.org>
Sam Ravnborg <sam@ravnborg.org> writes:
> Now git reset is maybe supposed to work on commit level only, but it
> would have been nice if it erroroed out when it saw an argument that
> it did not know about. In this case I assume git reset used
> "include/linux/config.h" as <commitish>.
There is an attempt to have that check, but obviously it is
busted. Thanks for noticing.
Maybe something like this is needed instead.
-- >8 --
git-reset: complain and exit upon seeing an unknown parameter.
The check to use "rev-parse --verify" was defeated by the use of
"--default HEAD". "git reset --hard bogus-committish" just
defaulted to reset to the HEAD without complaining.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-reset.sh b/git-reset.sh
index 46451d0..5c02240 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -17,7 +17,11 @@ case "$1" in
usage ;;
esac
-rev=$(git-rev-parse --verify --default HEAD "$@") || exit
+case $# in
+0) rev=HEAD ;;
+1) rev=$(git-rev-parse --verify "$1") || exit ;;
+*) usage ;;
+esac
rev=$(git-rev-parse --verify $rev^0) || exit
# We need to remember the set of paths that _could_ be left
^ permalink raw reply related
* Re: Does Git run on Windows ?
From: Martin Langhoff @ 2006-07-06 2:56 UTC (permalink / raw)
To: Aaron Gray; +Cc: Git Mailing List
In-Reply-To: <01c001c6a0a7$a2783f90$0200a8c0@AMD2500>
On 7/6/06, Aaron Gray <angray@beeb.net> wrote:
> This maybe a stupid question but does Git run on Windows ?
Ask google :-) - try "git cygwin" - or look at the git wiki.
> Are there better options ?
Mercurial is quite similar (though not as fast), and may have an
easier time on Windows. Not 100% sure about that.
> This maybe the crunch and reason to use CVS for now :(?)
If you are only supporting some users on Windows, you may be able to
use git-cvsserver for them. Looks like a cvsserver but it is a GIT
repository ;-)
cheers,
martin
^ permalink raw reply
* Re: [PATCH 2, proof of concept] autoconf: Use %configure in git.spec, autoconf dependency only in rpm target
From: Pavel Roskin @ 2006-07-06 4:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200607041609.36329.jnareb@gmail.com>
Hi Jakub,
On Tue, 2006-07-04 at 16:09 +0200, Jakub Narebski wrote:
> Sidenote 1: current git.spec.in doesn't allow building RPMS from a dirty
> version:
> error: line 3: Illegal char '-' in version: Version: 1.4.1.g1c7c-dirty
> Is it intentional?
I don't know if it's intentional, but it's annoying. The workaround is
to use StGIT and run "stg refresh" before "make rpm".
> +Patch0: git-add-autoconf-configure.patch.gz
I don't think we need patches in git.spec.in. Let's leave it to the
actual distributions. If you have a problem with rpm, please submit the
autoconf support for now and the rest will be cleaned up eventually.
Besides, the "next" branch has different and potentially conflicting
changes to git.spec.in for Git.pm support.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [RFC] GIT user survey
From: Pavel Roskin @ 2006-07-06 5:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8e1ea$s5c$1@sea.gmane.org>
On Tue, 2006-07-04 at 17:28 +0200, Jakub Narebski wrote:
> Paolo Ciarrocchi wrote:
>
> > I was wondering whether it could be a good idea to have a kind of "GIT
> > users survey" when google pointed my eyes to this page:
> > http://www.selenic.com/pipermail/mercurial/2006-April/007513.html
> >
> > So I modified the content of the survey and published a DRAFT here:
> > http://paolo.ciarrocchi.googlepages.com/GITSurvey
>
> Could you please add the final version (and of course results) on
> Git Wiki (http://git.or.cz/gitwiki), like original one is on Mercurial
> wiki: http://www.selenic.com/mercurial/wiki/index.cgi/UserSurvey ?
>
> Thanks in advance
>
> P.S. I wonder why my Mozilla 1.7.12 sees GITSurvey as binary/octet-stream
> instead of text/plain file...
It's not a Mozilla thing. It's a server configuration.
$ wget http://paolo.ciarrocchi.googlepages.com/GITSurvey
--00:52:45-- http://paolo.ciarrocchi.googlepages.com/GITSurvey
=> `GITSurvey'
Resolving paolo.ciarrocchi.googlepages.com... 64.233.179.93,
64.233.179.91
Connecting to paolo.ciarrocchi.googlepages.com|64.233.179.93|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 2,078 (2.0K) [application/octet-stream]
Regarding the questions (sorry, I could have missed comments of others):
What is your preferred language?
Preferred to type or preferred to speak? There answer is not always the
same, at least for me.
How did you hear about GIT?
With my own ears. "How did you learn about GIT" would be better because
many respondents probably _read_ about GIT first.
s/histoty/history
s/porcellains/porcelains/
What is the "history depth"? How do I measure it?
Which porcelains do you use?
Which child did you abuse today? Let's avoid loaded questions. Some
people are just fine with bare git.
Have you tried to get GIT help from other people?
Better: Have you asked other people to help you with GIT?
--
Regards,
Pavel Roskin
^ permalink raw reply
* comparing file contents in is_exact_match?
From: Martin Waitz @ 2006-07-06 5:57 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 708 bytes --]
hoi :)
I created a git repository for my photo collection and then renamed
some photos (about 600). Now git status and commit get hit by
the OOM killer.
The reason for that is that is_exact_match (in diffcore-rename.c) maps
both the source and destination file into memory and then compares them
byte for byte. This is a little bit too much for my little machine.
When I remove the content comparation and only leave the sha1
comparision, then my renames are correctly found in a second. But
unluckily, some other renames in the testcases are not correctly
handled any more.
So is there an easy solution? Why is the content comparision in
is_exact_match needed?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Junio C Hamano @ 2006-07-06 6:20 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060706055729.GA12512@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> The reason for that is that is_exact_match (in diffcore-rename.c) maps
> both the source and destination file into memory and then compares them
> byte for byte. This is a little bit too much for my little machine.
>
> When I remove the content comparation and only leave the sha1
> comparision, then my renames are correctly found in a second. But
> unluckily, some other renames in the testcases are not correctly
> handled any more.
>
> So is there an easy solution? Why is the content comparision in
> is_exact_match needed?
Because your working tree can be out of sync with respect to
what's in the index, in which case we cannot trust the sha1
while running diff-index (without --cached flag).
git-update-index --refresh before doing anything might help.
^ permalink raw reply
* Re: Does Git run on Windows ?
From: Johannes Schindelin @ 2006-07-06 6:34 UTC (permalink / raw)
To: Aaron Gray; +Cc: Git Mailing List
In-Reply-To: <01c001c6a0a7$a2783f90$0200a8c0@AMD2500>
On Thu, 6 Jul 2006, Aaron Gray wrote:
> This maybe a stupid question but does Git run on Windows ?
You do know that there are several list archives?
> Are there better options ?
Than Windows? Yes.
> Its got lots of C code, and Bash scripts, with a couple of Perl scripts.
And you completely forgot Python.
> So should run on Cygwin okay, maybe even MinGW. Anyone tried either ?
Yes, I have tried.
You might be surprised that Cygwin is supported. But then, you could have
seen it in the Makefile.
I also tried to port git to MinGW. This project is stalled a little,
because there is really, really, _really_ much to adapt.
MinGW inherits the problem of Windows being utterly non-POSIX, and that
has to be worked around.
HOWEVER, if you would like to continue where I left off, I'll send you a
repo URL where you can download it.
Ciao,
Dscho
^ permalink raw reply
* [RFC/PATCH] git-svn: migrate out of contrib
From: Eric Wong @ 2006-07-06 7:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <20060704215643.GA31763@localdomain>
Allow NO_SVN_TESTS to be defined to skip git-svn tests. These
tests are time-consuming due to SVN being slow, and even more so
if SVN Perl libraries are not available.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
.gitignore | 1
{contrib/git-svn => Documentation}/git-svn.txt | 0
Makefile | 6 ++-
contrib/git-svn/.gitignore | 4 --
contrib/git-svn/Makefile | 44 --------------------
contrib/git-svn/git-svn.perl => git-svn.perl | 2 -
t/Makefile | 10 +++++
{contrib/git-svn/t => t}/lib-git-svn.sh | 18 ++++----
.../t9100-git-svn-basic.sh | 4 ++
.../t9101-git-svn-props.sh | 0
.../t9102-git-svn-deep-rmdir.sh | 0
.../t9103-git-svn-graft-branches.sh | 0
.../t9104-git-svn-follow-parent.sh | 0
.../t9105-git-svn-commit-diff.sh | 0
14 files changed, 28 insertions(+), 61 deletions(-)
diff --git a/.gitignore b/.gitignore
index 7b954d5..9b69a0f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -106,6 +106,7 @@ git-ssh-push
git-ssh-upload
git-status
git-stripspace
+git-svn
git-svnimport
git-symbolic-ref
git-tag
diff --git a/contrib/git-svn/git-svn.txt b/Documentation/git-svn.txt
similarity index 100%
rename from contrib/git-svn/git-svn.txt
rename to Documentation/git-svn.txt
diff --git a/Makefile b/Makefile
index 7fa4a27..2f4dfb8 100644
--- a/Makefile
+++ b/Makefile
@@ -33,6 +33,10 @@ #
# Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link.
# Enable it on Windows. By default, symrefs are still used.
#
+# Define NO_SVN_TESTS if you want to skip time-consuming SVN interopability
+# tests. These tests take up a significant amount of the total test time
+# but are not needed unless you plan to talk to SVN repos.
+#
# Define PPC_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine optimized for PowerPC.
#
@@ -134,7 +138,7 @@ SCRIPT_PERL = \
git-shortlog.perl git-rerere.perl \
git-annotate.perl git-cvsserver.perl \
git-svnimport.perl git-mv.perl git-cvsexportcommit.perl \
- git-send-email.perl
+ git-send-email.perl git-svn.perl
SCRIPT_PYTHON = \
git-merge-recursive.py
diff --git a/contrib/git-svn/.gitignore b/contrib/git-svn/.gitignore
deleted file mode 100644
index d8d87e3..0000000
--- a/contrib/git-svn/.gitignore
+++ /dev/null
@@ -1,4 +0,0 @@
-git-svn
-git-svn.xml
-git-svn.html
-git-svn.1
diff --git a/contrib/git-svn/Makefile b/contrib/git-svn/Makefile
deleted file mode 100644
index 7c20946..0000000
--- a/contrib/git-svn/Makefile
+++ /dev/null
@@ -1,44 +0,0 @@
-all: git-svn
-
-prefix?=$(HOME)
-bindir=$(prefix)/bin
-mandir=$(prefix)/man
-man1=$(mandir)/man1
-INSTALL?=install
-doc_conf=../../Documentation/asciidoc.conf
--include ../../config.mak
-
-git-svn: git-svn.perl
- cp $< $@
- chmod +x $@
-
-install: all
- $(INSTALL) -d -m755 $(DESTDIR)$(bindir)
- $(INSTALL) git-svn $(DESTDIR)$(bindir)
-
-install-doc: doc
- $(INSTALL) git-svn.1 $(DESTDIR)$(man1)
-
-doc: git-svn.1
-git-svn.1 : git-svn.xml
- xmlto man git-svn.xml
-git-svn.xml : git-svn.txt
- asciidoc -b docbook -d manpage \
- -f ../../Documentation/asciidoc.conf $<
-git-svn.html : git-svn.txt
- asciidoc -b xhtml11 -d manpage \
- -f ../../Documentation/asciidoc.conf $<
-test: git-svn
- cd t && for i in t????-*.sh; do $(SHELL) ./$$i $(TEST_FLAGS); done
-
-# we can test NO_OPTIMIZE_COMMITS independently of LC_ALL
-full-test:
- $(MAKE) test GIT_SVN_NO_LIB=1 GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C
- $(MAKE) test GIT_SVN_NO_LIB=0 GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C
- $(MAKE) test GIT_SVN_NO_LIB=1 GIT_SVN_NO_OPTIMIZE_COMMITS=0 \
- LC_ALL=en_US.UTF-8
- $(MAKE) test GIT_SVN_NO_LIB=0 GIT_SVN_NO_OPTIMIZE_COMMITS=0 \
- LC_ALL=en_US.UTF-8
-
-clean:
- rm -f git-svn *.xml *.html *.1
diff --git a/contrib/git-svn/git-svn.perl b/git-svn.perl
similarity index 100%
rename from contrib/git-svn/git-svn.perl
rename to git-svn.perl
index 8bc4188..145eaa8 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/git-svn.perl
@@ -8,7 +8,7 @@ use vars qw/ $AUTHOR $VERSION
$GIT_SVN_INDEX $GIT_SVN
$GIT_DIR $GIT_SVN_DIR $REVDB/;
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
-$VERSION = '1.1.1-broken';
+$VERSION = '@@GIT_VERSION@@';
use Cwd qw/abs_path/;
$GIT_DIR = abs_path($ENV{GIT_DIR} || '.git');
diff --git a/t/Makefile b/t/Makefile
index 632c55f..8983509 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -11,6 +11,7 @@ # Shell quote;
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)
+TSVN = $(wildcard t91[0-9][0-9]-*.sh)
ifdef NO_PYTHON
GIT_TEST_OPTS += --no-python
@@ -24,6 +25,15 @@ all: $(T) clean
clean:
rm -fr trash
+# we can test NO_OPTIMIZE_COMMITS independently of LC_ALL
+full-svn-test:
+ $(MAKE) $(TSVN) GIT_SVN_NO_LIB=1 GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C
+ $(MAKE) $(TSVN) GIT_SVN_NO_LIB=0 GIT_SVN_NO_OPTIMIZE_COMMITS=1 LC_ALL=C
+ $(MAKE) $(TSVN) GIT_SVN_NO_LIB=1 GIT_SVN_NO_OPTIMIZE_COMMITS=0 \
+ LC_ALL=en_US.UTF-8
+ $(MAKE) $(TSVN) GIT_SVN_NO_LIB=0 GIT_SVN_NO_OPTIMIZE_COMMITS=0 \
+ LC_ALL=en_US.UTF-8
+
.PHONY: $(T) clean
.NOTPARALLEL:
diff --git a/contrib/git-svn/t/lib-git-svn.sh b/t/lib-git-svn.sh
similarity index 65%
rename from contrib/git-svn/t/lib-git-svn.sh
rename to t/lib-git-svn.sh
index d7f972a..450fee8 100644
--- a/contrib/git-svn/t/lib-git-svn.sh
+++ b/t/lib-git-svn.sh
@@ -1,14 +1,12 @@
-PATH=$PWD/../:$PATH
-if test -d ../../../t
+. ./test-lib.sh
+
+if test -n "$NO_SVN_TESTS"
then
- cd ../../../t
-else
- echo "Must be run in contrib/git-svn/t" >&2
- exit 1
+ test_expect_success 'skipping git-svn tests, NO_SVN_TESTS defined' :
+ test_done
+ exit
fi
-. ./test-lib.sh
-
GIT_DIR=$PWD/.git
GIT_SVN_DIR=$GIT_DIR/svn/git-svn
SVN_TREE=$GIT_SVN_DIR/svn-tree
@@ -16,7 +14,7 @@ SVN_TREE=$GIT_SVN_DIR/svn-tree
svnadmin >/dev/null 2>&1
if test $? != 1
then
- test_expect_success 'skipping contrib/git-svn test' :
+ test_expect_success 'skipping git-svn tests, svnadmin not found' :
test_done
exit
fi
@@ -24,7 +22,7 @@ fi
svn >/dev/null 2>&1
if test $? != 1
then
- test_expect_success 'skipping contrib/git-svn test' :
+ test_expect_success 'skipping git-svn tests, svn not found' :
test_done
exit
fi
diff --git a/contrib/git-svn/t/t0000-contrib-git-svn.sh b/t/t9100-git-svn-basic.sh
old mode 100644
new mode 100755
similarity index 98%
rename from contrib/git-svn/t/t0000-contrib-git-svn.sh
rename to t/t9100-git-svn-basic.sh
index b482bb6..bf1d638
--- a/contrib/git-svn/t/t0000-contrib-git-svn.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -3,7 +3,7 @@ #
# Copyright (c) 2006 Eric Wong
#
-test_description='git-svn tests'
+test_description='git-svn basic tests'
GIT_SVN_LC_ALL=$LC_ALL
case "$LC_ALL" in
@@ -17,6 +17,8 @@ esac
. ./lib-git-svn.sh
+echo 'define NO_SVN_TESTS to skip git-svn tests'
+
mkdir import
cd import
diff --git a/contrib/git-svn/t/t0001-contrib-git-svn-props.sh b/t/t9101-git-svn-props.sh
old mode 100644
new mode 100755
similarity index 100%
rename from contrib/git-svn/t/t0001-contrib-git-svn-props.sh
rename to t/t9101-git-svn-props.sh
diff --git a/contrib/git-svn/t/t0002-deep-rmdir.sh b/t/t9102-git-svn-deep-rmdir.sh
old mode 100644
new mode 100755
similarity index 100%
rename from contrib/git-svn/t/t0002-deep-rmdir.sh
rename to t/t9102-git-svn-deep-rmdir.sh
diff --git a/contrib/git-svn/t/t0003-graft-branches.sh b/t/t9103-git-svn-graft-branches.sh
old mode 100644
new mode 100755
similarity index 100%
rename from contrib/git-svn/t/t0003-graft-branches.sh
rename to t/t9103-git-svn-graft-branches.sh
diff --git a/contrib/git-svn/t/t0004-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
old mode 100644
new mode 100755
similarity index 100%
rename from contrib/git-svn/t/t0004-follow-parent.sh
rename to t/t9104-git-svn-follow-parent.sh
diff --git a/contrib/git-svn/t/t0005-commit-diff.sh b/t/t9105-git-svn-commit-diff.sh
old mode 100644
new mode 100755
similarity index 100%
rename from contrib/git-svn/t/t0005-commit-diff.sh
rename to t/t9105-git-svn-commit-diff.sh
--
1.4.1.ge255
^ permalink raw reply related
* Re: comparing file contents in is_exact_match?
From: Martin Waitz @ 2006-07-06 7:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5cj9rvm.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 706 bytes --]
hoi :)
On Wed, Jul 05, 2006 at 11:20:13PM -0700, Junio C Hamano wrote:
> Martin Waitz <tali@admingilde.org> writes:
> > Why is the content comparision in is_exact_match needed?
>
> Because your working tree can be out of sync with respect to
> what's in the index, in which case we cannot trust the sha1
> while running diff-index (without --cached flag).
so perhaps we need three phases instead of two:
first sort out all renames that can be detected by the sha1,
then compare file contents and finally do the diff.
> git-update-index --refresh before doing anything might help.
At the moment it is doing (N-1)^2 content compares, even if
the index is in sync.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Junio C Hamano @ 2006-07-06 7:33 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060706071629.GB12512@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
>> Because your working tree can be out of sync with respect to
>> what's in the index, in which case we cannot trust the sha1
>> while running diff-index (without --cached flag).
>
> so perhaps we need three phases instead of two:
> first sort out all renames that can be detected by the sha1,
> then compare file contents and finally do the diff.
Makes sort-of sense.
Although I am not sure how much this would help with a regular
workload, maybe something like this untested patch might help
your situation?
-- >8 --
diffcore-rename: try matching up renames without populating filespec first
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/diffcore-rename.c b/diffcore-rename.c
index d57e865..affff7a 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -96,11 +96,15 @@ static struct diff_rename_src *register_
return &(rename_src[first]);
}
-static int is_exact_match(struct diff_filespec *src, struct diff_filespec *dst)
+static int is_exact_match(struct diff_filespec *src,
+ struct diff_filespec *dst,
+ int contents_too)
{
if (src->sha1_valid && dst->sha1_valid &&
!memcmp(src->sha1, dst->sha1, 20))
return 1;
+ if (!contents_too)
+ return 0;
if (diff_populate_filespec(src, 1) || diff_populate_filespec(dst, 1))
return 0;
if (src->size != dst->size)
@@ -242,7 +246,7 @@ void diffcore_rename(struct diff_options
struct diff_queue_struct *q = &diff_queued_diff;
struct diff_queue_struct outq;
struct diff_score *mx;
- int i, j, rename_count;
+ int i, j, rename_count, contents_too;
int num_create, num_src, dst_cnt;
if (!minimum_score)
@@ -273,16 +277,23 @@ void diffcore_rename(struct diff_options
/* We really want to cull the candidates list early
* with cheap tests in order to avoid doing deltas.
+ * The first round matches up the up-to-date entries,
+ * and then during the second round we try to match
+ * cache-dirty entries as well.
*/
- for (i = 0; i < rename_dst_nr; i++) {
- struct diff_filespec *two = rename_dst[i].two;
- for (j = 0; j < rename_src_nr; j++) {
- struct diff_filespec *one = rename_src[j].one;
- if (!is_exact_match(one, two))
- continue;
- record_rename_pair(i, j, MAX_SCORE);
- rename_count++;
- break; /* we are done with this entry */
+ for (contents_too = 0; contents_too < 2; contents_too++) {
+ for (i = 0; i < rename_dst_nr; i++) {
+ struct diff_filespec *two = rename_dst[i].two;
+ if (rename_dst[i].pair)
+ continue; /* dealt with an earlier round */
+ for (j = 0; j < rename_src_nr; j++) {
+ struct diff_filespec *one = rename_src[j].one;
+ if (!is_exact_match(one, two, contents_too))
+ continue;
+ record_rename_pair(i, j, MAX_SCORE);
+ rename_count++;
+ break; /* we are done with this entry */
+ }
}
}
^ 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