* Re: comparing file contents in is_exact_match?
From: Yakov Lerner @ 2006-07-18 9:15 UTC (permalink / raw)
Cc: git
In-Reply-To: <17596.4771.377000.843941@lapjr.intranet.kiel.bmiag.de>
On 7/17/06, Juergen Ruehle <j.ruehle@bmiag.de> wrote:
> Yakov Lerner writes:
> > On me, it failed me on git-apply with more than 1 patches on
> > the commandline.
> >
> > git-apply with 1 patch on the commandline passed, with two, failed.
> >
> > git-apply with two patches on commandline is the simplest
> > testcase that exposes this problem, AFAIK.
>
> In that case tests 4109 and 4110 should fail, shouldn't they? They
> succed for me on NTFS (and fail on other FS).
Mine FAT32 FS.
Yakov
> But anyway, I did some
> quick performance check and the NO_MMAP code path seems to be as fast
> as the mmap one (even much faster in some cases). So the combination
> of windows' memory management and git mmap usage doesn't seem so hot
> (especially considering the fact that git runs about twice as fast on
> FAT32 for me).
Yakov
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Yakov Lerner @ 2006-07-18 9:38 UTC (permalink / raw)
Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607171431010.2478@evo.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> Well, the thing is, you really _do_ want to mmap as much as possible of
> the pack-file as possible, if mmap() works.
Juergen Ruehle <j.ruehle@bmiag.de> wrote:
> I did some
> quick performance check and the NO_MMAP code path seems to be as fast
> as the mmap one (even much faster in some cases). So the combination
> of windows' memory management and git mmap usage doesn't seem so hot
How about making this parameter (do-use-mmap vs not-use-mmap)
a *runtime* parameter ? (Env. var. $GIT_MMAP or $GIT_USE_MMAP ?).
What do you think ? I see two benefits:
(1) much easier to benchmark two methods against each other
(2) will always work on cygwin (automatic fallback to working
method at runtime; say depending on filesystem)
What do you say ? (Only in case when MMAP is enabled at build-time, of course)
Yakov
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Johannes Schindelin @ 2006-07-18 10:20 UTC (permalink / raw)
To: Yakov Lerner
Cc: no To-header on input <""@pop.gmx.net>,
Git Mailing List
In-Reply-To: <f36b08ee0607180238i34cde4deib17426f121ae269e@mail.gmail.com>
Hi,
On Tue, 18 Jul 2006, Yakov Lerner wrote:
> How about making this parameter (do-use-mmap vs not-use-mmap)
> a *runtime* parameter ? (Env. var. $GIT_MMAP or $GIT_USE_MMAP ?).
> What do you think ? I see two benefits:
> (1) much easier to benchmark two methods against each other
You will benchmark it only once, right? No need to have this in git for
one-time use.
> (2) will always work on cygwin (automatic fallback to working
> method at runtime; say depending on filesystem)
I think it is too complicated to depend on the filesystem, and too system
specific (but hey, those who submit a patch are more right than
others...).
But an automatic fallback is not feasible: you would try to mmap(), and it
would throw an "Access violation", which is MS speak for "Segmentation
fault".
Besides, if you would be able to detect a failed mmap(), it would be too
late: the rename() or unlink() would already have taken place.
Ciao,
Dscho
^ permalink raw reply
* print errors from git-update-ref
From: Alex Riesen @ 2006-07-18 13:13 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
...otherwise it not clear what happened when update-ref fails.
E.g., git checkout -b a/b/c HEAD would print nothing if refs/heads/a
exists and is a directory (it does return 1, so scripts checking for
return code should be ok).
I'm attaching two patches, because I'm not quite sure where it should
be done: git-checkout is the least intrusive, but only builtin-update-ref.c
has enough info to help user to resolve the problem (errno is ENOTDIR,
which is selfexplanatory). And I happen to use git-update-ref directly
sometimes.
[-- Attachment #2: 0001-update-ref-print-errors-otherwise-it-not-clear-what-happened.txt --]
[-- Type: text/plain, Size: 1049 bytes --]
From 5398f0ee6bab039701912fdaf784792f4cf76afe Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 18 Jul 2006 14:52:15 +0200
Subject: [PATCH] update-ref: print errors
otherwise it not clear what happened
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-update-ref.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/builtin-update-ref.c b/builtin-update-ref.c
index 83094ab..ad4a44d 100644
--- a/builtin-update-ref.c
+++ b/builtin-update-ref.c
@@ -50,10 +50,14 @@ int cmd_update_ref(int argc, const char
die("%s: not a valid old SHA1", oldval);
lock = lock_any_ref_for_update(refname, oldval ? oldsha1 : NULL, 0);
- if (!lock)
+ if (!lock) {
+ error("%s: %s", refname, strerror(errno));
return 1;
- if (write_ref_sha1(lock, sha1, msg) < 0)
+ }
+ if (write_ref_sha1(lock, sha1, msg) < 0) {
+ error("%s: %s", refname, strerror(errno));
return 1;
+ }
/* write_ref_sha1 always unlocks the ref, no need to do it explicitly */
return 0;
--
1.4.2.rc1.g22734
[-- Attachment #3: 0001-git-checkout.sh-print-errors-otherwise-it-is-not-clear-what-happened.txt --]
[-- Type: text/plain, Size: 939 bytes --]
From 7ea3177aec909e333bacccd00693f223997e2613 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 18 Jul 2006 15:10:54 +0200
Subject: [PATCH] git-checkout.sh: print errors, otherwise it is not clear what happened
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
git-checkout.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index 5613bfc..7b335e5 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -198,7 +198,7 @@ if [ "$?" -eq 0 ]; then
mkdir -p $(dirname "$GIT_DIR/logs/refs/heads/$newbranch")
touch "$GIT_DIR/logs/refs/heads/$newbranch"
fi
- git-update-ref -m "checkout: Created from $new_name" "refs/heads/$newbranch" $new || exit
+ git-update-ref -m "checkout: Created from $new_name" "refs/heads/$newbranch" $new || die "failed to create branch $newbranch"
branch="$newbranch"
fi
[ "$branch" ] &&
--
1.4.2.rc1.g22734
^ permalink raw reply related
* Re: comparing file contents in is_exact_match?
From: Linus Torvalds @ 2006-07-18 15:37 UTC (permalink / raw)
To: Yakov Lerner; +Cc: Git Mailing List
In-Reply-To: <f36b08ee0607180238i34cde4deib17426f121ae269e@mail.gmail.com>
On Tue, 18 Jul 2006, Yakov Lerner wrote:
>
> How about making this parameter (do-use-mmap vs not-use-mmap)
> a *runtime* parameter ?
The thing is, there are really two different kinds of users, and one of
them in particular (the pack-file case) shouldn't have the problems under
Windows at all (because the pack-files aren't moved), and have a much
bigger reason to use mmap in the first place (because accesses will be
sparse, so reading the whole file is wasteful).
The other user was the index file, and _that_ one is the one that gets
renamed (to replace the previous index file), and that one is also not
ever read only partially, so using "read()" instead of mmap is much less
of an issue.
So I really think we should just basically always mmap the pack-files (it
should work everywhere), and make NO_MMAP just trigger on the other cases.
Linus
^ permalink raw reply
* [PATCH] upload-pack: fix timeout in create_pack_file
From: Matthias Lederhofer @ 2006-07-18 17:14 UTC (permalink / raw)
To: git
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
<yacc> fatal: packfile '../linux-2.6/.git/objects/pack/tmp-7iPJo5'
SHA1 mismatch
<yacc> error: git-fetch-pack: unable to read from git-index-pack
<yacc> error: git-index-pack died with error code 128
<yacc> Any idea what this means?
This happens after ~12 minutes. The problem is that the loop in
upload-pack.c actually sending the pack does not reset the timeout.
I'd guess --timeout is 600 or a bit more on git.kernel.org :)
This does not help for low timeouts with slow clients. If a client is
slow enough so the server is blocked for more time than specified by
timeout the connection will be closed too (e.g. 15kb/s with a timeout
of 30 (git adds 10 extra) is not enough). We should either add a
warning to the man page or try to fix this. I don't know if this can
be fixed not using non-blocking sockets.
Perhaps support for resume would be quite useful too but I've no idea
how hard this is to implement.
A workaround for is to pull a part of the repository first and the
rest later. For example using this:
$ git init-db
$ git fetch URL refs/tags/old-tag:refs/tags/old-tag
$ git fetch URL refs/tags/newer-tag:refs/tags/newer-tag
..
---
upload-pack.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index f6f5a7e..07ecdb4 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -182,6 +182,8 @@ static void create_pack_file(void)
ssize_t sz;
int pe, pu, pollsize;
+ reset_timeout();
+
pollsize = 0;
pe = pu = -1;
--
1.4.2.rc1.ge7a0
^ permalink raw reply related
* [PATCH] Fix t4114 on cygwin
From: Johannes Schindelin @ 2006-07-18 17:46 UTC (permalink / raw)
To: git, junkio
On cygwin, when you try to create a symlink over a directory, you do
not get EEXIST, but EACCES.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-apply.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 8f7cf44..d924ac3 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2034,7 +2034,7 @@ static void create_one_file(char *path,
return;
}
- if (errno == EEXIST) {
+ if (errno == EEXIST || errno == EACCES) {
/* We may be trying to create a file where a directory
* used to be.
*/
--
1.4.2.rc1.gaf40
^ permalink raw reply related
* Re: comparing file contents in is_exact_match?
From: Alex Riesen @ 2006-07-18 18:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Yakov Lerner, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607180837260.3386@evo.osdl.org>
On 7/18/06, Linus Torvalds <torvalds@osdl.org> wrote:
> So I really think we should just basically always mmap the pack-files (it
> should work everywhere), and make NO_MMAP just trigger on the other cases.
And while we are at it make a mental note about avoiding platforms with
broken mmap. For instance, QNX6 mmap with MAP_PRIVATE _always_
makes a copy of the whole! file, the stupid thing (they even documented it so!).
The alternative flag, MAP_SHARED, does not work on some filesystems at all.
^ permalink raw reply
* Re: Kernel headers git tree
From: Ingo Oeser @ 2006-07-18 21:15 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-kernel, git
In-Reply-To: <1152900971.3191.76.camel@pmac.infradead.org>
Hi David,
On Friday, 14. July 2006 20:16, David Woodhouse wrote:
> Well, they're all derived from commits in Linus' tree. I could set up
> another mailing list feed script which tracks it, but I'd like to give
> it a while (until I'm happy with the export scripts) first.
Sounds good :-)
Thanks & Regards
Ingo Oeser
^ permalink raw reply
* [PATCH] Allow an alias to start with "-p"
From: Johannes Schindelin @ 2006-07-18 23:25 UTC (permalink / raw)
To: git, junkio
Now, something like
[alias]
pd = -p diff
works as expected.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/git.c b/git.c
index 537af3a..a969b1b 100644
--- a/git.c
+++ b/git.c
@@ -115,6 +115,12 @@ static int handle_alias(int *argcp, cons
count = split_cmdline(alias_string, &new_argv);
+ if (count > 0 && !strcmp(new_argv[0], "-p")) {
+ setup_pager();
+ count--;
+ new_argv++;
+ }
+
if (count < 1)
die("empty alias for %s", alias_command);
--
1.4.1.g3c58e
^ permalink raw reply related
* :), oval-faced
From: Leona Battle @ 2006-07-19 6:56 UTC (permalink / raw)
To: git-commits-head-owner
Even if you have no erectin problems SOFT CIA2LIS
would help you to make BETTER SEQX MORE OFTEN!
and to bring unimagnable plesure to her.
Just disolve half a pil under your tongue
and get ready for action in 15 minutes.
The tests showed that the majority of men
after taking this medic ation were able to have
PERFECT ERLECTION during 36 hours!
VISIT US, AND GET OUR SPECIAL 70% DISC1OUNT OFER!
http://EMDAeaju1kk92gk7xwwp1ww7jeww.sowtede.com/
=====
flight - how to get from shore to food and back again. For most gulls, it
a shimmering, a trembling, sort of like hot air at noon over a tin roof. It
conversational idiom, through so formidable a barrier. Theodore Sturgeon San
After all, what can those toads do to me? He really didn't have to say
He climbed two thousand feet above the black sea, and without a
apart, either.
By the time he had pulled his beak straight up into the sky he was
fellows from PPS and left at the passageway. Everyone else was waiting, too.
^ permalink raw reply
* Re: Tracking CVS
From: Petr Baudis @ 2006-07-19 12:38 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606220717of2ba299ta8a38c7d63fd5635@mail.gmail.com>
Dear diary, on Thu, Jun 22, 2006 at 04:17:15PM CEST, I got a letter
where Jon Smirl <jonsmirl@gmail.com> said that...
> On 6/22/06, Petr Baudis <pasky@suse.cz> wrote:
> >Dear diary, on Thu, Jun 22, 2006 at 02:41:16PM CEST, I got a letter
> >where Jon Smirl <jonsmirl@gmail.com> said that...
> >> I'm tracking cvs using this sequence.
> >>
> >> cvs update
> >> cg rm -a
> >> cg commit
> >> cg add -r .
> >> cg commit
> >>
> >> Is there a way to avoid the two commits? If you do the add with out
> >> the intervening commit it just adds the files back.
>
> How about a cg-sync? Tracking cvs (or other SCM) with git is probably
> a common activitiy while you try to convince the other CVS users to
> switch. It is probably worth a little write up in the readme on the
> best way to do it.
I have added and pushed out support for cg-add -a, now it should be
merely a matter of
cg-rm -a && cg-add -a
and I have documented that.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Problems using cg to clone Dave Millers repository
From: Panagiotis Issaris @ 2006-07-19 15:35 UTC (permalink / raw)
To: git; +Cc: davem
Hi,
I'm having trouble cloning Dave Millers kernel repository:
takis@issaris:/tmp/a$ cg-clone
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
defaulting to local storage area
Fetching pack (head and objects)...
fatal: unable to connect a socket (Connection refused)
cg-fetch: fetching pack failed
takis@issaris:/tmp/a$ cg-clone
http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
defaulting to local storage area
Fetching head...
Fetching objects...
Getting alternates list for
http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/
Also look at http://kernel.or
error: Couldn't resolve host 'kernel.orobjects' (curl_result = 6,
http_code = 0, sha1 = ae1237750a9178b81d61308f9228f4f92a7402b2)
Getting pack list for
http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/
Getting pack list for http://kernel.or
error: Couldn't resolve host 'kernel.or'
error: Unable to find 27fd37621255799602d74e94d670ff7a1658d40a under
http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/
Cannot obtain needed blob 27fd37621255799602d74e94d670ff7a1658d40a
while processing commit 322045cc61d1dae9ff9e9ba2d7d4768fe1b3385d.
Waiting for
http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/objects/d3/a269671c4c20a942bda04579d8d0e6ebf82c73
progress: 8 objects, 6468 bytes
cg-fetch: objects fetch failed
takis@issaris:/tmp/a$ git clone
http://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?
takis@issaris:/tmp/a$ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
fatal: unable to connect a socket (Connection refused)
fetch-pack from
'git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git' failed.
With friendly regards,
Takis
^ permalink raw reply
* Re: Problems using cg to clone Dave Millers repository
From: Panagiotis Issaris @ 2006-07-19 15:55 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git, davem
In-Reply-To: <44BE5143.70005@uhasselt.be>
Hi,
Just wanted to add, that cloning Torvalds' tree works:
takis@issaris:/tmp/a$ cg-clone
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
defaulting to local storage area
Fetching head...
Fetching objects...
Getting alternates list for
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Getting pack list for
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Getting index for pack 1d309de746f2b624d754622834d93b394bf43488
progress: 0 objects, 1660856 bytes, now fetching 1d309de746f2...
(1660856 bytes)
Panagiotis Issaris wrote:
> [...]
>
> takis@issaris:/tmp/a$ cg-clone
> http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
> defaulting to local storage area
> Fetching head...
> Fetching objects...
> Getting alternates list for
> http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/
> Also look at http://kernel.or
> error: Couldn't resolve host 'kernel.orobjects' (curl_result = 6,
> http_code = 0, sha1 = ae1237750a9178b81d61308f9228f4f92a7402b2)
> Getting pack list for
> http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/
> Getting pack list for http://kernel.or
> error: Couldn't resolve host 'kernel.or'
> error: Unable to find 27fd37621255799602d74e94d670ff7a1658d40a under
> http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/
> Cannot obtain needed blob 27fd37621255799602d74e94d670ff7a1658d40a
> while processing commit 322045cc61d1dae9ff9e9ba2d7d4768fe1b3385d.
> Waiting for
> http://kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/objects/d3/a269671c4c20a942bda04579d8d0e6ebf82c73
>
> progress: 8 objects, 6468 bytes
> cg-fetch: objects fetch failed
> [...]
With friendly regards,
Takis
^ permalink raw reply
* Never-seen But without any results… Delight in
From: Gabriela @ 2006-07-19 18:50 UTC (permalink / raw)
To: godard
Hello!
Have more success with women and impress them with your power and stamina in bed
You are just a couple of clicks away from our great prices and handy shipment
Most trusted brands of the world, join the thousands of happy customers
Come on in: http://www.hanchbi.com
The quality is realt high and the prices are the cheapest on the market!
^ permalink raw reply
* [PATCH] git-am: Don't accept an mbox on stdin of we already have a .dotest directory
From: Lukas Sandström @ 2006-07-19 20:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
It makes no sense to accept an mbox via stdin when we
won't accept it on the commandline.
The patch helps the following scenario:
# git init-db
"add file1 with content"
# git checkout -b apply
"edit file1 && commit"
# git checkout -b conflict master
"edit file1 && commit"
# git checkout -b ok master
"add file2"
# git checkout apply
# git format-patch -k -3 master..conflict | git am -k -3
=> git-am fails with a conflict message
# git reset --hard
# git format-patch -k -3 master..ok | git am -k -3
=> git am fails with the same conflict message as above,
=> since it's trying to apply the old .dotest directory
With the patch it complains about an old .dotest
directory instead.
git-am.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 3a129e0..04f0119 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -156,8 +156,10 @@ fi
if test -d "$dotest"
then
- test ",$#," = ",0," ||
- die "previous dotest directory $dotest still exists but mbox given."
+ if test ",$#," != ",0," || ! tty -s
+ then
+ die "previous dotest directory $dotest still exists but mbox given."
+ fi
resume=yes
else
# Make sure we are not given --skip nor --resolved
--
1.4.1.g59817
^ permalink raw reply related
* [PATCH] tar-tree: add the "tar.applyUmask" config option
From: Willy Tarreau @ 2006-07-19 21:40 UTC (permalink / raw)
To: Junio C Hamano, Rene Scharfe; +Cc: git, torvalds
Hi Junio, Hi Rene,
While I agreed with Linus that the very permissive file modes set in tar
archives were not particularly a problem for kernel users, I'm finding
that for some other projects it sometimes becomes really annoying, to
the point that I finally considered using a plain tar instead. This is a
shame because tar-tree is really fast an powerful, and I like its ability
to enforce permissions when those of the local dir might be wrong for
various reasons.
So I added a config option to tell tar-tree to respect the user's umask
to the files and dirs listed in the output tar file. By default, this
option is not set, of course, but once set to true, the files look somewhat
better :
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
[tar]
applyUmask = true
$ ./git-tar-tree HEAD | tar tvf -|head
-rw-r--r-- git/git 1887 2006-07-19 23:23:00 .gitignore
-rw-r--r-- git/git 18787 2006-07-19 23:23:00 COPYING
drwxr-xr-x git/git 0 2006-07-19 23:23:00 Documentation/
-rw-r--r-- git/git 52 2006-07-19 23:23:00 Documentation/.gitignore
-rw-r--r-- git/git 2463 2006-07-19 23:23:00 Documentation/Makefile
-rw-r--r-- git/git 11550 2006-07-19 23:23:00 Documentation/SubmittingPatches
-rw-r--r-- git/git 822 2006-07-19 23:23:00 Documentation/asciidoc.conf
-rwxr-xr-x git/git 1049 2006-07-19 23:23:00 Documentation/build-docdep.perl
-rw-r--r-- git/git 596 2006-07-19 23:23:00 Documentation/callouts.xsl
Let me insist on the fact that the default behaviour is unchanged.
Would you consider this for inclusion ? I've made the patch below
against <master>. Please check on your side that the doc generates
valid output, as I've never managed to install the asciidoc/xmlto
toolchain.
Please keep me CCed in replies as I'm not subscribed to the git list.
Regards,
Willy
--
>From dcc976d83c3b9c85460329932ce22547b7f5f3f9 Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w@1wt.eu>
Date: Wed, 19 Jul 2006 23:23:00 +0200
Subject: tar-tree: add the "tar.applyUmask" config option
For some projects, producing tar files with world-writable files
can be problematic. This change introduces a the "tar.applyUmask"
config option to make tar-tree apply the umask to the permissions
set in the tar file.
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/config.txt | 9 +++++++++
builtin-tar-tree.c | 19 ++++++++++++++++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0b434c1..32519a9 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -208,6 +208,15 @@ showbranch.default::
The default set of branches for gitlink:git-show-branch[1].
See gitlink:git-show-branch[1].
+tar.applyUmask::
+ By default, git-link:git-tar-tree[1] sets file and directories modes
+ to 0666 or 0777. While this is both useful and acceptable for projects
+ such as the Linux Kernel, it might be excessive for other projects.
+ Setting this variable to true makes git-link:git-tar-tree[1] apply the
+ umask to the modes above. This should be enough for most projects, as
+ it will lead to the same permissions as git-link:git-checkout[1] would
+ use. The default is false.
+
user.email::
Your email address to be recorded in any newly created commits.
Can be overridden by the 'GIT_AUTHOR_EMAIL' and 'GIT_COMMITTER_EMAIL'
diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
index f2e48aa..f66f6ad 100644
--- a/builtin-tar-tree.c
+++ b/builtin-tar-tree.c
@@ -20,6 +20,7 @@ static char block[BLOCKSIZE];
static unsigned long offset;
static time_t archive_time;
+static int tar_umask;
/* tries hard to write, either succeeds or dies in the attempt */
static void reliable_write(const void *data, unsigned long size)
@@ -188,13 +189,13 @@ static void write_entry(const unsigned c
} else {
if (S_ISDIR(mode)) {
*header.typeflag = TYPEFLAG_DIR;
- mode |= 0777;
+ mode |= 0777 & ~tar_umask;
} else if (S_ISLNK(mode)) {
*header.typeflag = TYPEFLAG_LNK;
mode |= 0777;
} else if (S_ISREG(mode)) {
*header.typeflag = TYPEFLAG_REG;
- mode |= (mode & 0100) ? 0777 : 0666;
+ mode |= ((mode & 0100) ? 0777 : 0666) & ~tar_umask;
} else {
error("unsupported file mode: 0%o (SHA1: %s)",
mode, sha1_to_hex(sha1));
@@ -293,6 +294,18 @@ static void traverse_tree(struct tree_de
}
}
+int git_tar_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "tar.applyumask")) {
+ if (git_config_bool(var, value)) {
+ tar_umask = umask(0);
+ umask(tar_umask);
+ }
+ return 0;
+ }
+ return git_default_config(var, value);
+}
+
static int generate_tar(int argc, const char **argv, char** envp)
{
unsigned char sha1[20], tree_sha1[20];
@@ -305,7 +318,7 @@ static int generate_tar(int argc, const
current_path.len = current_path.eof = 0;
setup_git_directory();
- git_config(git_default_config);
+ git_config(git_tar_config);
switch (argc) {
case 3:
--
1.4.1
^ permalink raw reply related
* Re: [PATCH] tar-tree: add the "tar.applyUmask" config option
From: Junio C Hamano @ 2006-07-19 22:33 UTC (permalink / raw)
To: Willy Tarreau; +Cc: git
In-Reply-To: <20060719214025.GA10997@1wt.eu>
Willy Tarreau <w@1wt.eu> writes:
> While I agreed with Linus that the very permissive file modes set in tar
> archives were not particularly a problem for kernel users, I'm finding
> that for some other projects it sometimes becomes really annoying, to
> the point that I finally considered using a plain tar instead. This is a
> shame because tar-tree is really fast an powerful, and I like its ability
> to enforce permissions when those of the local dir might be wrong for
> various reasons.
I do not have problem with an option to allow a non-default
behaviour in this area. Maybe we might want to be able to set
the mask in the configuration file as well, perhaps like...
tar.umask = user ;# use from the current process'
tar.umask = 0 ;# same as default
tar.umask = 002 ;# group friendly
^ permalink raw reply
* Re: [PATCH] tar-tree: add the "tar.applyUmask" config option
From: Johannes Schindelin @ 2006-07-19 22:39 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Junio C Hamano, Rene Scharfe, git, torvalds
In-Reply-To: <20060719214025.GA10997@1wt.eu>
Hi,
while at it, you could ask an explicit "--umask=<n>" flag, no?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] tar-tree: add the "tar.applyUmask" config option
From: Willy Tarreau @ 2006-07-19 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5c1jkc3.fsf@assigned-by-dhcp.cox.net>
On Wed, Jul 19, 2006 at 03:33:48PM -0700, Junio C Hamano wrote:
> Willy Tarreau <w@1wt.eu> writes:
>
> > While I agreed with Linus that the very permissive file modes set in tar
> > archives were not particularly a problem for kernel users, I'm finding
> > that for some other projects it sometimes becomes really annoying, to
> > the point that I finally considered using a plain tar instead. This is a
> > shame because tar-tree is really fast an powerful, and I like its ability
> > to enforce permissions when those of the local dir might be wrong for
> > various reasons.
>
> I do not have problem with an option to allow a non-default
> behaviour in this area. Maybe we might want to be able to set
> the mask in the configuration file as well, perhaps like...
>
> tar.umask = user ;# use from the current process'
> tar.umask = 0 ;# same as default
> tar.umask = 002 ;# group friendly
This is an excellent idea. I will try to find some spare time tomorrow
to implement it. I've also seen the proposal about the --umask= option.
I don't think it's absolutely necessary since the umask has little reason
to change during the repo's life, but if the implementation is obvious,
I will do it too.
Thanks for your suggestion,
Willy
^ permalink raw reply
* Git BOF notes
From: Petr Baudis @ 2006-07-19 23:01 UTC (permalink / raw)
To: git
Hi,
a short summary of the Git BOF on OLS which finished just a short
while ago. We got to hear how Len Brown is doing things and where Git
gets in the way for him as well as interesting questions and comments
from several other people. The main highlights as I feel them (mixed
randomly with my personal blabbering) are that:
(i) We should somehow separate the lowlevel Git commands from the
highlevel ones meant for user consumption. There's too many of them
and it is confusing for the users. Similarity with BitKeeper was pointed
out (and I refrained from mentioning GNU Arch).
(ii) We should document the workflows better. Currently there is a
huge variety of workflows spread accross the Git user community,
probably stemming from the fact that the UI evolved so fast while
already "on the fly". Of course it shows that the Git tools are
really flxible and versatile, but it might also mean that we are not
abstracting some operations enough, or not selling the easier user
interface better. Anyway, new users might find the current mix of
workflows used across the community somewhat intimidating. This also
means that....
(iii) ...we should spread the word about StGIT more (because StGIT
is cool and often does just what people want to do with Git and it's
clumsy), more so because...
(iv) ...we should support mutating history better (I think this is the
most important point). There is a kind of conflict here:
* Fundamentally, Git considers history to be immutable,
especially if you publish it.
* The kernel workflow encourages the opposite - the subsystem
maintainers are rebasing all the time as well as just
generally retouching their history (typos, fixing bugs in
the patches etc).
This problem can be separated to two areas:
* Support for the history mutation. We have some nice tools
in Git for rebasing, but it would be nice to support the
other modifications easier as well. I suggested having
a tool you just tell a commit id and it will let you modify
the author info, the associated patch or fold another patch
in... Also, using StGIT obviously hlps a lot here.
* Support for distributing and following the mutated history.
I'm actually not sure about the level of Git support for
this, Cogito supports cg-updating to a mutated history
if you have no local changes.
Please feel free to add things if I have missed anything.
Happy hacking,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* git-svn: Missing files
From: Ben Williamson @ 2006-07-20 2:02 UTC (permalink / raw)
To: git
Hi all,
I'm probably confused, but it seems like git-svn has missed some files
while importing the buildroot sources. I did this:
git-svn init svn://uclibc.org/trunk/buildroot
git-svn fetch
Then I used gitk to find the revision corresponding to svn's r15711,
and checked that out:
git-checkout -b test c84f9463b67bdb57c93bec571b1118b37cb597ce
commit c84f9463b67bdb57c93bec571b1118b37cb597ce
Author: vapier <vapier@69ca8d6d-28ef-0310-b511-8ec308f3f277>
Date: Mon Jul 17 03:53:12 2006 +0000
fix whitespace
git-svn-id: svn://uclibc.org/trunk/buildroot@15711
69ca8d6d-28ef-0310-b511-8ec308f3f277
The resulting tree is missing a bunch of files, compared to what I
checked out with svn:
svn export -r15711 svn://uclibc.org/trunk/buildroot buildroot
Also, if I use git-svn to only fetch r15711 then I get what I expect,
with no missing files. The tree is the same as the 'svn export' minus
a few empty directories:
git-svn init svn://uclibc.org/trunk/buildroot
git-svn fetch -r15711
I've listed the missing files below. There are no other differences -
all the files that did turn up are identical in all three trees ("svn
export", "git-svn fetch" and "git-svn fetch -r15711").
Disclaimer: I'm no subversion expert, and I'm fairly new to git. But
git rocks, and I'd love somewhere to locally commit my hacks to
subversion projects like buildroot.
Thanks!
- Ben.
diff -ur --exclude .git svn-export/buildroot git-svn-fetch-all/buildroot
Only in svn-export/buildroot/package: linux
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
003_kbuild_fixes.diff.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
004_386_emu.diff.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
005_modularize_vesafb.diff.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
006_init_unshare.diff.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
008-ieee1394-fix.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
009-always-inline.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
010-optimize-for-size.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
012-x86-check_gcc.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
015_cramfs_initrd.diff.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
017-printk.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
018-slab-loop-init.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
041-changeloop.patch.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
042-loopfixes.patch.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
062-silence-blk-queue.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
063-silence.kbd.patch.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
064-shutup-md.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
076-nmap-freak.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
077-orinoco-0.13e.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
078-hostap.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
079-jiffies64.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
089-no-touch-makedep.bz2
Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
100_VERSION.bz2
Only in svn-export/buildroot/target/generic: access_point
Only in svn-export/buildroot/target/generic: firewall
Only in svn-export/buildroot/target/generic/target_skeleton/etc: fstab
Only in svn-export/buildroot/target/generic/target_skeleton/etc: hostname
Only in svn-export/buildroot/target/generic/target_skeleton/etc: hosts
Only in svn-export/buildroot/target/generic/target_skeleton/etc/init.d: rcS
Only in svn-export/buildroot/target/generic/target_skeleton/etc/init.d:
S40network
Only in svn-export/buildroot/target/generic/target_skeleton/etc: inittab
Only in svn-export/buildroot/target/generic/target_skeleton/etc: inputrc
Only in svn-export/buildroot/target/generic/target_skeleton/etc: issue
Only in svn-export/buildroot/target/generic/target_skeleton/etc: network
Only in svn-export/buildroot/target/generic/target_skeleton/etc: passwd
Only in svn-export/buildroot/target/generic/target_skeleton/etc: profile
Only in svn-export/buildroot/target/generic/target_skeleton/etc: protocols
Only in svn-export/buildroot/target/generic/target_skeleton/etc: random-seed
Only in svn-export/buildroot/target/generic/target_skeleton/etc: securetty
Only in svn-export/buildroot/target/generic/target_skeleton/etc: services
Only in svn-export/buildroot/target/generic/target_skeleton/etc: shadow
Only in svn-export/buildroot/target/generic/target_skeleton/etc: TZ
Only in svn-export/buildroot/target/generic/target_skeleton: root
Only in svn-export/buildroot/target/generic/target_skeleton: usr
Only in svn-export/buildroot/toolchain/binutils: 2.16.91.0.6
Only in svn-export/buildroot/toolchain/binutils/2.16.91.0.7:
300-001_ld_makefile_patch.patch
Only in svn-export/buildroot/toolchain/binutils/2.16.91.0.7:
300-006_better_file_error.patch
Only in svn-export/buildroot/toolchain/binutils/2.16.91.0.7:
300-012_check_ldrunpath_length.patch
Only in svn-export/buildroot/toolchain/binutils/2.16.91.0.7:
400-mips-ELF_MAXPAGESIZE-4K.patch
Only in svn-export/buildroot/toolchain/binutils/2.16.91.0.7:
702-binutils-skip-comments.patch
Only in svn-export/buildroot/toolchain/binutils: 2.17
Only in svn-export/buildroot/toolchain/binutils: 2.17.50.0.2
Only in svn-export/buildroot/toolchain/binutils: 2.17.50.0.3
Only in svn-export/buildroot/toolchain/gcc/3.4.6: 100-uclibc-conf.patch
Only in svn-export/buildroot/toolchain/gcc/3.4.6: 200-uclibc-locale.patch
Only in svn-export/buildroot/toolchain/gcc/3.4.6: 300-libstdc++-pic.patch
Only in svn-export/buildroot/toolchain/gcc/3.4.6:
600-gcc34-arm-ldm-peephole.patch
Only in svn-export/buildroot/toolchain/gcc/3.4.6: 601-gcc34-arm-ldm.patch
Only in svn-export/buildroot/toolchain/gcc/3.4.6:
601-gcc34-arm-ldm-peephole2.patch
Only in svn-export/buildroot/toolchain/gcc/3.4.6:
602-sdk-libstdc++-includes.patch
Only in svn-export/buildroot/toolchain/gcc/3.4.6: 700-pr15068-fix.patch
Only in svn-export/buildroot/toolchain/gcc/3.4.6: 71_all_sh-pr16665-fix.patch
Only in svn-export/buildroot/toolchain/gcc/3.4.6:
72_all_sh-no-reorder-blocks.patch
Only in svn-export/buildroot/toolchain/gcc/3.4.6: 73_all_sh-pr20617.patch
Only in svn-export/buildroot/toolchain/gcc/3.4.6:
800-powerpc-libc_stack_end-uclibc.patch
Only in svn-export/buildroot/toolchain/gcc/3.4.6: 900-nios2.patch
Only in svn-export/buildroot/toolchain/gcc/3.4.6:
arm-softfloat.patch.conditional
Only in svn-export/buildroot/toolchain/gcc/4.0.3: 100-uclibc-conf.patch
Only in svn-export/buildroot/toolchain/gcc/4.0.3: 200-uclibc-locale.patch
Only in svn-export/buildroot/toolchain/gcc/4.0.3: 300-libstdc++-pic.patch
Only in svn-export/buildroot/toolchain/gcc/4.0.3: 301-missing-execinfo_h.patch
Only in svn-export/buildroot/toolchain/gcc/4.0.3: 302-c99-snprintf.patch
Only in svn-export/buildroot/toolchain/gcc/4.0.3:
303-c99-complex-ugly-hack.patch
Only in svn-export/buildroot/toolchain/gcc/4.0.3:
602-sdk-libstdc++-includes.patch
Only in svn-export/buildroot/toolchain/gcc/4.1.1: 100-uclibc-conf.patch
Only in svn-export/buildroot/toolchain/gcc/4.1.1: 301-missing-execinfo_h.patch
Only in svn-export/buildroot/toolchain/gcc/4.1.1: 302-c99-snprintf.patch
Only in svn-export/buildroot/toolchain/gcc/4.1.1:
303-c99-complex-ugly-hack.patch
Only in svn-export/buildroot/toolchain/gcc/4.1.1: 304-index_macro.patch
Only in svn-export/buildroot/toolchain/gcc/4.1.1: 740-sh-pr24836.patch
Only in svn-export/buildroot/toolchain/gcc/4.1.1: 800-arm-bigendian.patch
Only in svn-export/buildroot/toolchain/gcc/4.2: 103-uclibc-conf-noupstream.patch
Only in svn-export/buildroot/toolchain/gcc/4.2: 203-uclibc-locale-no__x.patch
Only in svn-export/buildroot/toolchain/gcc/4.2:
204-uclibc-locale-wchar_fix.patch
Only in svn-export/buildroot/toolchain/gcc/4.2: 301-missing-execinfo_h.patch
Only in svn-export/buildroot/toolchain/gcc/4.2: 302-c99-snprintf.patch
Only in svn-export/buildroot/toolchain/gcc/4.2: 303-c99-complex-ugly-hack.patch
Only in svn-export/buildroot/toolchain/gdb: 6.5
^ permalink raw reply
* Re: git-svn: Missing files
From: Ben Williamson @ 2006-07-20 2:09 UTC (permalink / raw)
To: git
In-Reply-To: <b6327a230607191902n47b81993x8caea2df3955d8c0@mail.gmail.com>
Oh. I just looked in git-svn and found this:
$VERSION = '1.1.1-broken';
Fair enough. So far I haven't explored other branches in git.git, I've
no idea what "pu" stands for. Can someone point me in the right
direction?
Thanks,
- Ben.
On 7/20/06, Ben Williamson <benw@pobox.com> wrote:
> Hi all,
>
> I'm probably confused, but it seems like git-svn has missed some files
> while importing the buildroot sources. I did this:
>
> git-svn init svn://uclibc.org/trunk/buildroot
> git-svn fetch
>
> Then I used gitk to find the revision corresponding to svn's r15711,
> and checked that out:
>
> git-checkout -b test c84f9463b67bdb57c93bec571b1118b37cb597ce
>
> commit c84f9463b67bdb57c93bec571b1118b37cb597ce
> Author: vapier <vapier@69ca8d6d-28ef-0310-b511-8ec308f3f277>
> Date: Mon Jul 17 03:53:12 2006 +0000
>
> fix whitespace
>
> git-svn-id: svn://uclibc.org/trunk/buildroot@15711
> 69ca8d6d-28ef-0310-b511-8ec308f3f277
>
> The resulting tree is missing a bunch of files, compared to what I
> checked out with svn:
>
> svn export -r15711 svn://uclibc.org/trunk/buildroot buildroot
>
> Also, if I use git-svn to only fetch r15711 then I get what I expect,
> with no missing files. The tree is the same as the 'svn export' minus
> a few empty directories:
>
> git-svn init svn://uclibc.org/trunk/buildroot
> git-svn fetch -r15711
>
> I've listed the missing files below. There are no other differences -
> all the files that did turn up are identical in all three trees ("svn
> export", "git-svn fetch" and "git-svn fetch -r15711").
>
> Disclaimer: I'm no subversion expert, and I'm fairly new to git. But
> git rocks, and I'd love somewhere to locally commit my hacks to
> subversion projects like buildroot.
>
> Thanks!
>
> - Ben.
>
>
> diff -ur --exclude .git svn-export/buildroot git-svn-fetch-all/buildroot
> Only in svn-export/buildroot/package: linux
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 003_kbuild_fixes.diff.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 004_386_emu.diff.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 005_modularize_vesafb.diff.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 006_init_unshare.diff.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 008-ieee1394-fix.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 009-always-inline.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 010-optimize-for-size.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 012-x86-check_gcc.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 015_cramfs_initrd.diff.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 017-printk.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 018-slab-loop-init.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 041-changeloop.patch.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 042-loopfixes.patch.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 062-silence-blk-queue.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 063-silence.kbd.patch.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 064-shutup-md.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 076-nmap-freak.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 077-orinoco-0.13e.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 078-hostap.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 079-jiffies64.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 089-no-touch-makedep.bz2
> Only in svn-export/buildroot/target/device/Soekris/net4521/kernel-patches:
> 100_VERSION.bz2
> Only in svn-export/buildroot/target/generic: access_point
> Only in svn-export/buildroot/target/generic: firewall
> Only in svn-export/buildroot/target/generic/target_skeleton/etc: fstab
> Only in svn-export/buildroot/target/generic/target_skeleton/etc: hostname
> Only in svn-export/buildroot/target/generic/target_skeleton/etc: hosts
> Only in svn-export/buildroot/target/generic/target_skeleton/etc/init.d: rcS
> Only in svn-export/buildroot/target/generic/target_skeleton/etc/init.d:
> S40network
> Only in svn-export/buildroot/target/generic/target_skeleton/etc: inittab
> Only in svn-export/buildroot/target/generic/target_skeleton/etc: inputrc
> Only in svn-export/buildroot/target/generic/target_skeleton/etc: issue
> Only in svn-export/buildroot/target/generic/target_skeleton/etc: network
> Only in svn-export/buildroot/target/generic/target_skeleton/etc: passwd
> Only in svn-export/buildroot/target/generic/target_skeleton/etc: profile
> Only in svn-export/buildroot/target/generic/target_skeleton/etc: protocols
> Only in svn-export/buildroot/target/generic/target_skeleton/etc: random-seed
> Only in svn-export/buildroot/target/generic/target_skeleton/etc: securetty
> Only in svn-export/buildroot/target/generic/target_skeleton/etc: services
> Only in svn-export/buildroot/target/generic/target_skeleton/etc: shadow
> Only in svn-export/buildroot/target/generic/target_skeleton/etc: TZ
> Only in svn-export/buildroot/target/generic/target_skeleton: root
> Only in svn-export/buildroot/target/generic/target_skeleton: usr
> Only in svn-export/buildroot/toolchain/binutils: 2.16.91.0.6
> Only in svn-export/buildroot/toolchain/binutils/2.16.91.0.7:
> 300-001_ld_makefile_patch.patch
> Only in svn-export/buildroot/toolchain/binutils/2.16.91.0.7:
> 300-006_better_file_error.patch
> Only in svn-export/buildroot/toolchain/binutils/2.16.91.0.7:
> 300-012_check_ldrunpath_length.patch
> Only in svn-export/buildroot/toolchain/binutils/2.16.91.0.7:
> 400-mips-ELF_MAXPAGESIZE-4K.patch
> Only in svn-export/buildroot/toolchain/binutils/2.16.91.0.7:
> 702-binutils-skip-comments.patch
> Only in svn-export/buildroot/toolchain/binutils: 2.17
> Only in svn-export/buildroot/toolchain/binutils: 2.17.50.0.2
> Only in svn-export/buildroot/toolchain/binutils: 2.17.50.0.3
> Only in svn-export/buildroot/toolchain/gcc/3.4.6: 100-uclibc-conf.patch
> Only in svn-export/buildroot/toolchain/gcc/3.4.6: 200-uclibc-locale.patch
> Only in svn-export/buildroot/toolchain/gcc/3.4.6: 300-libstdc++-pic.patch
> Only in svn-export/buildroot/toolchain/gcc/3.4.6:
> 600-gcc34-arm-ldm-peephole.patch
> Only in svn-export/buildroot/toolchain/gcc/3.4.6: 601-gcc34-arm-ldm.patch
> Only in svn-export/buildroot/toolchain/gcc/3.4.6:
> 601-gcc34-arm-ldm-peephole2.patch
> Only in svn-export/buildroot/toolchain/gcc/3.4.6:
> 602-sdk-libstdc++-includes.patch
> Only in svn-export/buildroot/toolchain/gcc/3.4.6: 700-pr15068-fix.patch
> Only in svn-export/buildroot/toolchain/gcc/3.4.6: 71_all_sh-pr16665-fix.patch
> Only in svn-export/buildroot/toolchain/gcc/3.4.6:
> 72_all_sh-no-reorder-blocks.patch
> Only in svn-export/buildroot/toolchain/gcc/3.4.6: 73_all_sh-pr20617.patch
> Only in svn-export/buildroot/toolchain/gcc/3.4.6:
> 800-powerpc-libc_stack_end-uclibc.patch
> Only in svn-export/buildroot/toolchain/gcc/3.4.6: 900-nios2.patch
> Only in svn-export/buildroot/toolchain/gcc/3.4.6:
> arm-softfloat.patch.conditional
> Only in svn-export/buildroot/toolchain/gcc/4.0.3: 100-uclibc-conf.patch
> Only in svn-export/buildroot/toolchain/gcc/4.0.3: 200-uclibc-locale.patch
> Only in svn-export/buildroot/toolchain/gcc/4.0.3: 300-libstdc++-pic.patch
> Only in svn-export/buildroot/toolchain/gcc/4.0.3: 301-missing-execinfo_h.patch
> Only in svn-export/buildroot/toolchain/gcc/4.0.3: 302-c99-snprintf.patch
> Only in svn-export/buildroot/toolchain/gcc/4.0.3:
> 303-c99-complex-ugly-hack.patch
> Only in svn-export/buildroot/toolchain/gcc/4.0.3:
> 602-sdk-libstdc++-includes.patch
> Only in svn-export/buildroot/toolchain/gcc/4.1.1: 100-uclibc-conf.patch
> Only in svn-export/buildroot/toolchain/gcc/4.1.1: 301-missing-execinfo_h.patch
> Only in svn-export/buildroot/toolchain/gcc/4.1.1: 302-c99-snprintf.patch
> Only in svn-export/buildroot/toolchain/gcc/4.1.1:
> 303-c99-complex-ugly-hack.patch
> Only in svn-export/buildroot/toolchain/gcc/4.1.1: 304-index_macro.patch
> Only in svn-export/buildroot/toolchain/gcc/4.1.1: 740-sh-pr24836.patch
> Only in svn-export/buildroot/toolchain/gcc/4.1.1: 800-arm-bigendian.patch
> Only in svn-export/buildroot/toolchain/gcc/4.2: 103-uclibc-conf-noupstream.patch
> Only in svn-export/buildroot/toolchain/gcc/4.2: 203-uclibc-locale-no__x.patch
> Only in svn-export/buildroot/toolchain/gcc/4.2:
> 204-uclibc-locale-wchar_fix.patch
> Only in svn-export/buildroot/toolchain/gcc/4.2: 301-missing-execinfo_h.patch
> Only in svn-export/buildroot/toolchain/gcc/4.2: 302-c99-snprintf.patch
> Only in svn-export/buildroot/toolchain/gcc/4.2: 303-c99-complex-ugly-hack.patch
> Only in svn-export/buildroot/toolchain/gdb: 6.5
>
^ permalink raw reply
* Re: git-svn: Missing files
From: Eric Wong @ 2006-07-20 2:48 UTC (permalink / raw)
To: Ben Williamson; +Cc: git
In-Reply-To: <b6327a230607191909tf48c4f8nc551b732523cca3e@mail.gmail.com>
Ben Williamson <benw@pobox.com> wrote:
> Oh. I just looked in git-svn and found this:
>
> $VERSION = '1.1.1-broken';
I removed the version tag and started using GIT_VERSION when git-svn
moved out of contrib/ a few weeks ago.
As far as I remember, I don't remember git-svn having problems with
missing files. There has been a bug where it got extra files from other
places in the repository, but that's fixed.
May I ask if you have the Perl SVN:: library bindings installed? If so
1.1.1-broken (and all versions afterwards) will automatically. use them
(if the SVN library version is >= 1.1).
Nevertheless, I'm running an import right now (with the SVN:: libraries enabled)
and will make another run with them disabled (which is kind of slow).
I'll keep you posted...
I've actually been getting a lot of real-world git-svn usage in the past
few weeks (and hence the lack of git-related work) and haven't noticed
any major problems.
> Fair enough. So far I haven't explored other branches in git.git, I've
> no idea what "pu" stands for. Can someone point me in the right
> direction?
pu is "potential updates", it's very bleeding edge. next is a few steps
ahead of master, which should be the safest of the three.
--
Eric Wong
^ permalink raw reply
* Re: git-svn: Missing files
From: Eric Wong @ 2006-07-20 3:06 UTC (permalink / raw)
To: Ben Williamson; +Cc: git
In-Reply-To: <20060720024815.GC31763@localdomain>
Eric Wong <normalperson@yhbt.net> wrote:
> Ben Williamson <benw@pobox.com> wrote:
> > Oh. I just looked in git-svn and found this:
> >
> > $VERSION = '1.1.1-broken';
>
> Nevertheless, I'm running an import right now (with the SVN:: libraries enabled)
> and will make another run with them disabled (which is kind of slow).
> I'll keep you posted...
Ok, I think I've found the problem. This problem only happens if you're
using the SVN:: libraries, right?
--
Eric Wong
^ 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