* Re: [PATCH] Add compat/setenv.c, use in git.c.
From: Jason Riedy @ 2005-12-06 22:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtih299f.fsf@assigned-by-dhcp.cox.net>
And Morten Welinder writes:
- The code looks wrong. It assumes that pointers are no larger than ints.
The failure's in 32-bit mode, so they _are_ the same size.
The difference is no more than 0x80 in the tests.
But you're right; the result is implementation defined in
C99.
And Junio C Hamano writes:
- Are you suggesting it to be done like this?
Your change fixed it. Oddly enough, using arithmetic in
ptrdiff_t then testing against zero didn't... I don't
have time to dig through assembly or try different gcc
versions to figure out the real problem. ugh.
Jason
^ permalink raw reply
* [PATCH] Initial AIX portability fixes.
From: Jason Riedy @ 2005-12-06 22:20 UTC (permalink / raw)
To: git
Added an AIX clause in the Makefile; that clause likely
will be wrong for any AIX pre-5.2, but I can only test
on 5.3. mailinfo.c was missing the compat header file,
and convert-objects.c needs to define a specific
_XOPEN_SOURCE as well as _XOPEN_SOURCE_EXTENDED.
Signed-off-by: E. Jason Riedy <ejr@cs.berkeley.edu>
---
Makefile | 4 ++++
convert-objects.c | 3 ++-
mailinfo.c | 1 +
3 files changed, 7 insertions(+), 1 deletions(-)
54b8c282e017b246612b94bcbf5b88ab39c042a0
diff --git a/Makefile b/Makefile
index 425c519..01b6643 100644
--- a/Makefile
+++ b/Makefile
@@ -243,6 +243,10 @@ ifeq ($(uname_S),NetBSD)
ALL_CFLAGS += -I/usr/pkg/include
ALL_LDFLAGS += -L/usr/pkg/lib -Wl,-rpath,/usr/pkg/lib
endif
+ifeq ($(uname_S),AIX)
+ NO_STRCASESTR=YesPlease
+ NEEDS_LIBICONV=YesPlease
+endif
ifneq (,$(findstring arm,$(uname_M)))
ARM_SHA1 = YesPlease
endif
diff --git a/convert-objects.c b/convert-objects.c
index d78a8b4..b49bce2 100644
--- a/convert-objects.c
+++ b/convert-objects.c
@@ -1,4 +1,5 @@
-#define _XOPEN_SOURCE /* glibc2 needs this */
+#define _XOPEN_SOURCE 500 /* glibc2 and AIX 5.3L need this */
+#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#include <time.h>
#include "cache.h"
diff --git a/mailinfo.c b/mailinfo.c
index 3b97a89..d4b4163 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -8,6 +8,7 @@
#include <string.h>
#include <ctype.h>
#include <iconv.h>
+#include "git-compat-util.h"
#include "cache.h"
static FILE *cmitmsg, *patchfile;
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH] Use printf rather than echo -n.
From: Jason Riedy @ 2005-12-06 22:21 UTC (permalink / raw)
To: git
On AIX, there is no -n option to the system's echo. Instead,
it needs the '\c' control character. We could replace
echo -n "foo"
with
echo -e "foo\c"
but printf is recommended by most man pages. Tested on AIX
5.3, Solaris 8, and Debian.
Signed-off-by: E. Jason Riedy <ejr@cs.berkeley.edu>
---
git-am.sh | 2 +-
git-applypatch.sh | 2 +-
git-bisect.sh | 2 +-
git-status.sh | 4 ++--
4 files changed, 5 insertions(+), 5 deletions(-)
58ad3dda17daa0577fda5204f75bbc846cf7d7ea
diff --git a/git-am.sh b/git-am.sh
index 660b3a4..6ed527c 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -312,7 +312,7 @@ do
echo "--------------------------"
cat "$dotest/final-commit"
echo "--------------------------"
- echo -n "Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all "
+ printf "Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all "
read reply
case "$reply" in
[yY]*) action=yes ;;
diff --git a/git-applypatch.sh b/git-applypatch.sh
index 4c577eb..a112e1a 100755
--- a/git-applypatch.sh
+++ b/git-applypatch.sh
@@ -83,7 +83,7 @@ while [ "$interactive" = yes ]; do
echo "--------------------------"
cat "$final"
echo "--------------------------"
- echo -n "Apply? [y]es/[n]o/[e]dit/[a]ccept all "
+ printf "Apply? [y]es/[n]o/[e]dit/[a]ccept all "
read reply
case "$reply" in
y|Y) interactive=no;;
diff --git a/git-bisect.sh b/git-bisect.sh
index 68838f3..05dae8a 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -67,7 +67,7 @@ bisect_start() {
rm -rf "$GIT_DIR/refs/bisect/"
mkdir "$GIT_DIR/refs/bisect"
{
- echo -n "git-bisect start"
+ printf "git-bisect start"
sq "$@"
} >"$GIT_DIR/BISECT_LOG"
sq "$@" >"$GIT_DIR/BISECT_NAMES"
diff --git a/git-status.sh b/git-status.sh
index b90ffc1..bf0e66c 100755
--- a/git-status.sh
+++ b/git-status.sh
@@ -13,7 +13,7 @@ report () {
trailer=""
while read status name newname
do
- echo -n "$header"
+ printf "$header"
header=""
trailer="#
"
@@ -27,7 +27,7 @@ report () {
U ) echo "# unmerged: $name";;
esac
done
- echo -n "$trailer"
+ printf "$trailer"
[ "$header" ]
}
--
0.99.9.GIT
^ permalink raw reply related
* [RFC] Run hooks with a cleaner environment
From: Daniel Barkalow @ 2005-12-06 22:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Currently, hooks/post-update is run in the environment that receive-pack
is run. This means that there are a number of things that are
unpredictable. I'd like to make it set things up in a more predictable and
useful way. The things I know are odd:
stdout and stdin are connected to send-pack, either by broken pipes (for
local pushes) or an ignored socket (via ssh). stdin should probably be
/dev/null, and stdout should be either a log file or /dev/null. stderr is
still the push's stderr, which may or may not be desired.
GIT_DIR is set to the repository that got the push, which may surprise
people who only use it in "GIT_DIR=foo git ..." form and don't expect it
ever to be set from outside. Of course, it's potentially useful to know
what repository is running the hook, but that doesn't have to be
communicated in such a way that git programs will pick it up directly.
Other environment variables could potentially be purged, too, but I don't
think that's as important, since the user probably knows about them.
cwd is set to the push's cwd if it's local, maybe $HOME if it's over ssh.
It should probably always be $HOME, unless we want it to be $GIT_DIR.
Is there anything else we want to regularize? Is there some sort of
standard behavior we should match, like CVS or cron?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Wine + GIT
From: Nick Hengeveld @ 2005-12-06 23:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Mike McCormack, git
In-Reply-To: <4394F50E.7030803@pobox.com>
On Mon, Dec 05, 2005 at 09:18:54PM -0500, Jeff Garzik wrote:
> One other comment: http:// is the slowest of all three transports.
> git:// (git daemon) is preferred, followed by rsync.
>
> http:// takes forever, comparatively.
Has that been the general git user experience? While there are
certainly disadvantages to the http transport, I didn't think that
performance was one of them.
For comparison, I ran some clones this morning/afternoon with the
following results:
Clone of kernel.org/pub/scm/git/git.git
http
real 0m24.204s real 0m25.750s real 0m24.094s
user 0m5.870s user 0m5.530s user 0m5.350s
sys 0m0.660s sys 0m0.710s sys 0m0.600s
rsync
real 1m3.952s real 1m3.417s real 1m4.360s
user 0m0.090s user 0m0.130s user 0m0.120s
sys 0m0.210s sys 0m0.230s sys 0m0.210s
git
real 0m54.715s real 0m55.928s real 0m56.411s
user 0m0.980s user 0m0.980s user 0m1.040s
sys 0m0.220s sys 0m0.140s sys 0m0.160s
Clone of kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
http
real 4m59.959s real 5m28.512s real 6m9.109s
user 1m38.400s user 1m34.350s user 1m35.700s
sys 0m7.640s sys 0m8.180s sys 0m7.510s
rsync
real 19m47.218s real 19m46.739s real 21m41.875s
user 0m3.960s user 0m4.260s user 0m4.000s
sys 0m5.060s sys 0m4.680s sys 0m4.860s
git
real 19m43.014s real 19m36.692s real 20m43.277s
user 0m23.180s user 0m23.070s user 0m23.230s
sys 0m8.210s sys 0m8.590s sys 0m11.240s
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Wine + GIT
From: Andreas Ericsson @ 2005-12-06 23:27 UTC (permalink / raw)
To: git
In-Reply-To: <20051206230844.GA3876@reactrix.com>
Nick Hengeveld wrote:
> On Mon, Dec 05, 2005 at 09:18:54PM -0500, Jeff Garzik wrote:
>
>
>>One other comment: http:// is the slowest of all three transports.
>>git:// (git daemon) is preferred, followed by rsync.
>>
>>http:// takes forever, comparatively.
>
>
> Has that been the general git user experience?
It certainly is for me, and I know most of my colleagues think so too.
> While there are
> certainly disadvantages to the http transport, I didn't think that
> performance was one of them.
>
> For comparison, I ran some clones this morning/afternoon with the
> following results:
>
When you clone you need to get all the objects. If the objects aren't
packed on the remote end (which is usually the case), the git protocol
will pack them for you which takes quite some time for a large repo and
puts the server under considerable stress.
When you pull incrementally the native git protocol does some figuring
out of the minimum set of packs it needs to send you.
>
> Clone of kernel.org/pub/scm/git/git.git
>
> http
> real 0m24.204s real 0m25.750s real 0m24.094s
> user 0m5.870s user 0m5.530s user 0m5.350s
> sys 0m0.660s sys 0m0.710s sys 0m0.600s
>
> rsync
> real 1m3.952s real 1m3.417s real 1m4.360s
> user 0m0.090s user 0m0.130s user 0m0.120s
> sys 0m0.210s sys 0m0.230s sys 0m0.210s
>
> git
> real 0m54.715s real 0m55.928s real 0m56.411s
> user 0m0.980s user 0m0.980s user 0m1.040s
> sys 0m0.220s sys 0m0.140s sys 0m0.160s
>
In general, rsync:// should be the fastest protocol to clone over. Why
you got the numbers listed above I have no idea, but I'm guessing the
rsync daemon was under quite a bit of stress. http could in that case be
faster since apache handles multiple clients better than rsync, but only
if you're on a very fast line with low round trip time to the server as
it needs to do a lot of downloading and checking to see where it's at
and what it needs.
You may also want to take notice of the fact that the git-daemon can use
cached pack-files, in which case it doesn't have to do so much manual
packing. If cache-files are present, the git protocol *should* be the
fastest to clone over as well.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: ssh removed?
From: Petr Baudis @ 2005-12-06 23:29 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: git list
In-Reply-To: <20051206211918.GP21705@schottelius.org>
Dear diary, on Tue, Dec 06, 2005 at 10:19:18PM CET, I got a letter
where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> said that...
> Did somebody remove git+ssh in git? If I search for ssh in cg-log
> in the git source I do not see any hint. But I see that when trying to
> use it:
..snip..
> [22:16] hydrogenium:ccollect.sh% cg-version
> cogito-0.17pre.GIT (c10cc1d2a99b01ed3bf45d5f2ad6157940a22365)
> [22:17] hydrogenium:ccollect.sh% git --version
> git version 0.99.8.GIT
Quite on the contrary, your GIT is too old - at least 0.99.9 is required
as noted in the INSTALL file.
--
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] Initial AIX portability fixes.
From: Johannes Schindelin @ 2005-12-06 23:58 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <20493.1133907616@lotus.CS.Berkeley.EDU>
Hi,
On Tue, 6 Dec 2005, Jason Riedy wrote:
> -#define _XOPEN_SOURCE /* glibc2 needs this */
> +#define _XOPEN_SOURCE 500 /* glibc2 and AIX 5.3L need this */
> +#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
Why not enclose the #define in #ifndef/#endif, and do the real magic in
the Makefile? Within the AIX clause:
ALL_CFLAGS += -D_XOPEN_SOURCE=500 -XOPEN_SOURCE_EXTENDED=1
This way the source does not get cluttered with platform dependent
defines.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Initial AIX portability fixes.
From: Jason Riedy @ 2005-12-07 0:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512070055430.5888@wbgn013.biozentrum.uni-wuerzburg.de>
And Johannes Schindelin writes:
- Why not enclose the #define in #ifndef/#endif, and do the real magic in
- the Makefile? Within the AIX clause:
- ALL_CFLAGS += -D_XOPEN_SOURCE=500 -XOPEN_SOURCE_EXTENDED=1
Because other files do _not_ compile when given those options.
I'm going for minimal changes to the existing structure; the
#define for glibc2 has been there a long, long time. Yes, it
probably can be done better, but these are 1.0rc versions...
Jason
^ permalink raw reply
* Re: [PATCH] Initial AIX portability fixes.
From: Junio C Hamano @ 2005-12-07 0:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512070055430.5888@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 6 Dec 2005, Jason Riedy wrote:
>
>> -#define _XOPEN_SOURCE /* glibc2 needs this */
>> +#define _XOPEN_SOURCE 500 /* glibc2 and AIX 5.3L need this */
>> +#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
>
> Why not enclose the #define in #ifndef/#endif, and do the real magic in
> the Makefile? Within the AIX clause:
>
> ALL_CFLAGS += -D_XOPEN_SOURCE=500 -XOPEN_SOURCE_EXTENDED=1
>
> This way the source does not get cluttered with platform dependent
> defines.
True but the original convert-objects.c defines _XOPEN_SOURCE on
all platforms not just AIX.
^ permalink raw reply
* Re: [PATCH] Initial AIX portability fixes.
From: Junio C Hamano @ 2005-12-07 0:12 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <21075.1133914036@lotus.CS.Berkeley.EDU>
Jason Riedy <ejr@EECS.Berkeley.EDU> writes:
> And Johannes Schindelin writes:
> - Why not enclose the #define in #ifndef/#endif, and do the real magic in
> - the Makefile? Within the AIX clause:
> - ALL_CFLAGS += -D_XOPEN_SOURCE=500 -XOPEN_SOURCE_EXTENDED=1
>
> Because other files do _not_ compile when given those options.
> I'm going for minimal changes to the existing structure; the
> #define for glibc2 has been there a long, long time. Yes, it
> probably can be done better, but these are 1.0rc versions...
I agree with your approach of least impact for now. Thanks.
^ permalink raw reply
* Re: [RFC] Run hooks with a cleaner environment
From: Paul Serice @ 2005-12-07 0:19 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512061716030.25300@iabervon.org>
> Currently, hooks/post-update is run in the environment that
> receive-pack is run. This means that there are a number of things
> that are unpredictable. I'd like to make it set things up in a more
> predictable and useful way.
I'd like to second this. I've been bitten by two of the three issues
you've raised.
> stdout and stdin are connected to send-pack, either by broken pipes
> (for local pushes) or an ignored socket (via ssh). stdin should
> probably be /dev/null, and stdout should be either a log file or
> /dev/null. stderr is still the push's stderr, which may or may not
> be desired.
If there is a controlling terminal and nothing else git-related is
reading from it, I'd like for stdout and stderr to be reconnected.
Paul Serice
^ permalink raw reply
* Re: gitk - ewww
From: Paul Mackerras @ 2005-12-06 22:54 UTC (permalink / raw)
To: Ben Clifford; +Cc: Git Mailing List
In-Reply-To: <6CC092B0-101F-4D98-9761-B4E24A7CA35A@hawaga.org.uk>
Ben Clifford writes:
> The area around where the 'master' green tag is displayed
> (specifically the two lines below it) are surprisingly poor.
Yes.
> I'm not going to learn tcl/tk and how gitk works to investigate,
> though, but maybe someone else cares enough and/or can see a trivial
> fix...
I'm working on changes which should fix this and also speed it up, but
it's not trivial... :)
Paul.
^ permalink raw reply
* Re: [RFC] Run hooks with a cleaner environment
From: Junio C Hamano @ 2005-12-07 0:39 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512061716030.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> GIT_DIR is set to the repository that got the push,
That is done by receive-pack; it chdir()s into the repository
and does its thing, and the hooks are called from there; I'd
expect cwd to be the repository ('.git'), GIT_DIR to be dot
('.').
I think doing the "unset GIT_DIR" to be the first thing if you
want to access some other repository is documented somewhere but
if not please send a patch to document it.
As to file descriptors, I think duping the output to original
stderr might make sense, but I do not know what breaks, so
interested parties may want to test it out and submit a tested
patch for inclusion.
^ permalink raw reply
* Re: type_size_sort
From: Morten Welinder @ 2005-12-07 0:51 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: GIT Mailing List
In-Reply-To: <439604DF.5010603@op5.se>
> It's perfectly correct. If the same list was to be passed to
> create_sorted_list() twice it will come out exactly the same the second
> time as it did the first. The only thing to remark on is that the return
> above could be written as below instead:
>
> return a - b;
That is not what the part of the standard I quoted says. It very
clearly forbids the sorting function from depending on the pointers'
values. I can even see an implementation actually using this
requirement.
And it is well known that some qsort implementations will do nasty
things if the sorting order is not consistent. I've seen Perl core
dumps on that account, although that is a while ago.
M.
^ permalink raw reply
* Re: [PATCH] Add compat/setenv.c, use in git.c.
From: Morten Welinder @ 2005-12-07 0:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtih299f.fsf@assigned-by-dhcp.cox.net>
> Are you suggesting it to be done like this?
Precisely.
Morten
^ permalink raw reply
* Re: Wine + GIT
From: Ben Clifford @ 2005-12-07 0:56 UTC (permalink / raw)
To: Jon Loeliger, J. Bruce Fields; +Cc: Git List
In-Reply-To: <1133891589.8577.63.camel@cashmere.sps.mot.com>
On 7 Dec 2005, at 04:53, Jon Loeliger wrote:
> On Tue, 2005-12-06 at 11:39, J. Bruce Fields wrote:
>
>> I've enjoyed getting tab completions without having to add whatever's
>> required to my .bashrc to teach it about git subcommands. Oh well,
>> I'll
>> get over it.
>
> I believe this effort is already well under way.
> Uh, I also thought we were going to place it in
> some "contrib" directory too...?
>
The (latest as of now) code for cogito is in cogito's contrib/
directory.
You can get stg,cogito,git,gitk completion code from my repo with:
cg clone http://www.hawaga.org.uk/gitcompletion.git
(I posted a note about it the other day on this git list, entitled
'bash completions code for git+porcelain)
--
Ben • ベン • Бэн • 벤 • 班明
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,
SMS number(s) at above URL.
^ permalink raw reply
* Re: [PATCH] Use printf rather than echo -n.
From: Junio C Hamano @ 2005-12-07 2:04 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <20512.1133907712@lotus.CS.Berkeley.EDU>
Jason Riedy <ejr@EECS.Berkeley.EDU> writes:
> On AIX, there is no -n option to the system's echo. Instead,
> it needs the '\c' control character. We could replace
> echo -n "foo"
> with
> echo -e "foo\c"
> but printf is recommended by most man pages. Tested on AIX
> 5.3, Solaris 8, and Debian.
Hmmmmmmmmmmmmmmmmmmmmmmmm.
Perhaps printf '%s' "$blah" to futureproof, instead of just
saying printf "$blah"?
<rant mode on>
While I do not have anything aginst system without "sane" echo,
I really do not like it. Not your solution, but *having to do*
something like that.
metaconfig Configure does "echo $n frotz $c" with n=-n or c=\\c
set appropriately; autoconf does the same with $ac_n $ac_c.
IIRC, I think ancient autoconf did "echo | tr -d '\012'".
These are far worse than a single printf, although they may be
more portable.
</rant mode off>
As a traditionalist, if I were doing it myself I would probably
pipe echo to tr, but I am lazy so I'd take your patch as is ;-).
^ permalink raw reply
* Re: type_size_sort
From: Junio C Hamano @ 2005-12-07 2:28 UTC (permalink / raw)
To: Morten Welinder; +Cc: git
In-Reply-To: <118833cc0512061651y57ddcdc7pd26996b40c08d225@mail.gmail.com>
Morten Welinder <mwelinder@gmail.com> writes:
>> It's perfectly correct. If the same list was to be passed to
>> create_sorted_list() twice it will come out exactly the same the second
>> time as it did the first. The only thing to remark on is that the return
>> above could be written as below instead:
>>
>> return a - b;
>
> That is not what the part of the standard I quoted says. It very
> clearly forbids the sorting function from depending on the pointers'
> values. I can even see an implementation actually using this
> requirement.
What you say is correct, and people should be careful when using
qsort(), but it does not apply to this case. The patch I posted
is not necessary. Andreas' rewrite quoted above, however, is
invalid when ptrdiff_t (a-b) overflows int range.
The code as written by Linus back on June 25 is correct, but
that sort callchain is written in an unusual way to confuse us
(you were, and I was initially after seeing your message).
(1) The caller look like this. It prepares an array of pointers
in list[], calls qsort with sort_comparator() as the
function to sort this list[]. Each element in this list[]
is a pointer to struct object_entry.
for (i = 0; i < nr_objects; i++)
list[i] = objects + i;
current_sort = sort;
qsort(list, nr_objects, sizeof(struct object_entry *), sort_comparator);
(2) sort_comparator() is called by qsort() with the standard
calling convention -- two pointers pointing into the array
being sorted. It calls current_sort() function set up by
(1), giving it the pointers *FETCHED* *FROM* the locations
these two incoming pointers are pointing at.
static entry_sort_t current_sort;
static int sort_comparator(const void *_a, const void *_b)
{
struct object_entry *a = *(struct object_entry **)_a;
struct object_entry *b = *(struct object_entry **)_b;
return current_sort(a,b);
}
(3) Then type_size_sort() uses compariosn of these two pointers
as the tiebreaker.
Notice? The comparison of two pointers you originally pointed
out is not about the location in list[]. They are values stored
there.
^ permalink raw reply
* Re: type_size_sort
From: Morten Welinder @ 2005-12-07 3:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzjdy721.fsf@assigned-by-dhcp.cox.net>
> Notice? The comparison of two pointers you originally pointed
> out is not about the location in list[]. They are values stored
> there.
Ah, right you are.
Mildly relatedly, notice that a<b can be valid when a-b<0 is
not. ptrdiff_t is not required to be big enough to hold the difference!
(A highly dubious part of the C standard.)
M.
^ permalink raw reply
* Re: [PATCH] Use printf rather than echo -n.
From: Jason Riedy @ 2005-12-07 3:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyp5zmqe.fsf@assigned-by-dhcp.cox.net>
And Junio C Hamano writes:
- Perhaps printf '%s' "$blah" to futureproof, instead of just
- saying printf "$blah"?
Definitely more likely to stay correct. I'm just lazy.
- <rant mode on>
- While I do not have anything aginst system without "sane" echo,
- I really do not like it. Not your solution, but *having to do*
- something like that.
Um, you think the wrong one is sane. ;) Why should echo
in Bourne shell take C-shell arguments? (I blame AT&T for
their crappy licensing.)
Jason
^ permalink raw reply
* prevent git-daemon from running as root?
From: Joshua N Pritikin @ 2005-12-07 5:23 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 121 bytes --]
git-daemon seems to work fine when running as a non-root account.
Maybe it should refuse to start when running as root?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 2/3] git-merge-one: new merge world order.
From: Junio C Hamano @ 2005-12-07 10:01 UTC (permalink / raw)
To: git
This does two things:
- Use new --stage=2 option to create the working tree file with
leading paths and correct permission bits using
checkout-index, as before.
- Make sure we do not confuse "merge" program when the file
being merged has an unfortunate name, '-L'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-merge-one-file.sh | 25 +++++++++----------------
1 files changed, 9 insertions(+), 16 deletions(-)
b539c5e8fbd36e38eb8f589e11aa5b136ddce753
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 88a5da9..7dee88a 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -16,14 +16,6 @@
# been handled already by git-read-tree, but that one doesn't
# do any merges that might change the tree layout.
-verify_path() {
- file="$1"
- dir=`dirname "$file"` &&
- mkdir -p "$dir" &&
- rm -f -- "$file" &&
- : >"$file"
-}
-
case "${1:-.}${2:-.}${3:-.}" in
#
# Deleted in both or deleted in one and unchanged in the other
@@ -95,15 +87,16 @@ case "${1:-.}${2:-.}${3:-.}" in
;;
esac
- # Create the working tree file, with the correct permission bits.
- # we can not rely on the fact that our tree has the path, because
- # we allow the merge to be done in an unchecked-out working tree.
- verify_path "$4" &&
- git-cat-file blob "$2" >"$4" &&
- case "$6" in *7??) chmod +x -- "$4" ;; esac &&
- merge "$4" "$orig" "$src2"
+ # Be careful for funny filename such as "-L" in "$4", which
+ # would confuse "merge" greatly.
+ src1=`git-unpack-file $2`
+ merge "$src1" "$orig" "$src2"
ret=$?
- rm -f -- "$orig" "$src2"
+
+ # Create the working tree file, using "our tree" version from the
+ # index, and then store the result of the merge.
+ git-checkout-index -f --stage=2 -- "$4" && cat "$src1" >"$4"
+ rm -f -- "$orig" "$src1" "$src2"
if [ "$6" != "$7" ]; then
echo "ERROR: Permissions conflict: $5->$6,$7."
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 1/3] checkout-index: allow checking out from higher stages.
From: Junio C Hamano @ 2005-12-07 10:01 UTC (permalink / raw)
To: git
The new option, --stage=<n>, lets you copy out from an unmerged,
higher stage. This is to help the new merge world order during
a nontrivial merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-checkout-index.txt | 6 +++
checkout-index.c | 61 ++++++++++++++++++++++++----------
2 files changed, 48 insertions(+), 19 deletions(-)
3bd348aeea24709cd9be4b9d741f79b6014cd7e3
diff --git a/Documentation/git-checkout-index.txt b/Documentation/git-checkout-index.txt
index 97eef22..9f32c65 100644
--- a/Documentation/git-checkout-index.txt
+++ b/Documentation/git-checkout-index.txt
@@ -9,7 +9,7 @@ git-checkout-index - Copy files from the
SYNOPSIS
--------
'git-checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
- [--] <file>...
+ [--stage=<number>] [--] <file>...
DESCRIPTION
-----------
@@ -40,6 +40,10 @@ OPTIONS
When creating files, prepend <string> (usually a directory
including a trailing /)
+--stage=<number>::
+ Instead of checking out unmerged entries, copy out the
+ files from named stage. <number> must be between 1 and 3.
+
--::
Do not interpret any more arguments as options.
diff --git a/checkout-index.c b/checkout-index.c
index f1e716d..1e1c972 100644
--- a/checkout-index.c
+++ b/checkout-index.c
@@ -36,6 +36,7 @@
static const char *prefix;
static int prefix_length;
+static int checkout_stage; /* default to checkout stage0 */
static struct checkout state = {
.base_dir = "",
@@ -48,20 +49,36 @@ static struct checkout state = {
static int checkout_file(const char *name)
{
- int pos = cache_name_pos(name, strlen(name));
- if (pos < 0) {
- if (!state.quiet) {
- pos = -pos - 1;
- fprintf(stderr,
- "git-checkout-index: %s is %s.\n",
- name,
- (pos < active_nr &&
- !strcmp(active_cache[pos]->name, name)) ?
- "unmerged" : "not in the cache");
- }
- return -1;
+ int namelen = strlen(name);
+ int pos = cache_name_pos(name, namelen);
+ int has_same_name = 0;
+
+ if (pos < 0)
+ pos = -pos - 1;
+
+ while (pos < active_nr) {
+ struct cache_entry *ce = active_cache[pos];
+ if (ce_namelen(ce) != namelen &&
+ memcmp(ce->name, name, namelen))
+ break;
+ has_same_name = 1;
+ if (checkout_stage == ce_stage(ce))
+ return checkout_entry(ce, &state);
+ pos++;
+ }
+
+ if (!state.quiet) {
+ fprintf(stderr, "git-checkout-index: %s ", name);
+ if (!has_same_name)
+ fprintf(stderr, "is not in the cache");
+ else if (checkout_stage)
+ fprintf(stderr, "does not exist at stage %d",
+ checkout_stage);
+ else
+ fprintf(stderr, "is unmerged");
+ fputc('\n', stderr);
}
- return checkout_entry(active_cache[pos], &state);
+ return -1;
}
static int checkout_all(void)
@@ -70,11 +87,11 @@ static int checkout_all(void)
for (i = 0; i < active_nr ; i++) {
struct cache_entry *ce = active_cache[i];
- if (ce_stage(ce))
+ if (ce_stage(ce) != checkout_stage)
continue;
if (prefix && *prefix &&
- ( ce_namelen(ce) <= prefix_length ||
- memcmp(prefix, ce->name, prefix_length) ))
+ (ce_namelen(ce) <= prefix_length ||
+ memcmp(prefix, ce->name, prefix_length)))
continue;
if (checkout_entry(ce, &state) < 0)
errs++;
@@ -88,7 +105,7 @@ static int checkout_all(void)
}
static const char checkout_cache_usage[] =
-"git-checkout-index [-u] [-q] [-a] [-f] [-n] [--prefix=<string>] [--] <file>...";
+"git-checkout-index [-u] [-q] [-a] [-f] [-n] [--stage=[123]] [--prefix=<string>] [--] <file>...";
static struct cache_file cache_file;
@@ -138,11 +155,19 @@ int main(int argc, char **argv)
die("cannot open index.lock file.");
continue;
}
- if (!memcmp(arg, "--prefix=", 9)) {
+ if (!strncmp(arg, "--prefix=", 9)) {
state.base_dir = arg+9;
state.base_dir_len = strlen(state.base_dir);
continue;
}
+ if (!strncmp(arg, "--stage=", 8)) {
+ int ch = arg[8];
+ if ('1' <= ch && ch <= '3')
+ checkout_stage = arg[8] - '0';
+ else
+ die("stage should be between 1 and 3");
+ continue;
+ }
if (arg[0] == '-')
usage(checkout_cache_usage);
break;
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 3/3] update-index: allow --index-info to add higher stages.
From: Junio C Hamano @ 2005-12-07 10:01 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen
In-Reply-To: <20051202083652.GA4824@c165.ib.student.liu.se>
The new merge world order tells the merge strategies to leave
the cache unmerged and store the automerge result in the working
tree if automerge is not clean. This was done for the resolve
strategy and recursive strategy when no rename is involved, but
recording a conflicting merge in the rename case could not
easily be done by the recursive strategy.
This commit adds a new input format, in addition to the exsting
two, to "update-index --index-info".
(1) mode SP sha1 TAB path
The first format is what "git-apply --index-info"
reports, and used to reconstruct a partial tree
that is used for phony merge base tree when falling
back on 3-way merge.
(2) mode SP type SP sha1 TAB path
The second format is to stuff git-ls-tree output
into the index file.
(3) mode SP sha1 SP stage TAB path
This format is to put higher order stages into the
index file and matches git-ls-files --stage output.
To place a higher stage entry to the index, the path should
first be removed by feeding a mode=0 entry for the path, and
then feeding necessary input lines in the (3) format.
For example, starting with this index:
$ git ls-files -s
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0 frotz
$ git update-index --index-info ;# interactive session -- input follows...
0 0000000000000000000000000000000000000000 frotz
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
The first line of the input feeds 0 as the mode to remove the
path; the SHA1 does not matter as long as it is well formatted.
Then the second and third line feeds stage 1 and stage 2 entries
for that path. After the above, we would end up with this:
$ git ls-files -s
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
This completes the groundwork for the new merge world order.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-update-index.txt | 57 +++++++++++++++++++++++++++++++++
update-index.c | 63 ++++++++++++++++++++++++++----------
2 files changed, 103 insertions(+), 17 deletions(-)
d23748a6af3e3db2b239090553f92c3a779b3578
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index e4678cd..c74311d 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -136,6 +136,63 @@ in the database but the file isn't avail
useful when the file is available, but you do not wish to update the
object database.
+
+Using --index-info
+------------------
+
+`--index-info` is a more powerful mechanism that lets you feed
+multiple entry definitions from the standard input, and designed
+specifically for scripts. It can take inputs of three formats:
+
+ . mode SP sha1 TAB path
++
+The first format is what "git-apply --index-info"
+reports, and used to reconstruct a partial tree
+that is used for phony merge base tree when falling
+back on 3-way merge.
+
+ . mode SP type SP sha1 TAB path
++
+The second format is to stuff git-ls-tree output
+into the index file.
+
+ . mode SP sha1 SP stage TAB path
++
+This format is to put higher order stages into the
+index file and matches git-ls-files --stage output.
+
+To place a higher stage entry to the index, the path should
+first be removed by feeding a mode=0 entry for the path, and
+then feeding necessary input lines in the third format.
+
+For example, starting with this index:
+
+------------
+$ git ls-files -s
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0 frotz
+------------
+
+you can feed the following input to `--index-info`:
+
+------------
+$ git update-index --index-info
+0 0000000000000000000000000000000000000000 frotz
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz
+100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
+------------
+
+The first line of the input feeds 0 as the mode to remove the
+path; the SHA1 does not matter as long as it is well formatted.
+Then the second and third line feeds stage 1 and stage 2 entries
+for that path. After the above, we would end up with this:
+
+------------
+$ git ls-files -s
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz
+100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
+------------
+
+
Examples
--------
To update and refresh only the files already checked out:
diff --git a/update-index.c b/update-index.c
index 11b7f6a..be87b99 100644
--- a/update-index.c
+++ b/update-index.c
@@ -256,35 +256,30 @@ inside:
}
}
-static int add_cacheinfo(const char *arg1, const char *arg2, const char *arg3)
+static int add_cacheinfo(unsigned int mode, const unsigned char *sha1,
+ const char *path, int stage)
{
int size, len, option;
- unsigned int mode;
- unsigned char sha1[20];
struct cache_entry *ce;
- if (sscanf(arg1, "%o", &mode) != 1)
- return -1;
- if (get_sha1_hex(arg2, sha1))
- return -1;
- if (!verify_path(arg3))
+ if (!verify_path(path))
return -1;
- len = strlen(arg3);
+ len = strlen(path);
size = cache_entry_size(len);
ce = xmalloc(size);
memset(ce, 0, size);
memcpy(ce->sha1, sha1, 20);
- memcpy(ce->name, arg3, len);
- ce->ce_flags = htons(len);
+ memcpy(ce->name, path, len);
+ ce->ce_flags = create_ce_flags(len, stage);
ce->ce_mode = create_ce_mode(mode);
option = allow_add ? ADD_CACHE_OK_TO_ADD : 0;
option |= allow_replace ? ADD_CACHE_OK_TO_REPLACE : 0;
if (add_cache_entry(ce, option))
return error("%s: cannot add to the index - missing --add option?",
- arg3);
- report("add '%s'", arg3);
+ path);
+ report("add '%s'", path);
return 0;
}
@@ -342,7 +337,24 @@ static void read_index_info(int line_ter
char *path_name;
unsigned char sha1[20];
unsigned int mode;
+ int stage;
+ /* This reads lines formatted in one of three formats:
+ *
+ * (1) mode SP sha1 TAB path
+ * The first format is what "git-apply --index-info"
+ * reports, and used to reconstruct a partial tree
+ * that is used for phony merge base tree when falling
+ * back on 3-way merge.
+ *
+ * (2) mode SP type SP sha1 TAB path
+ * The second format is to stuff git-ls-tree output
+ * into the index file.
+ *
+ * (3) mode SP sha1 SP stage TAB path
+ * This format is to put higher order stages into the
+ * index file and matches git-ls-files --stage output.
+ */
read_line(&buf, stdin, line_termination);
if (buf.eof)
break;
@@ -354,9 +366,19 @@ static void read_index_info(int line_ter
tab = strchr(ptr, '\t');
if (!tab || tab - ptr < 41)
goto bad_line;
+
+ if (tab[-2] == ' ' && '1' <= tab[-1] && tab[-1] <= '3') {
+ stage = tab[-1] - '0';
+ ptr = tab + 1; /* point at the head of path */
+ tab = tab - 2; /* point at tail of sha1 */
+ }
+ else {
+ stage = 0;
+ ptr = tab + 1; /* point at the head of path */
+ }
+
if (get_sha1_hex(tab - 40, sha1) || tab[-41] != ' ')
goto bad_line;
- ptr = tab + 1;
if (line_termination && ptr[0] == '"')
path_name = unquote_c_style(ptr, NULL);
@@ -382,7 +404,7 @@ static void read_index_info(int line_ter
* ptr[-41] is at the beginning of sha1
*/
ptr[-42] = ptr[-1] = 0;
- if (add_cacheinfo(buf.buf, ptr-41, path_name))
+ if (add_cacheinfo(mode, sha1, path_name, stage))
die("git-update-index: unable to update %s",
path_name);
}
@@ -449,10 +471,17 @@ int main(int argc, const char **argv)
continue;
}
if (!strcmp(path, "--cacheinfo")) {
+ unsigned char sha1[20];
+ unsigned int mode;
+
if (i+3 >= argc)
die("git-update-index: --cacheinfo <mode> <sha1> <path>");
- if (add_cacheinfo(argv[i+1], argv[i+2], argv[i+3]))
- die("git-update-index: --cacheinfo cannot add %s", argv[i+3]);
+
+ if ((sscanf(argv[i+1], "%o", &mode) != 1) ||
+ get_sha1_hex(argv[i+2], sha1) ||
+ add_cacheinfo(mode, sha1, argv[i+3], 0))
+ die("git-update-index: --cacheinfo"
+ " cannot add %s", argv[i+3]);
i += 3;
continue;
}
--
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