* [PATCH Cogito] Fix t/t9300-seek.sh
From: Fernando J. Pereda @ 2005-11-12 22:39 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 932 bytes --]
After 'seeking' to the first commit, identical should have 'identical'
instead of 'nonconflicting'.
Signed-off-by: Fernando J. Pereda <ferdy@gentoo.org>
---
t/t9300-seek.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
applies-to: 25610e0bf9968dc98709a8ca271db70806c2dbac
8c1240eaa91f1f805535287e7a6a037c341453b4
diff --git a/t/t9300-seek.sh b/t/t9300-seek.sh
index d3fed11..55a3f19 100755
--- a/t/t9300-seek.sh
+++ b/t/t9300-seek.sh
@@ -82,8 +82,8 @@ test_expect_success 'current commit shou
# "[ -e newdir/newfile ] && [ -e newdir/newfile.rej ]"
test_expect_success 'different should be v1' \
"[ $(cat different) = v1 ]"
-test_expect_success 'identical should be nonconflicting' \
- "[ $(cat identical) = nonconflicting ]"
+test_expect_success 'identical should be identical' \
+ "[ $(cat identical) = identical ]"
test_expect_success 'unseeking' \
"cg-seek"
---
0.99.9g
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH Cogito] Fix t/t9300-seek.sh
From: Petr Baudis @ 2005-11-12 22:47 UTC (permalink / raw)
To: git
In-Reply-To: <20051112223914.GA1150@ferdyx.org>
Dear diary, on Sat, Nov 12, 2005 at 11:39:14PM CET, I got a letter
where "Fernando J. Pereda" <ferdy@ferdyx.org> said that...
> After 'seeking' to the first commit, identical should have 'identical'
> instead of 'nonconflicting'.
Nope, since we locally change it to "nonconflicting", and cg-seek is
supposed to keep local changes.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH Cogito] Fix t/t9300-seek.sh
From: Fernando J. Pereda @ 2005-11-12 22:55 UTC (permalink / raw)
To: git
In-Reply-To: <20051112224743.GJ30496@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]
On Sat, Nov 12, 2005 at 11:47:43PM +0100, Petr Baudis wrote:
| Dear diary, on Sat, Nov 12, 2005 at 11:39:14PM CET, I got a letter
| where "Fernando J. Pereda" <ferdy@ferdyx.org> said that...
| > After 'seeking' to the first commit, identical should have 'identical'
| > instead of 'nonconflicting'.
|
| Nope, since we locally change it to "nonconflicting", and cg-seek is
| supposed to keep local changes.
Ouch... I failed to see that. Then that test is failing for me,
'identical' actually contains 'identical'. I used cogito-0.16rc1 is it
suposed to work? Or is it known to be broken?
Cheers,
Ferdy
--
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH Cogito] Fix t/t9300-seek.sh
From: Fernando J. Pereda @ 2005-11-12 23:01 UTC (permalink / raw)
To: git
In-Reply-To: <20051112225525.GA13674@ferdyx.org>
[-- Attachment #1: Type: text/plain, Size: 937 bytes --]
On Sat, Nov 12, 2005 at 11:55:25PM +0100, Fernando J. Pereda wrote:
| On Sat, Nov 12, 2005 at 11:47:43PM +0100, Petr Baudis wrote:
| | Dear diary, on Sat, Nov 12, 2005 at 11:39:14PM CET, I got a letter
| | where "Fernando J. Pereda" <ferdy@ferdyx.org> said that...
| | > After 'seeking' to the first commit, identical should have 'identical'
| | > instead of 'nonconflicting'.
| |
| | Nope, since we locally change it to "nonconflicting", and cg-seek is
| | supposed to keep local changes.
|
| Ouch... I failed to see that. Then that test is failing for me,
| 'identical' actually contains 'identical'. I used cogito-0.16rc1 is it
| suposed to work? Or is it known to be broken?
Actually don't mind me. It justs fails under the Gentoo sandbox. Sorry
for the noise.
Cheers,
Ferdy
--
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: http protocol, cloning git.git, fails (too many open files)
From: Junio C Hamano @ 2005-11-12 23:21 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86acg9ijwa.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> $ mkdir foo
> $ cd foo
> $ cg-clone http://www.kernel.org/pub/scm/git/git.git git.new
> Fetching head...
> Fetching objects...
> progress: 1 objects, 191 bytes
> progress: 2 objects, 519 bytes
> progress: 3 objects, 5851 bytes
> progress: 4 objects, 7671 bytes
>...
>
> progress: 66 objects, 187452 bytes
>
> And at this point, it hung. I had to ^C.
This sounds like the problem the patch Pasky posted last night
addresses.
However, one thing puzzles me. I just tried to reproduce it by
doing this:
$ rm -fr git-http
$ ulimit -n 16
$ git clone http://www.kernel.org/pub/scm/git/git.git git-http
and it did not fail on my Linux box. This is from the tip of
the master tree (essentially the same as 0.99.9h aka 1.0rc1),
built without Pasky's patch. Maybe the number of in-transit
requests in your case is much higher with your connection while
waiting for a packfile to arrive than my setup.
Could you please try with the patch Nick posted (which covers
less) and then with Pasky's patch?
^ permalink raw reply
* Re: cg-admin-setuprepo fails to make a cg-clone'able repo
From: Petr Baudis @ 2005-11-13 0:29 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Git Mailing List
In-Reply-To: <8664qxn71k.fsf@blue.stonehenge.com>
Dear diary, on Sat, Nov 12, 2005 at 05:51:35PM CET, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> >>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:
>
> Petr> But this is actually an entirely unrelated bug, it seems - pretty
> Petr> strange. I revived another few months old thread because of this, since
> Petr> it seems the 'b' was actually a typo and we don't want to pass 'cp' this
> Petr> argument at all, but something different. Does cloning locally otherwise
> Petr> work?
>
> When I tried "local cloning", I first tried to make an empty archive
> with cgi-init, but it dumped me into an editor. I couldn't find a
> switch to turn that off. Perhaps the manpage should say "you'll
> be dumped in to an editor",
Well, that's pretty obvious after the first try. ;-)
> and perhaps provide a way to pass that message with "-m".
Good idea. Added.
> So, on a whim, I realize that it's performing an initial commit,
It says that right in the editor, after all. :-)
> so I try cg-init -I.
>
> And here's the result:
>
> localhost:~/Projects/Git % cg-init -I my_master
> defaulting to local storage area
> localhost:~/Projects/Git % cg-clone my_master my_slave
> defaulting to local storage area
> find: /Users/merlyn/Projects/Git/my_master: No such file or directory
> Hard links don't work - using copy
> Fetching head...
> cp: illegal option -- b
> usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src target
> cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src1 ... srcN directory
> cg-fetch: unable to get the HEAD branch
> cg-clone: fetch failed
>
> So, I guess your answer is no. What is "-b" for cp. That's not
> on my manpage.
It's something totally weird "backup" thing. A bug in Cogito, what we
_want_ is to have cp dereferencing its symlink. I replaced it with -L
now. Could you try the latest version from git or -rc2 (coming out in
few minutes), please?
> And, after reading the manpage closer, I see my first "my_master"
> was created wrong. But no error message. :(
Good catch. Fixed.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* [ANNOUNCE] Cogito-0.16rc2
From: Petr Baudis @ 2005-11-13 1:02 UTC (permalink / raw)
To: git
Hello,
I'm announcing the release of Cogito version 0.16rc2, the human-friendly
version control UI for Linus' GIT tool. Share and enjoy at:
http://www.kernel.org/pub/software/scm/cogito/
Compared to rc1, this carries few bugfixes, a minor feature or two,
some small documentation updates, extended testsuites etc.
The new stuff includes:
* Curl is used instead of wget for HTTP heads fetching
* Handle multiple merge bases (leaving the decision on the user)
* cg-init -m'msg' support
* Fix a long-standing bug with some stale files not being removed
during large fast-forwards
* Non-symlink HEADs are now fetched from properly
* cg-commit -f now really works
* Local fetching should work even without GNU cp now
* Some fetch progressbar fixes
* Few tiny improvements
* Several new tests
* Small documentation updates
If I will get no more bugreports during the next few days, this will
become 0.16 final.
Happy hacking,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Balanced packing strategy
From: Junio C Hamano @ 2005-11-13 2:34 UTC (permalink / raw)
To: Craig Schlenter; +Cc: git
In-Reply-To: <b6abcb70496730705046934973221b93@codefountain.com>
Craig Schlenter <craig@codefountain.com> writes:
> Does the pack index file contain enough information to enable a client
> to send http byte range requests to grab individual objects from a pack?
> It does seem to store object offsets...
Yes, it is certainly doable; there is enough information. I am
not sure if it is worth the complexity, though.
Many objects are stored delitified, so your byte range requests
would return delta and base object name. After you read what
was returned and find out the base object name, you would need
to get it, which can be another delta against its base object.
This would make tangling a delta chain would become a serialized
sequence of requests.
^ permalink raw reply
* Re: Remove unneeded packs
From: Junio C Hamano @ 2005-11-13 2:38 UTC (permalink / raw)
To: Lukas =?iso-2022-jp-2?B?U2FuZHN0chsuQRtOdm0=?=; +Cc: git
In-Reply-To: <43766687.2000007@etek.chalmers.se>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 558 bytes --]
Lukas Sandstr^[.A^[Nvm <lukass@etek.chalmers.se> writes:
> This is most likley because the pack b3c6... contains unreachable objects.
> git-pack-redundant only makes sure that all objects present in packfiles
> still are present in packfiles after the redundant packs have been removed.
> ...
> I'm thinking of the possibility passing a list of objects to be ignored
> on stdin to git-pack-redundant. This would hopefully solve this problem.
But once you go down that path, wouldn't doing 'repack -a -d'
become looking simpler and more attractive, I wonder?
^ permalink raw reply
* Re: [PATCH] Building git on NetBSD
From: Junio C Hamano @ 2005-11-13 2:41 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43760AF5.1010704@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Yes it should. Currently the git makefile doesn't distinguish between
> CFLAGS and LDFLAGS which results in a fair few warnings.
Very well. Maybe LDFLAGS and ALL_LDFLAGS pair to parallel
CFLAGS and ALL_CFLAGS (the former is for the end user to
override from make command line, the latter is for Makefile to
augment and use)?
^ permalink raw reply
* [PATCH 1/2] Add expat and expat-devel dependencies (for http-push) to RPM spec.
From: Thomas Matysik @ 2005-11-13 4:56 UTC (permalink / raw)
To: git
Signed-off-by: Thomas Matysik <thomas@matysik.co.nz>
---
git-core.spec.in | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
applies-to: 76d3d1c302c20b82fd976e958aabd19f7f01e7b5
b33499b703fbeac7e055a50a7f250ed71a516517
diff --git a/git-core.spec.in b/git-core.spec.in
index cf7e942..91f8677 100644
--- a/git-core.spec.in
+++ b/git-core.spec.in
@@ -7,9 +7,9 @@ License: GPL
Group: Development/Tools
URL: http://kernel.org/pub/software/scm/git/
Source: http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
-BuildRequires: zlib-devel >= 1.2, openssl-devel, curl-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
+BuildRequires: zlib-devel >= 1.2, openssl-devel, curl-devel, expat-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: zlib >= 1.2, rsync, rcs, curl, less, openssh-clients, python >= 2.3, tk >= 8.4
+Requires: zlib >= 1.2, rsync, rcs, curl, less, openssh-clients, python >= 2.3, tk >= 8.4, expat
%description
This is a stupid (but extremely fast) directory content manager. It
---
0.99.9g
^ permalink raw reply related
* [PATCH 2/2] Split gitk into seperate RPM package
From: Thomas Matysik @ 2005-11-13 4:58 UTC (permalink / raw)
To: git
I don't want to have to install x11-libs and all it's dependencies on my headless machines, so this patch splits gitk out of the RPM.
The .deb already appears to have gitk split out.
Signed-off-by: Thomas Matysik <thomas@matysik.co.nz>
---
git-core.spec.in | 20 +++++++++++++++++---
1 files changed, 17 insertions(+), 3 deletions(-)
applies-to: 69a4acd3853a9d7fb26bc3620c9fb3079b2b5494
57d0a6cf0343ae19581dc2c89821605077a4035d
diff --git a/git-core.spec.in b/git-core.spec.in
index 91f8677..54a6815 100644
--- a/git-core.spec.in
+++ b/git-core.spec.in
@@ -9,7 +9,7 @@ URL: http://kernel.org/pub/software/sc
Source: http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
BuildRequires: zlib-devel >= 1.2, openssl-devel, curl-devel, expat-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: zlib >= 1.2, rsync, rcs, curl, less, openssh-clients, python >= 2.3, tk >= 8.4, expat
+Requires: zlib >= 1.2, rsync, rcs, curl, less, openssh-clients, python >= 2.3, expat
%description
This is a stupid (but extremely fast) directory content manager. It
@@ -47,6 +47,13 @@ Requires: git-core = %{version}-%{releas
%description email
Git tools for sending email.
+%package tk
+Summary: Git revision tree visualiser ('gitk')
+Group: Development/Tools
+Requires: git-core = %{version}-%{release}, tk >= 8.4
+%description tk
+Git revision tree visualiser ('gitk')
+
%prep
%setup -q
@@ -60,9 +67,9 @@ make %{_smp_mflags} DESTDIR=$RPM_BUILD_R
prefix=%{_prefix} mandir=%{_mandir} \
install %{!?_without_docs: install-doc}
-(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "arch|svn|cvs|email" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
+(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "arch|svn|cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
%if %{!?_without_docs:1}0
-(find $RPM_BUILD_ROOT%{_mandir} $RPM_BUILD_ROOT/Documentation -type f | grep -vE "arch|svn|git-cvs|email" | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-doc-files
+(find $RPM_BUILD_ROOT%{_mandir} $RPM_BUILD_ROOT/Documentation -type f | grep -vE "arch|svn|git-cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-doc-files
%endif
%clean
@@ -96,6 +103,13 @@ rm -rf $RPM_BUILD_ROOT
%{!?_without_docs: %{_mandir}/man1/*email*.1*}
%{!?_without_docs: %doc Documentation/*email*.html }
+%files tk
+%defattr(-,root,root)
+%doc Documentation/*gitk*.txt
+%{_bindir}/*gitk*
+%{!?_without_docs: %{_mandir}/man1/*gitk*.1*}
+%{!?_without_docs: %doc Documentation/*gitk*.html }
+
%files -f bin-man-doc-files
%defattr(-,root,root)
%{_datadir}/git-core/
---
0.99.9g
^ permalink raw reply related
* Re: GIT character codecs
From: Marco Costalba @ 2005-11-13 8:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano wrote:
>Marco Costalba <mcostalba@yahoo.it> writes:
>
>>I modified qgit to force the use of utf-8 codec instead of the local one,
>>in my case ISO-8859-15.
>
>
>I suspect that trying to have a globa single encoding is a wrong
>approach overall. There are a handful issues to think about.
>
I agree.
>First the easiest one -- the commit log messages. We encourage
>use of UTF-8,
>
> [cut]
>
>But we do not _enforce_ UTF-8.
>
>What this means for qgit is that it is often sufficient for its
>log browser to support one encoding at a time, provided if it
>allows the user to switch which encoding to use depending on
>what project is being viewed.
>
>
> [cut]
>
>
>But other projects may use different
>encodings, and even a single project can have its i18n message
>files in different encodings and charsets in different files.
>Users probably want to be able to view all of them, even if they
>only understand a couple of languages and not others.
>
>What this means for qgit is that at least you should be able to
>show a whole file in a single encoding, but if you show more
>than two files at the same time, one in each window, these
>windows may be showing its contents in different encodings and
>charsets. So you would need to give a way to your users to tell
>you what encoding each file is in. Using global locale as the
>default and having a way to override that per file basis would
>be sufficient.
>
If encoding is a per-blob _and_ per-log message property a real solution, although cumbersone,
could be that git stores encoding togheter with the blob and the commits.
The interfaces to read out encoded info could be something like
git-rev-list --pretty --encoding
git-ls-files -e
for commits and blobs respectively.
This avoids all user settings. More, the user could do not know the encoding, as
example when browsing a public repo.
But I understand is too late for something like this. So what qgit can do is
to show a setting with a list of all supported encodings from the user to choose from.
But this is also a problem because, first we should have _two_ settings, one from log
messages and one from blobs _and_ also in this case we miss the problem of different
blobs with different encoding.
A practical workaround, *that do not catches all cases at all* could be qgit has only one global
setting (defaulting to local codec) and applies that setting blindly to everything, from commits
to blobs, the user changes that setting and refreshes the view until he finds the correct one.
But I'm a bit reclutant to add this 'codec list' stuff because, as said, is *not* the real
solution.
Marco
__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: [PATCH] Building git on NetBSD
From: Junio C Hamano @ 2005-11-13 9:44 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <7vhdahclr5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Andreas Ericsson <ae@op5.se> writes:
>
>> Yes it should. Currently the git makefile doesn't distinguish between
>> CFLAGS and LDFLAGS which results in a fair few warnings.
>
> Very well. Maybe LDFLAGS and ALL_LDFLAGS pair to parallel
> CFLAGS and ALL_CFLAGS (the former is for the end user to
> override from make command line, the latter is for Makefile to
> augment and use)?
Does this look OK?
-- >8 -- cut here -- >8 --
diff --git a/Makefile b/Makefile
index b75cb13..7713c05 100644
--- a/Makefile
+++ b/Makefile
@@ -52,10 +52,12 @@
GIT_VERSION = 0.99.9.GIT
-# CFLAGS is for the users to override from the command line.
+# CFLAGS and LDFLAGS are for the users to override from the command line.
CFLAGS = -g -O2 -Wall
+LDFLAGS =
ALL_CFLAGS = $(CFLAGS)
+ALL_LDFLAGS = $(LDFLAGS)
prefix = $(HOME)
bindir = $(prefix)/bin
@@ -187,9 +189,11 @@ ifeq ($(uname_S),Darwin)
NEEDS_SSL_WITH_CRYPTO = YesPlease
NEEDS_LIBICONV = YesPlease
## fink
- ALL_CFLAGS += -I/sw/include -L/sw/lib
+ ALL_CFLAGS += -I/sw/include
+ ALL_LDFLAGS += -L/sw/lib
## darwinports
- ALL_CFLAGS += -I/opt/local/include -L/opt/local/lib
+ ALL_CFLAGS += -I/opt/local/include
+ ALL_LDFLAGS += -L/opt/local/lib
endif
ifeq ($(uname_S),SunOS)
NEEDS_SOCKET = YesPlease
@@ -211,7 +215,13 @@ endif
ifeq ($(uname_S),OpenBSD)
NO_STRCASESTR = YesPlease
NEEDS_LIBICONV = YesPlease
- ALL_CFLAGS += -I/usr/local/include -L/usr/local/lib
+ ALL_CFLAGS += -I/usr/local/include
+ ALL_LDFLAGS += -L/usr/local/lib
+endif
+ifeq ($(uname_S),NetBSD)
+ NEEDS_LIBICONV = YesPlease
+ ALL_CFLAGS += -I/usr/pkg/include
+ ALL_LDFLAGS += -L/usr/pkg/lib -Wl,-rpath,/usr/pkg/lib
endif
ifneq (,$(findstring arm,$(uname_M)))
ARM_SHA1 = YesPlease
@@ -221,7 +231,7 @@ endif
ifndef NO_CURL
ifdef CURLDIR
- # This is still problematic -- gcc does not want -R.
+ # This is still problematic -- gcc does not always want -R.
ALL_CFLAGS += -I$(CURLDIR)/include
CURL_LIBCURL = -L$(CURLDIR)/lib -R$(CURLDIR)/lib -lcurl
else
@@ -369,12 +379,13 @@ git-cherry-pick: git-revert
$(CC) -o $*.o -c $(ALL_CFLAGS) $<
git-%$X: %.o $(LIB_FILE)
- $(CC) $(ALL_CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)
+ $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
git-mailinfo$X : SIMPLE_LIB += $(LIB_4_ICONV)
$(SIMPLE_PROGRAMS) : $(LIB_FILE)
$(SIMPLE_PROGRAMS) : git-%$X : %.o
- $(CC) $(ALL_CFLAGS) -o $@ $(filter %.o,$^) $(LIB_FILE) $(SIMPLE_LIB)
+ $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(LIB_FILE) $(SIMPLE_LIB)
git-http-fetch$X: fetch.o
git-local-fetch$X: fetch.o
@@ -408,10 +419,10 @@ test: all
$(MAKE) -C t/ all
test-date$X: test-date.c date.o ctype.o
- $(CC) $(ALL_CFLAGS) -o $@ test-date.c date.o ctype.o
+ $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) test-date.c date.o ctype.o
test-delta$X: test-delta.c diff-delta.o patch-delta.o
- $(CC) $(ALL_CFLAGS) -o $@ $^
+ $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $^
check:
for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i; done
^ permalink raw reply related
* Re: GIT character codecs
From: Junio C Hamano @ 2005-11-13 10:21 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20051113081443.38296.qmail@web26309.mail.ukl.yahoo.com>
Marco Costalba <mcostalba@yahoo.it> writes:
> But I'm a bit reclutant to add this 'codec list' stuff
> because, as said, is *not* the real solution.
Why isn't it real? UNIX files do not declare what encoding they
are in, and people get their work done with existing viewing or
editing tools (e.g. vi, less, emacs, firefox [*1*], ...). How
is your situation any different?
I suspect you could just take the default from LANG and LC_CTYPE
to cover 98% of the cases, and to cover the rest 2% the
problematic cases have a per-window override menu. If you first
implement only the locale support without per-window override
and tell your users to set these environment variables to
iso-8859-15 when running qgit on your Italian project repository
(or use utf-8 on git.git), wouldn't that be sufficient for most
everyday uses?
[Footnotes]
*1* Ok, firefox is a bit different because they can read charset
attribute from content type, but even so they have a manual
override from View->CharEncoding menu to let their users cope
with broken pages.
^ permalink raw reply
* Re: Remove unneeded packs
From: Lukas Sandström @ 2005-11-13 10:58 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Lukas Sandström
In-Reply-To: <7voe4pclwm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Lukas Sandström <lukass@etek.chalmers.se> writes:
>>This is most likley because the pack b3c6... contains unreachable objects.
>>git-pack-redundant only makes sure that all objects present in packfiles
>>still are present in packfiles after the redundant packs have been removed.
>>...
>>I'm thinking of the possibility passing a list of objects to be ignored
>>on stdin to git-pack-redundant. This would hopefully solve this problem.
>
>
> But once you go down that path, wouldn't doing 'repack -a -d'
> become looking simpler and more attractive, I wonder?
>
>
It depends on how expensive git-fsck-objects --full --unreacahble is versus
a full repack.
Howerver, if I read the source correctly git-fsck-objects doesn't currently test
the reachablility of packed objects. This would have to change, and I'm not certain
of how to do that properly.
Note that the following patch is reqired if git-repack -a -d is to work as expected.
(Remove all packs except the new one)
Btw, I'm sending this patch in utf8, let's see if it works...
----
Subject: [PATCH] Make sure all old packfiles are removed when doing a full repack
This is nessecary because unrachable objects in packfiles makes git-pack-redundant
flag them as non-redundant.
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
git-repack.sh | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
applies-to: 9a0f0c748316751fbf593a21f2b16bcdd975095a
08df1f641bd3f98a607a8413d647667adc18a633
diff --git a/git-repack.sh b/git-repack.sh
index f347207..293bb50 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -32,6 +32,8 @@ case ",$all_into_one," in
rev_list=
rev_parse='--all'
pack_objects=
+ existing=`cd "$PACKDIR" && \
+ find . -type f \( -name '*.pack' -o -name '*.idx' \) -print`
;;
esac
if [ "$local" ]; then
@@ -60,7 +62,19 @@ mv .tmp-pack-$name.pack "$PACKDIR/pack-$
mv .tmp-pack-$name.idx "$PACKDIR/pack-$name.idx" ||
exit
-if test "$remove_redandant" = t
+if test "$all_into_one" = t
+then
+ sync
+ ( cd "$PACKDIR" &&
+ for e in $existing
+ do
+ case "$e" in
+ ./pack-$name.pack | ./pack-$name.idx) ;;
+ *) rm -f $e ;;
+ esac
+ done
+ )
+else if test "$remove_redandant" = t
then
sync
redundant=$(git-pack-redundant --all)
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] GIT commit statistics.
From: Junio C Hamano @ 2005-11-13 10:59 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90511120419v70166c60t93d58b7544e03e3b@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> Similarly, when dealing with an upstream, my tree gets slowly out of
> sync and slightly messy. Eventually I get a new checkout, and rebase
> any pending patches with git-format-patch and git-am.
The key is not to let your tree go "slowly" out of sync, from my
experience. When Linus was the maintainer, I used to do the
equivalent of the following all the time to keep up with his
tree while keeping my history clean [*1*].
Frequently [*2*], I tried to see if Linus made something new and
interesting. My "origin" branch was always copy of Linus head.
$ git fetch origin
The command would say "Fast forward". So what did he do?
$ git show-branch master origin
! [origin] Separate LDFLAGS and CFLAGS.
* [master] Rename lost+found to lost-found.
--
+ [master] Rename lost+found to lost-found.
+ [master^] Fix compilation warnings in pack-redundant.c
+ [master~2] Debian: build-depend on libexpat-dev.
+ [origin] Separate LDFLAGS and CFLAGS.
++ [master~3] Split gitk into seperate RPM package
Ah, the commit master~3 was what he had the last time I pulled
from him, and since then he made a commit while I did three. I
could do "git pull . origin" at this point, but that would
result in a useless mini-merge. My tree is not public so I can
freely rebase to clean things up.
$ git rebase origin
$ git show-branch
! [origin] Separate LDFLAGS and CFLAGS.
* [master] Rename lost+found to lost-found.
--
+ [master] Rename lost+found to lost-found.
+ [master^] Fix compilation warnings in pack-redundant.c
+ [master~2] Debian: build-depend on libexpat-dev.
++ [origin] Separate LDFLAGS and CFLAGS.
Now I am fast-forward, so I could ask him to pull from me [*3*].
I think each of your developers can do the same, treating the
"project shared repository" as "Linus repository" and pull that
into the "origin" branch, and when the "master" is ready, push
it back into the shared repository (which is equivalent of Linus
pulling everything from me while doing nothing else in his
repository).
For a sizable change that deserves a topic branch with a long
sequence of commits, rebasing is not always the optimum
solution; and you may want to keep the full merge history of
such a branch pushed into the public repository as is. But for
simpler cases that 'git rebase' can handle easily without
conflicts, the above procedure would help you keeping the
history of your shared repository less cluttered.
[Footnotes]
*1* Back then we did not have multi-head fetch, show-branch nor
rebase, so I did these using a homebrew Porcelain.
*2* Unlike CVS which always mucks with the working tree, 'git
fetch' into a branch that is not current one is an operation and
can be done even when I am in the middle of a heavy hackery.
Being able to peek into what others are up even when your tree
is in a messy state (the fetch is often followed by log and
diff) helps you to avoid doing duplicated work or going in a
wrong direction, which was great.
*3* Even back then almost all changes were fed via e-mail to
the maintainer.
^ permalink raw reply
* Re: Balanced packing strategy
From: Petr Baudis @ 2005-11-13 11:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Craig Schlenter, git
In-Reply-To: <7vveyxcm3p.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Nov 13, 2005 at 03:34:02AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Craig Schlenter <craig@codefountain.com> writes:
>
> > Does the pack index file contain enough information to enable a client
> > to send http byte range requests to grab individual objects from a pack?
> > It does seem to store object offsets...
>
> Yes, it is certainly doable; there is enough information. I am
> not sure if it is worth the complexity, though.
I think we need either the balanced packing or this.
> Many objects are stored delitified, so your byte range requests
> would return delta and base object name. After you read what
> was returned and find out the base object name, you would need
> to get it, which can be another delta against its base object.
> This would make tangling a delta chain would become a serialized
> sequence of requests.
Sort the objects topologically, then get everything from the old heads
on. Obviously, this will not work so well when we get multiple heads in
single pack, but either don't do that (would it be actually so bad if we
would create one pack per head?), or:
(i) objects are topologically sorted
(ii) objects introduced by a commit/tree are right after the commit or
tree in the pack file
(iii) index file contains parents list for each commit
This way, you can possibly run through the gaps, or if the gap is big
enough, restart the request. You still will miss objects introduced by
commits in different branches, but in case of trees you can slurp the
trees at once again, and pick the individual objects otherwise; while
doing this second pass, you can apply the gaps strategy again.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] GIT commit statistics.
From: Petr Baudis @ 2005-11-13 11:11 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, Ryan Anderson, Linus Torvalds, git
In-Reply-To: <46a038f90511120419v70166c60t93d58b7544e03e3b@mail.gmail.com>
Dear diary, on Sat, Nov 12, 2005 at 01:19:45PM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> Similarly, when dealing with an upstream, my tree gets slowly out of
> sync and slightly messy.
I've been replying only to this, but missed the team shared repo case,
where StGIT obviously does not make much sense.
> Related to this, I've been wondering whether it'd be possible to teach
> git to rebase local patches, even if that means rewriting local
> history. When you are dealing with team shared repo, the sequences of
> pull/push end up being quite messy, full of little meaningless merges.
Well, only pulls make up for merges. But what's wrong with that? This is
just what you get when using distributed VCS, and what's the point in
skewing the history to look different than how did it happen? I'd just
get used to it. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Remove unneeded packs
From: Sergey Vlasov @ 2005-11-13 12:00 UTC (permalink / raw)
To: Lukas Sandstr__m; +Cc: git, Junio C Hamano
In-Reply-To: <43771C43.7000104@etek.chalmers.se>
[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]
On Sun, 13 Nov 2005 11:58:11 +0100 Lukas Sandstr__m wrote:
> Subject: [PATCH] Make sure all old packfiles are removed when doing a full repack
>
> This is nessecary because unrachable objects in packfiles makes git-pack-redundant
> flag them as non-redundant.
>
> Signed-off-by: Lukas Sandstr____m <lukass@etek.chalmers.se>
>
> ---
>
> git-repack.sh | 16 +++++++++++++++-
> 1 files changed, 15 insertions(+), 1 deletions(-)
>
> applies-to: 9a0f0c748316751fbf593a21f2b16bcdd975095a
> 08df1f641bd3f98a607a8413d647667adc18a633
> diff --git a/git-repack.sh b/git-repack.sh
> index f347207..293bb50 100755
> --- a/git-repack.sh
> +++ b/git-repack.sh
> @@ -32,6 +32,8 @@ case ",$all_into_one," in
> rev_list=
> rev_parse='--all'
> pack_objects=
> + existing=`cd "$PACKDIR" && \
> + find . -type f \( -name '*.pack' -o -name '*.idx' \) -print`
> ;;
> esac
> if [ "$local" ]; then
> @@ -60,7 +62,19 @@ mv .tmp-pack-$name.pack "$PACKDIR/pack-$
> mv .tmp-pack-$name.idx "$PACKDIR/pack-$name.idx" ||
> exit
>
> -if test "$remove_redandant" = t
> +if test "$all_into_one" = t
This should be
if test "$all_into_one$remove_redandant" = tt
(otherwise "git repack -a" becomes the same as "git repack -a -d").
> +then
> + sync
> + ( cd "$PACKDIR" &&
> + for e in $existing
> + do
> + case "$e" in
> + ./pack-$name.pack | ./pack-$name.idx) ;;
> + *) rm -f $e ;;
> + esac
> + done
> + )
> +else if test "$remove_redandant" = t
> then
> sync
> redundant=$(git-pack-redundant --all)
> ---
> 0.99.9.GIT
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Remove unneeded packs
From: Lukas Sandström @ 2005-11-13 12:07 UTC (permalink / raw)
To: git; +Cc: Sergey Vlasov, Junio C Hamano
In-Reply-To: <20051113150051.4a10365d.vsu@altlinux.ru>
Sergey Vlasov wrote:
> On Sun, 13 Nov 2005 11:58:11 +0100 Lukas Sandström wrote:
>
>
>>Subject: [PATCH] Make sure all old packfiles are removed when doing a full repack
>>
>>This is nessecary because unrachable objects in packfiles makes git-pack-redundant
>>flag them as non-redundant.
>>
>>Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
>>
>>---
>>
>> git-repack.sh | 16 +++++++++++++++-
>> 1 files changed, 15 insertions(+), 1 deletions(-)
>>
>>applies-to: 9a0f0c748316751fbf593a21f2b16bcdd975095a
>>08df1f641bd3f98a607a8413d647667adc18a633
>>diff --git a/git-repack.sh b/git-repack.sh
>>index f347207..293bb50 100755
>>--- a/git-repack.sh
>>+++ b/git-repack.sh
>>@@ -32,6 +32,8 @@ case ",$all_into_one," in
>> rev_list=
>> rev_parse='--all'
>> pack_objects=
>>+ existing=`cd "$PACKDIR" && \
>>+ find . -type f \( -name '*.pack' -o -name '*.idx' \) -print`
>> ;;
>> esac
>> if [ "$local" ]; then
>>@@ -60,7 +62,19 @@ mv .tmp-pack-$name.pack "$PACKDIR/pack-$
>> mv .tmp-pack-$name.idx "$PACKDIR/pack-$name.idx" ||
>> exit
>>
>>-if test "$remove_redandant" = t
>>+if test "$all_into_one" = t
>
>
> This should be
>
> if test "$all_into_one$remove_redandant" = tt
>
> (otherwise "git repack -a" becomes the same as "git repack -a -d").
>
>
This was the behaviour before git-pack-redundant, I just restored it.
Someone else gets to decide if git repack -a implies "remove all old packs".
^ permalink raw reply
* Re: Remove unneeded packs
From: Sergey Vlasov @ 2005-11-13 12:20 UTC (permalink / raw)
To: Lukas Sandstr?m; +Cc: git, Junio C Hamano
In-Reply-To: <43772C96.9030805@etek.chalmers.se>
[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]
On Sun, Nov 13, 2005 at 01:07:50PM +0100, Lukas Sandstr?m wrote:
> Sergey Vlasov wrote:
> > On Sun, 13 Nov 2005 11:58:11 +0100 Lukas Sandstr?m wrote:
> >>-if test "$remove_redandant" = t
> >>+if test "$all_into_one" = t
> >
> >
> > This should be
> >
> > if test "$all_into_one$remove_redandant" = tt
> >
> > (otherwise "git repack -a" becomes the same as "git repack -a -d").
> >
> >
>
> This was the behaviour before git-pack-redundant, I just restored it.
But the old code was:
if test "$remove_redandant" = t
then
# We know $existing are all redandant only when
# all-into-one is used.
if test "$all_into_one" != '' && test "$existing" != ''
then
sync
( cd "$PACKDIR" &&
for e in $existing
do
case "$e" in
./pack-$name.pack | ./pack-$name.idx) ;;
*) rm -f $e ;;
esac
done
)
fi
fi
So without the -d option nothing was removed, even with -a.
(And test "$existing" != '' might also be needed for some shells which
are confused by the empty list in the for statement.)
> Someone else gets to decide if git repack -a implies "remove all old packs".
If there is a separate -d option for this, just using -a probably
should not remove anything.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Remove unneeded packs
From: Lukas Sandström @ 2005-11-13 12:31 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: git, Junio C Hamano
In-Reply-To: <20051113122017.GA9996@procyon.home>
Sergey Vlasov wrote:
> On Sun, Nov 13, 2005 at 01:07:50PM +0100, Lukas Sandstr?m wrote:
>
>>Sergey Vlasov wrote:
>>
>>>On Sun, 13 Nov 2005 11:58:11 +0100 Lukas Sandstr?m wrote:
>
>
>>>>-if test "$remove_redandant" = t
>>>>+if test "$all_into_one" = t
>>>
>>>
>>>This should be
>>>
>>>if test "$all_into_one$remove_redandant" = tt
>>>
>>>(otherwise "git repack -a" becomes the same as "git repack -a -d").
>>>
>>>
>>
>>This was the behaviour before git-pack-redundant, I just restored it.
>
>
> But the old code was:
>
> if test "$remove_redandant" = t
> then
> # We know $existing are all redandant only when
> # all-into-one is used.
> if test "$all_into_one" != '' && test "$existing" != ''
> then
> sync
> ( cd "$PACKDIR" &&
> for e in $existing
> do
> case "$e" in
> ./pack-$name.pack | ./pack-$name.idx) ;;
> *) rm -f $e ;;
> esac
> done
> )
> fi
> fi
>
> So without the -d option nothing was removed, even with -a.
>
True. I forgot to look at the context around the changed lines...
Btw, remove_redundant is misspellt.
> (And test "$existing" != '' might also be needed for some shells which
> are confused by the empty list in the for statement.)
>
>
>>Someone else gets to decide if git repack -a implies "remove all old packs".
>
>
> If there is a separate -d option for this, just using -a probably
> should not remove anything.
True, but you will have trouble removing stale packfiles if they contain
unreachable objects unless you remove them when you create the -a pack.
Anyway, ignore the patch above.
^ permalink raw reply
* Re: git.org registered
From: Edésio Costa e Silva @ 2005-11-13 13:27 UTC (permalink / raw)
To: Adrien Beau; +Cc: Git Mailing List
In-Reply-To: <94fc236b0511120450v417f74dm70d39e9046488930@mail.gmail.com>
Hi!
I registered gitscm.org. Currently it is redirected to
http://www.kernel.org/pub/scm. Maybe in the future we could create a
wiki there.
Other suggestions are welcome.
Edésio
On 11/12/05, Adrien Beau <adrienbeau@gmail.com> wrote:
> Andreas Ericsson wrote:
> >
> > git.org has just been registered (well, "just" being what www.git.org says).
> >
> > Might be nothing and it might be someone hitching a free ride.
> > I just thought you all ought to know.
>
> whois git.org says:
> >
> > Domain Name:GIT.ORG
> > Created On:12-May-1997 04:00:00 UTC
> > Last Updated On:25-Oct-2005 16:16:54 UTC
> > Expiration Date:13-May-2011 04:00:00 UTC
>
> Looks like git.org has been registered many years ago, and maybe
> renewed or transfered a few weeks ago.
>
> Randal L. Schwartz wrote:
> >
> > Might be a good time to register gitsoftware.org for future use.
>
> Or maybe gitscm.org or global-information-tracker.com? Anyway, the
> various Git sites already rank very well in Google, I don't think we
> have an emergency here.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] Bugfix: stop if directory already exists
From: Josef Weidendorfer @ 2005-11-13 14:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Fix a typo: We do not want to run the directory as command,
and want to terminate if the directory exists
Additionally, update the usage message
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
Regarding the usage: I do not think that on an error condition
the usage string should be outputted. This helps nothing:
either the user knows the usage, and can see what is wrong by
the error message, or he should look up the man page.
Should we use "git clone" or "git-clone" in the usage message?
Or perhaps
usage: git clone ...
For more details, see 'man git-clone'
?
git-clone.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
applies-to: 62fad3f1275b9bbf07fba50c328a3bd730c3454c
3de065bff303bd4caa433dfa685fdc1164be2b81
diff --git a/git-clone.sh b/git-clone.sh
index f99e0ad..c09979a 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -9,7 +9,7 @@
unset CDPATH
usage() {
- echo >&2 "* git clone [-l [-s]] [-q] [-u <upload-pack>] [-n] <repo> <dir>"
+ echo >&2 "* git clone [-l [-s]] [-q] [-u <upload-pack>] [-n] <repo> [<dir>]"
exit 1
}
@@ -98,7 +98,7 @@ fi
dir="$2"
# Try using "humanish" part of source repo if user didn't specify one
[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*/||g')
-[ -e "$dir" ] && $(echo "$dir already exists."; usage)
+[ -e "$dir" ] && echo "$dir already exists." && usage
mkdir -p "$dir" &&
D=$(
(cd "$dir" && git-init-db && pwd)
---
0.99.9.GIT
^ 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