* Re: [PATCH] Use backticks instead of $(command) to maintain /bin/sh compatibility
From: Junio C Hamano @ 2005-05-07 18:38 UTC (permalink / raw)
To: GIT
In-Reply-To: <20050507101530.GH23680@cip.informatik.uni-erlangen.de>
>>>>> "TG" == Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
TG> Hello,
>> You can nest $() which is valuable, unlike backtics.
TG> we're aware of this. But the specific script works perfectly fine
TG> without nested simple-command redirection. So what is your point?
If that is the case then I think the patch you posted to force
bash is backwards. How about changing it to use backticks?
^ permalink raw reply
* Re: [PATCH] Use backticks instead of $(command) to maintain /bin/sh compatibility
From: Martin Waitz @ 2005-05-07 17:24 UTC (permalink / raw)
To: GIT, Junio C Hamano
In-Reply-To: <20050507090543.GG23680@cip.informatik.uni-erlangen.de>
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
hoi :)
On Sat, May 07, 2005 at 11:05:43AM +0200, Thomas Glanzmann wrote:
> * Junio C Hamano <junkio@cox.net> [050507 10:54]:
> > A quick question. Which construct in this bashism?
> > Not using backtick but saying $(command)?
>
> Exactly:
huh? which broken shell does not understand $()?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Broken adding of cache entries
From: Petr Baudis @ 2005-05-07 15:28 UTC (permalink / raw)
To: Kay Sievers; +Cc: git, junkio
In-Reply-To: <1115431767.32065.182.camel@localhost.localdomain>
Dear diary, on Sat, May 07, 2005 at 04:09:27AM CEST, I got a letter
where Kay Sievers <kay.sievers@vrfy.org> told me that...
..snip..
> Look what funny thing you can do:
> kay@mam:~/public_html/pub/scm/funny-tree$ git-ls-tree HEAD
> 100644 blob b1a17ba136936531b72571844a773fe938b85ad4 entry
> 040000 tree eba6ba02f18176500019755ad58c0bdfead16c47 entry
>
> Add a file to the cache, replace it with a directory, add that to the
> cache and then write the tree and you have two entries with the same
> name. :)
Duh. Well, what could be the reasonwhy cache_name_compare() cares about
flags at all? Can you _ever_ have two same-named entries? Junio, what do
you think about something like this?
Index: read-cache.c
===================================================================
--- e47e2a558a85b33e0652233f78aa1ca8a959685b/read-cache.c (mode:100644)
+++ uncommitted/read-cache.c (mode:100644)
@@ -68,10 +68,6 @@
return -1;
if (len1 > len2)
return 1;
- if (flags1 < flags2)
- return -1;
- if (flags1 > flags2)
- return 1;
return 0;
}
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: David Woodhouse @ 2005-05-07 12:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505050846530.2328@ppc970.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
On Thu, 2005-05-05 at 09:40 -0700, Linus Torvalds wrote:
> Btw, if you want to, you could simplify and optimize things heavily by
> doign some very specific git internal mucking around, and using the new
> "-m" flag I added to "git-diff-cache".
OK, this is in place now. I also made sure it was going to treat a real
'2.6.12' release as newer than '2.6.12-rcX'. The selection of the tags
and the output of the log are still chronological, which is of course
wrong -- but it'll do for now.
As an added bonus I've also fixed the script to refrain from creating a
-git1 snapshot even when there have been no commits since the last
release. And deleted 2.6.12-rc4-git1.
--
dwmw2
[-- Attachment #2: git-snapshot.sh --]
[-- Type: application/x-shellscript, Size: 2499 bytes --]
^ permalink raw reply
* Re: [PATCH] git-tar-tree: Lift path length limit
From: Petr Baudis @ 2005-05-07 12:09 UTC (permalink / raw)
To: Rene Scharfe; +Cc: Linus Torvalds, git
In-Reply-To: <20050507005706.GA6093@lsrfire.ath.cx>
Dear diary, on Sat, May 07, 2005 at 02:57:06AM CEST, I got a letter
where Rene Scharfe <rene.scharfe@lsrfire.ath.cx> told me that...
> On Sat, May 07, 2005 at 02:25:27AM +0200, Rene Scharfe wrote:
> > Last minute patch?
>
> This leaks memory. D'oh!
>
> Petr, would you add the (hopefully) fixed version below to your tree now
> that Linus is on vacation? (Patch applies to tip of GIT tree.)
It appears to me that the patch currently in the git tree is this
(correct) one?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [patch] add simple git documentation
From: Petr Baudis @ 2005-05-07 11:36 UTC (permalink / raw)
To: David Greaves; +Cc: Andrew Morton, Pavel Machek, git
In-Reply-To: <427C7E38.3010301@dgreaves.com>
Dear diary, on Sat, May 07, 2005 at 10:37:12AM CEST, I got a letter
where David Greaves <david@dgreaves.com> told me that...
> Andrew Morton wrote:
>
> >Pavel Machek <pavel@ucw.cz> wrote:
> >
> >
> >>This adds short intro to git aimed at kernel hackers.
> >>
> >>
> >>
> >
> >OK, but I'm hoping that shortly we'll have something more complete than
> >this, and your patch might not be a suitable starting point for that.
> >(Large hint-dropping sounds).
> >
> >
> What are you looking for.
>
> For man-page-a-like, have you seen Documentation/core-git.txt in Linus'
> repository?
>
> I'll be working more on that this weekend.
Are you planning to split it to individual files at some point?
(That's what I'd like to do with Documentation/cogito/, speaking of
manpageness...)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH] Use backticks instead of $(command) to maintain /bin/sh compatibility
From: Thomas Glanzmann @ 2005-05-07 10:15 UTC (permalink / raw)
To: GIT
In-Reply-To: <20050507100348.GA16461@outpost.ds9a.nl>
Hello,
> You can nest $() which is valuable, unlike backtics.
we're aware of this. But the specific script works perfectly fine
without nested simple-command redirection. So what is your point?
Thomas
^ permalink raw reply
* Re: [PATCH] Use backticks instead of $(command) to maintain /bin/sh compatibility
From: bert hubert @ 2005-05-07 10:03 UTC (permalink / raw)
To: GIT, Junio C Hamano
In-Reply-To: <20050507090543.GG23680@cip.informatik.uni-erlangen.de>
On Sat, May 07, 2005 at 11:05:43AM +0200, Thomas Glanzmann wrote:
> * Junio C Hamano <junkio@cox.net> [050507 10:54]:
> > A quick question. Which construct in this bashism?
> > Not using backtick but saying $(command)?
You can nest $() which is valuable, unlike backtics.
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
^ permalink raw reply
* [PATCH] Use backticks instead of $(command) to maintain /bin/sh compatibility
From: Thomas Glanzmann @ 2005-05-07 9:05 UTC (permalink / raw)
To: GIT; +Cc: Junio C Hamano
In-Reply-To: <7v3bszbeoo.fsf@assigned-by-dhcp.cox.net>
Hello,
* Junio C Hamano <junkio@cox.net> [050507 10:54]:
> A quick question. Which construct in this bashism?
> Not using backtick but saying $(command)?
Exactly:
(faui04a) [~/work/git/git-solaris] git pull
head => 46dd99f970d283dc0de440c06fca8f4586b70548
remote => e7d3dd248f50501f98b29c917e70bddcf3ea925a
base => 74c7cfa875448c71a18d21a0cc7c973afe759fa5
Documentation/core-git.txt: unmerged (8bd893197e6e769b6e03ca1206e355214e16d56a)
local-pull.c: unmerged (4f52bca48c390e8113b3695a53ce62e0c23278a8)
local-pull.c: unmerged (a8af725467cde6653160511e468a1fda4e004503)
local-pull.c: unmerged (1eec8927dbfa3af934651b25ded738d192706286)
sha1_file.c: unmerged (e6ce455ae90bd430f2128f454bdb6e0575412486)
sha1_file.c: unmerged (7887b6481ae5c9368a24bf053f79dbbc1f039300)
sha1_file.c: unmerged (f1c1c70d784aa0587cd4c7143c3d464fd8e5ddc6)
fatal: write-tree: not able to write tree
This is it:
/home/cip/adm/sithglan/work/git/bin/git-SunOS/bin/git-merge-one-file-script: syntax error at line 55: `orig=$' unexpected
fatal: merge program failed
git-merge-cache failed: child exit value: 1 at /home/cip/adm/sithglan/work/git/yagf/git line 1015.
The attached patch at the end of this eMail fixes it for me *without*
touching /bin/sh in the bang:
(faui04a) [~/work/git/git-solaris] git pull
head => 46dd99f970d283dc0de440c06fca8f4586b70548
remote => e7d3dd248f50501f98b29c917e70bddcf3ea925a
base => 74c7cfa875448c71a18d21a0cc7c973afe759fa5
Documentation/core-git.txt: unmerged (8bd893197e6e769b6e03ca1206e355214e16d56a)
local-pull.c: unmerged (4f52bca48c390e8113b3695a53ce62e0c23278a8)
local-pull.c: unmerged (a8af725467cde6653160511e468a1fda4e004503)
local-pull.c: unmerged (1eec8927dbfa3af934651b25ded738d192706286)
sha1_file.c: unmerged (e6ce455ae90bd430f2128f454bdb6e0575412486)
sha1_file.c: unmerged (7887b6481ae5c9368a24bf053f79dbbc1f039300)
sha1_file.c: unmerged (f1c1c70d784aa0587cd4c7143c3d464fd8e5ddc6)
fatal: write-tree: not able to write tree
Threewaydiff invloved.
[PATCH] Use backticks instead of $(command) to maintain /bin/sh compatibility
Signed-Off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
--- a/git-merge-one-file-script
+++ b/git-merge-one-file-script
@@ -52,9 +52,9 @@
#
"$1$2$3")
echo "Auto-merging $4."
- orig=$(git-unpack-file $1)
- src1=$(git-unpack-file $2)
- src2=$(git-unpack-file $3)
+ orig=`git-unpack-file $1`
+ src1=`git-unpack-file $2`
+ src2=`git-unpack-file $3`
merge "$src2" "$orig" "$src1"
ret=$?
if [ "$6" != "$7" ]; then
@@ -64,7 +64,7 @@
echo "ERROR: Leaving conflict merge in $src2."
exit 1
fi
- sha1=$(git-write-blob "$src2") || {
+ sha1=`git-write-blob "$src2"` || {
echo "ERROR: Leaving conflict merge in $src2."
}
exec git-update-cache --add --cacheinfo "$6" $sha1 "$4" ;;
^ permalink raw reply
* Re: How do I...
From: David Woodhouse @ 2005-05-07 8:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Frank Sorenson, git
In-Reply-To: <Pine.LNX.4.58.0505061652240.2233@ppc970.osdl.org>
On Fri, 2005-05-06 at 16:54 -0700, Linus Torvalds wrote:
> But trying to be clever while building this up is just crazy talk. When
> diff-tree prints out the changes, it has no way of knowing what the
> context around it was - it doesn't know about merges far away, and it
> _shouldn't_ know.
Isn't that what I suggested? Start with full history, mark the
'interesting' commits which touch the file(s) in question, then prune.
--
dwmw2
^ permalink raw reply
* Re: [PATCH]: git-merge-one-file-script use /usr/bin/env to call bash
From: Junio C Hamano @ 2005-05-07 8:52 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20050507084549.GF23680@cip.informatik.uni-erlangen.de>
A quick question. Which construct in this bashism?
Not using backtick but saying $(command)?
^ permalink raw reply
* Re: [patch] add simple git documentation
From: David Greaves @ 2005-05-07 8:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: Pavel Machek, git
In-Reply-To: <20050506175835.65b9c9c1.akpm@osdl.org>
Andrew Morton wrote:
>Pavel Machek <pavel@ucw.cz> wrote:
>
>
>>This adds short intro to git aimed at kernel hackers.
>>
>>
>>
>
>OK, but I'm hoping that shortly we'll have something more complete than
>this, and your patch might not be a suitable starting point for that.
>(Large hint-dropping sounds).
>
>
What are you looking for.
For man-page-a-like, have you seen Documentation/core-git.txt in Linus'
repository?
I'll be working more on that this weekend.
David
--
^ permalink raw reply
* [PATCH] make INSTALL binary in Makefile configurable via make variable
From: Thomas Glanzmann @ 2005-05-07 8:41 UTC (permalink / raw)
To: GIT; +Cc: Linus Torvalds
[PATCH] make INSTALL binary in Makefile configurable via make variable
On Solaris machines gnu install called ginstall
Signed-Off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
--- a/Makefile
+++ b/Makefile
@@ -11,6 +11,7 @@
CC=gcc
AR=ar
+INSTALL=install
SCRIPTS=git-apply-patch-script git-merge-one-file-script git-prune-script \
git-pull-script git-tag-script git-resolve-script
@@ -26,7 +27,7 @@
all: $(PROG)
install: $(PROG) $(SCRIPTS)
- install $(PROG) $(SCRIPTS) $(HOME)/bin/
+ $(INSTALL) $(PROG) $(SCRIPTS) $(HOME)/bin/
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
tag.o date.o
-
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]: git-merge-one-file-script use /usr/bin/env to call bash
From: Thomas Glanzmann @ 2005-05-07 8:45 UTC (permalink / raw)
To: Linus Torvalds, GIT
[PATCH]: git-merge-one-file-script use /usr/bin/env to call bash
Signed-Off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
--- a/git-merge-one-file-script
+++ b/git-merge-one-file-script
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/usr/bin/env bash
#
# This is the git merge script, called with
#
^ permalink raw reply
* [PATCH] Add #include <limits.h> so that git compiles under Solaris
From: Thomas Glanzmann @ 2005-05-07 8:41 UTC (permalink / raw)
To: GIT; +Cc: Linus Torvalds
[PATCH] Add #include <limits.h> so that git compiles under Solaris
Signed-Off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
--- a/diff-tree-helper.c
+++ b/diff-tree-helper.c
@@ -1,6 +1,7 @@
/*
* Copyright (C) 2005 Junio C Hamano
*/
+#include <limits.h>
#include "cache.h"
#include "strbuf.h"
#include "diff.h"
--- a/diff.c
+++ b/diff.c
@@ -4,6 +4,7 @@
#include <sys/types.h>
#include <sys/wait.h>
#include <signal.h>
+#include <limits.h>
#include "cache.h"
#include "diff.h"
--- a/local-pull.c
+++ b/local-pull.c
@@ -5,6 +5,7 @@
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
+#include <limits.h>
#include "cache.h"
#include "commit.h"
#include <errno.h>
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -7,6 +7,7 @@
* creation etc.
*/
#include <stdarg.h>
+#include <limits.h>
#include "cache.h"
const char *sha1_file_directory = NULL;
-
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
* Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES
From: Junio C Hamano @ 2005-05-07 6:31 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <2721.10.10.10.24.1115425962.squirrel@linux1>
>>>>> "S" == Sean <seanlkml@sympatico.ca> writes:
S> Perhaps I'm just missing something in your code,...
Yes you are. You have spotted a very inconvenient inconsistency
in the interface to the code.
Only on the very first time when it tries to constructs the
alternate directory list, and if there is no alternate list, it
just returns the name without stat(), which forces the callers
to do stat() themselves all the time. I think I should make it
always stat, since the reading side needs do it anyway.
Thankfully I think Linus had rejected this part in the series.
I'll fix it up.
^ permalink raw reply
* Updated versions of previously posted patches
From: Jonas Fonseca @ 2005-05-07 3:38 UTC (permalink / raw)
To: pasky; +Cc: git
Hi pasky,
I have updated the patches I have previously posted here. They are
available at http://www.nitro.dk/~jonas/cogito/ and carry the following
changes:
- 0--move-date-to-Xlib.patch
Move date conversion from cg-log to cg-Xlib so it can be used in the
next patch.
- 1--human-readable-mkpatch-dates.patch:
Show the author and commit date in a human readable format.
- 2--show-changed-files-in-log-output.patch
Add an -f switch to cg-log controlling whether to list which files
were changed. The output looks like the following:
<commit header>
* file1, file2, ..., fileN:
<log message>
It doesn't do anything fancy like wrapping long lines and can be quite
costly to do for big logs.
- 3--add-mkpatch-short-version.patch
Add an -s option to cg-mkpatch which specifies whether to print a
short version of the patch without a patch header with meta info such
as author and committer.
This was proposed by you after YOSHIFUJI Hideaki pointed out that the
diffstat is not always useful. However, I don't know if this is
anywhere near how you intended it to be. Anyway, it prepares for the
next patch.
- 4--show-diffstat-for-mkpatch.patch
Show diffstat as part of the patch header if diffstat is available on
the system.
I didn't test this since diffstat unfortunately wasn't available on
the system I updated the patches on.
--
Jonas Fonseca
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: Marcelo Tosatti @ 2005-05-06 21:51 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: David Woodhouse, Git Mailing List
In-Reply-To: <427BE699.60802@zytor.com>
On Fri, May 06, 2005 at 02:50:17PM -0700, H. Peter Anvin wrote:
> David Woodhouse wrote:
> >On Thu, 2005-05-05 at 17:28 -0700, H. Peter Anvin wrote:
> >
> >>Could you add that to 2.4 as well, too?
> >
> >Is there a 2.4 git tree?
> >
>
> I thought so, but now I can't find it. Marcelo?
Not yet. I should be able to put a "beta" version
next week.
David, can I bug you to add nightly snapshotting
as soon as the v2.4 git tree is created ?
I hope there aren't many further changes in v2.4.x...
^ permalink raw reply
* Re: [patch] add simple git documentation
From: Andrew Morton @ 2005-05-07 0:58 UTC (permalink / raw)
To: Pavel Machek; +Cc: git
In-Reply-To: <20050505102600.GA16387@elf.ucw.cz>
Pavel Machek <pavel@ucw.cz> wrote:
>
> This adds short intro to git aimed at kernel hackers.
>
OK, but I'm hoping that shortly we'll have something more complete than
this, and your patch might not be a suitable starting point for that.
(Large hint-dropping sounds).
>
> ---
> commit addb0833bdadda14495d66749e6cb95b6a9445d7
> tree 7e66cb899004fbec0fadae5c9265d0731d3a26f3
> parent 1f9ca1262e6b27dde44d456a87c456d15f0a9b80
> author <pavel@amd.(none)> 1115288688 +0200
> committer <pavel@amd.(none)> 1115288688 +0200
>
> Index: Documentation/git.txt
> ===================================================================
> --- /dev/null (tree:de65e7579ed050d324357e3040b37c561676ab7d)
> +++ 7e66cb899004fbec0fadae5c9265d0731d3a26f3/Documentation/git.txt (mode:100644 sha1:353d5ae7f46eeb79c058be611cb429622167f784)
> @@ -0,0 +1,41 @@
> + Kernel hacker's guide to git
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + 2005 Pavel Machek <pavel@suse.cz>
> +
> +You can get cogito at http://www.kernel.org/pub/software/scm/cogito/
> +. Compile it, and place it somewhere in $PATH. Then you can get kernel
> +by running
> +
> +mkdir clean-cg; cd clean-cg
> +cg-init rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> +
> +... Do cg-update origin to pickup latest changes from Linus. You can
> +do cg-diff to see what changes you done in your local tree. cg-cancel
> +will kill any such changes, and cg-commit will make them permanent.
> +
> +To get diff between your working tree and "next tree up", do cg-diff
> +-r origin: . If you want to get the same diff but separated
> +patch-by-patch, do cg-mkpatch origin: . If you want to pull changes
> +from the "up" tree to your working tree, do cg-update origin.
> +
> +
> +How to set up your trees so that you can cooperate with Linus
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +What I did:
> +
> +Created clean-cg. Initialized straight from Linus (as above). Then I
> +created "nice" tree, good for Linus to pull from
> +
> +mkdir /data/l/linux-good; cd /data/l/linux-good
> +cg-init /data/l/clean-cg
> +
> +and then my working tree, based on linux-good
> +
> +mkdir /data/l/linux-cg; cd /data/l/linux-cg
> +cg-init /data/l/linux-good
> +
> +. I do my work in linux-cg. If someone sends me nice patch I should
> +pass up, I apply it to linux-good with nice message and do
> +
> +cd /data/l/linux-cg; cg-update origin
>
> --
> Boycott Kodak -- for their patent abuse against Java.
^ permalink raw reply
* Re: [PATCH] git-tar-tree: Lift path length limit
From: Rene Scharfe @ 2005-05-07 0:57 UTC (permalink / raw)
To: Linus Torvalds, Petr Baudis; +Cc: git
In-Reply-To: <20050507002527.GA5082@lsrfire.ath.cx>
On Sat, May 07, 2005 at 02:25:27AM +0200, Rene Scharfe wrote:
> Last minute patch?
This leaks memory. D'oh!
Petr, would you add the (hopefully) fixed version below to your tree now
that Linus is on vacation? (Patch applies to tip of GIT tree.)
Thanks,
Rene
Lift path length limits from git-tar-tree.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
commit d36797f64ee0431e6a73aa1c77a7fe7c18b6ce9f
tree ab8e6967a08ac343b69b527f663e6a9722fcea08
parent bf60144c0ab50e88c0086a90c5cb35b81613ad14
author Rene Scharfe <rene.scharfe@lsrfire.ath.cx> 1115322098 +0200
committer Rene Scharfe <rene.scharfe@lsrfire.ath.cx> 1115322098 +0200
Index: tar-tree.c
===================================================================
--- 8ef25a2788d6c225641a3040622b82c364f987b8/tar-tree.c (mode:100644 sha1:9d9bd7be98502f64e4a643ef0973182f3483251e)
+++ ab8e6967a08ac343b69b527f663e6a9722fcea08/tar-tree.c (mode:100644 sha1:8b0d75bd2cf12a531aee3d51e59a8ac8102ba6be)
@@ -212,7 +212,7 @@
const char *path, unsigned int namelen,
void *content, unsigned int contentsize)
{
- char *p;
+ char *buffer, *p;
unsigned int pathlen, size, linkpathlen = 0;
size = pathlen = extended_header_len("path", namelen);
@@ -220,18 +220,19 @@
linkpathlen = extended_header_len("linkpath", contentsize);
size += linkpathlen;
}
- if (size > RECORDSIZE)
- die("tar-tree: extended header too big, wtf?");
write_header(NULL, TYPEFLAG_EXT_HEADER, NULL, NULL, headerfilename,
0100600, NULL, size);
- p = get_record();
+ buffer = p = malloc(size);
+ if (!buffer)
+ die("git-tar-tree: %s", strerror(errno));
append_extended_header_prefix(&p, pathlen, "path");
append_path(&p, is_dir, basepath, prefix, path);
append_char(&p, '\n');
if (flags & EXT_HEADER_LINKPATH)
append_extended_header(&p, "linkpath", content, contentsize);
- write_if_needed();
+ write_blocked(buffer, size);
+ free(buffer);
}
static void write_global_extended_header(const char *sha1)
@@ -269,9 +270,7 @@
}
namelen = path_len(S_ISDIR(mode), basepath, prefix, path);
- if (namelen > 500)
- die("tar-tree: name too log of object %s\n", sha1_to_hex(sha1));
- else if (namelen > 100)
+ if (namelen > 100)
ext_header |= EXT_HEADER_PATH;
if (typeflag == TYPEFLAG_LNK && size > 100)
ext_header |= EXT_HEADER_LINKPATH;
^ permalink raw reply
* Re: How do I...
From: Benjamin Herrenschmidt @ 2005-05-07 0:45 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, Frank Sorenson, git
In-Reply-To: <1115397368.16187.266.camel@hades.cambridge.redhat.com>
On Fri, 2005-05-06 at 17:36 +0100, David Woodhouse wrote:
> On Fri, 2005-05-06 at 09:13 -0700, Linus Torvalds wrote:
> > There has been at least two different scripts for this posted, and one C
> > source code version.
> >
> > I just haven't integrated them, because I'm an idiot, and too much choice
> > makes me run around in small circles and clucking.
> >
> > Guys - whoever wrote one of the scripts, can you please send out your
> > current version to the git list and cc me, and explain why yours is
> > superior to the other peoples version. Please?
>
> I already explained why mine sucks and shouldn't be merged. It was a
> proof of concept; hoping for the stone soup effect.
>
> I haven't seen a C version or indeed anything which actually does the
> right thing, although I outlined how it would work and _threatened_ to
> do one. I had a half-arsed attempt at it on the way home from
> linux.conf.au but my brain tends to melt while I'm on airplanes so I
> didn't get very far.
Note that paulus current dirdiff CVS can diff arbitrary revs of a git
tree afaik (or a rev against current edited content).
Ben.
^ permalink raw reply
* Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES
From: Sean @ 2005-05-07 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vis1vc27f.fsf@assigned-by-dhcp.cox.net>
On Fri, May 6, 2005 8:24 pm, Junio C Hamano said:
>>>>>> "S" == Sean <seanlkml@sympatico.ca> writes:
>
> S> has_sha1_file can be reduced to:
>
> S> int has_sha1_file(const unsigned char *sha1)
> S> {
> S> return (!!find_sha1_file(sha1));
> S> }
>
> Not really. If you do not have alternates it does not even
> bother to stat so you get the path that supposed to contain the
> data and you need to do the checking yourself.
>
>
Perhaps I'm just missing something in your code, but this fragment makes
it look to me that stat is always called in find_sha1_file even when there
are no alternates:
+ char *name = sha1_file_name(sha1);
[...]
+ if (!stat(name, &st))
+ return name;
+ for (i = 0; i < num_alt; i++) {
Sean
^ permalink raw reply
* [PATCH] git-tar-tree: Lift path length limit
From: Rene Scharfe @ 2005-05-07 0:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Petr Baudis
Last minute patch? This lifts the limits from path length and link
path length that are in git-tar-tree.
Have a nice vacation!
Rene
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
commit 2d7b8f2afc47c753aaab4bf48587fdea730b0db3
tree 378fae86e43460c1c53feccbde3573ced26818f6
parent a02ebff6127c5fc981668fb570f0a80f2b7657ca
author Rene Scharfe <rene.scharfe@lsrfire.ath.cx> 1115320521 +0200
committer Rene Scharfe <rene.scharfe@lsrfire.ath.cx> 1115320521 +0200
Index: tar-tree.c
===================================================================
--- 8477488c1965186c98b59ad0da04d221aff3c9a1/tar-tree.c (mode:100644 sha1:a09cb416595094e493a52dd7f45d943c81c0310a)
+++ 378fae86e43460c1c53feccbde3573ced26818f6/tar-tree.c (mode:100644 sha1:0fb6514c27a0f0edc2fc6e9850c361c8a58c0a9f)
@@ -212,7 +212,7 @@
const char *path, unsigned int namelen,
void *content, unsigned int contentsize)
{
- char *p;
+ char *buffer, *p;
unsigned int pathlen, size, linkpathlen = 0;
size = pathlen = extended_header_len("path", namelen);
@@ -220,18 +220,18 @@
linkpathlen = extended_header_len("linkpath", contentsize);
size += linkpathlen;
}
- if (size > RECORDSIZE)
- die("tar-tree: extended header too big, wtf?");
write_header(NULL, TYPEFLAG_EXT_HEADER, NULL, NULL, headerfilename,
0100600, NULL, size);
- p = get_record();
+ buffer = p = malloc(size);
+ if (!buffer)
+ die("git-tar-tree: %s", strerror(errno));
append_extended_header_prefix(&p, pathlen, "path");
append_path(&p, is_dir, basepath, prefix, path);
append_char(&p, '\n');
if (flags & EXT_HEADER_LINKPATH)
append_extended_header(&p, "linkpath", content, contentsize);
- write_if_needed();
+ write_blocked(buffer, size);
}
static void write_global_extended_header(const char *sha1)
@@ -269,9 +269,7 @@
}
namelen = path_len(S_ISDIR(mode), basepath, prefix, path);
- if (namelen > 500)
- die("tar-tree: name too log of object %s\n", sha1_to_hex(sha1));
- else if (namelen > 100)
+ if (namelen > 100)
ext_header |= EXT_HEADER_PATH;
if (typeflag == TYPEFLAG_LNK && size > 100)
ext_header |= EXT_HEADER_LINKPATH;
^ permalink raw reply
* Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES
From: Junio C Hamano @ 2005-05-07 0:24 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <2637.10.10.10.24.1115425225.squirrel@linux1>
>>>>> "S" == Sean <seanlkml@sympatico.ca> writes:
S> has_sha1_file can be reduced to:
S> int has_sha1_file(const unsigned char *sha1)
S> {
S> return (!!find_sha1_file(sha1));
S> }
Not really. If you do not have alternates it does not even
bother to stat so you get the path that supposed to contain the
data and you need to do the checking yourself.
^ permalink raw reply
* Re: [PATCH] Introduce SHA1_FILE_DIRECTORIES
From: Sean @ 2005-05-07 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vmzr8apxc.fsf@assigned-by-dhcp.cox.net>
On Fri, May 6, 2005 7:35 pm, Junio C Hamano said:
Hi Junio,
> This is an implementation of the idea floated on the GIT list a couple
> of days ago to archive really old history on a separate directory, even
> on a read-only DVD ROM media.
David Lang should get the credit for the idea.
> int has_sha1_file(const unsigned char *sha1)
> {
> - char *filename = sha1_file_name(sha1);
> struct stat st;
> + char *filename = find_sha1_file(sha1);
> + if (!filename)
> + return 0;
>
> if (!stat(filename, &st))
> return 1;
has_sha1_file can be reduced to:
int has_sha1_file(const unsigned char *sha1)
{
return (!!find_sha1_file(sha1));
}
Sean
^ permalink raw reply
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