* Re: Re: Re: Add "clone" support to lntree
From: Daniel Barkalow @ 2005-04-17 0:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050416233305.GO19099@pasky.ji.cz>
On Sun, 17 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sat, Apr 16, 2005 at 05:17:00AM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > On Sat, 16 Apr 2005, Petr Baudis wrote:
> >
> > > Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter
> > > where Petr Baudis <pasky@ucw.cz> told me that...
> > > > git branch --- creates a branch from a given commit
> > > > (when passed empty commit, creates a branch
> > > > from the current commit and sets the working
> > > > tree to that branch)
> > > > Note that there is a bug in current git update - it will allow you to
> > > > bring several of your trees to follow the same branch, or even a remote
> > > > branch. This is not even supposed to work, and will be fixed when I get
> > > > some sleep. You will be able to do git pull even on local branches, and
> > > > the proper solution for this will be just tracking the branch you want
> > > > to follow.
> > >
> > > I must admit that I'm not entirely decided yet, so I'd love to hear your
> > > opinion.
> > >
> > > I'm wondering, whether each tree should be fixed to a certain branch.
> > > That is, you decide a name when you do git fork, and then the tree
> > > always follows that branch. (It always has to follow [be bound to]
> > > *some* branch, and each branch can be followed by only a single tree at
> > > a time.)
> >
> > I don't think I'm following the use of branches. Currently, what I do is
> > have a git-pasky and a git-linus, and fork off a working directory from
> > one of these for each thing I want to work on. I do some work, commit as I
> > make progress, and then do a diff against the remote head to get a patch
> > to send off. If I want to do a series of patches which depend on each
> > other, I fork my next directory off of my previous one rather than off of
> > a remote base. I haven't done much rebasing, so I haven't worked out how I
> > would do that most effectively.
>
> Yes. And that's exactly what the branches allow you to do. You just do
>
> git fork myhttpclient ~/myhttpclientdir
>
> then you do some hacking, and when you have something usable, you can
> go back to your main working directory and do
>
> git merge -b when_you_started myhttpclient
>
> Since you consider the code perfect, you can now just rm -rf
> ~/myhttpclient.
>
> Suddenly, you get a mail from mj pointing out some bugs, and it looks
> like there are more to come. What to do?
>
> git fork myhttpclient ~/myhttpclientdir
>
> (Ok, this does not work, but that's a bug, will fix tomorrow.) This will
> let you take off when you left in your work on the branch.
Ah, I think that's what made me think I wasn't understanding branches; the
first thing I tried hit this big.
> git update for seeking between commits is probably extremely important
> for any kind of binary search when you are wondering when did this bug
> appeared first, or when you are exploring how certain branch evolved
> over time. Doing git fork for each successive iteration sounds horrible.
Even if there isn't a performance hit, it's semantically wrong, because
you're looking at different versions that were in the same place at
different times.
> Now, what about git branch and git update for switching between
> branches? I think this is the most controversial part; these are
> basically just shortcuts for not having to do git fork, and I wouldn't
> mind so much removing them, if you people really consider them too ugly
> a wart for the soft clean git skin. I admit that they both come from a
> hidden prejudice that git fork is going to be slow and eat a lot of
> disk.
I think that this just confuses matters.
> The idea for git update for switching between branches is that
> especially when you have two rather similar branches and mostly do stuff
> on one of them, but sometimes you want to do something on the other one,
> you can do just quick git update, do stuff, and git update back, without
> any forking.
I still think that fork should be quick enough, or you could leave the
extra tree around. I'm not against having such a command, but I think it
should be a separate command rather than a different use of update, since
it would be used by poeople working in different ways.
> > I think I can make this space efficient by hardlinking unmodified blobs to
> > a directory of cached expanded blobs.
>
> I don't know but I really feel *very* unsafe when doing that. What if
> something screws up and corrupts my base... way too easy. And it gets
> pretty inconvenient and even more dangerous when you get the idea to do
> some modifications on your tree by something else than your favorite
> editor (which you've already checked does the right thing).
It should only be an option, not required and maybe not even
default. I think it should be possible to prevent stuff from screwing up,
since we really don't want anything to ever modify those inodes (as
opposed to some cases, where you want to modify inodes only in certain
ways). For that matter, relatively few programs actually support
modifying inodes rather than unlinking.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Storing permissions
From: Paul Jackson @ 2005-04-17 0:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: mj, git
In-Reply-To: <7vk6n247cd.fsf@assigned-by-dhcp.cox.net>
Junio wrote:
> Sounds like svn
I have no idea what svn is.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: fix mktemp (remove mktemp ;)
From: Paul Jackson @ 2005-04-17 0:02 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, mj
In-Reply-To: <20050416233724.GP19099@pasky.ji.cz>
> And racy. And not guaranteed to come up with fresh new files.
In theory perhaps. In practice no.
Even mktemp(1) can collide, in theory, since there is no practical way
in shell scripts to hold open and locked the file from the instant of it
is determined to be a unique name.
The window of vulnerability for shell script tmp files is the lifetime
of the script - while the file sits there unlocked. Anyone else with
permissions can mess with it.
More people will fail, and are already failing, using mktemp than I have
ever seen using $$ (I've never seen a documented case, and since such
files are not writable to other user accounts, such a collision would
typically not go hidden.)
Fast, simple portable solutions that work win over solutions with some
theoretical advantage that don't matter in practice, but also that are
less portable or less efficient.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: [PATCH] Get commits from remote repositories by HTTP
From: Adam Kropelin @ 2005-04-16 22:52 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Tony Luck, git
In-Reply-To: <Pine.LNX.4.21.0504161844040.30848-100000@iabervon.org>
Daniel Barkalow wrote:
> On Sat, 16 Apr 2005, Adam Kropelin wrote:
>> How about building a file list and doing a batch download via 'wget
>> -i /tmp/foo'? A quick test (on my ancient wget-1.7) indicates that
>> it reuses connectionss when successive URLs point to the same server.
>
> You need to look at some of the files before you know what other
> files to get. You could do it in waves, but that would be excessively
> complicated to code and not the most efficient anyway.
Ah, yes. Makes sense. How about libcurl or another http client library,
then? Minimizing dependencies on external libraries is good, but writing a
really robust http client is a tricky business. (Not that you aren't up to
it; I just wonder if it's the best way to spend your time.)
--Adam
^ permalink raw reply
* Re: [PATCH] fix mktemp (remove mktemp ;)
From: Paul Jackson @ 2005-04-16 23:46 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git, pasky
In-Reply-To: <20050416233626.GV9461@lug-owl.de>
> /usr/tmp/ ??? Hey, /usr may be mounted read-only! Why not just use /tmp ?
Sure - that's fine to change. Those that care will have TMPDIR set anyway.
I probably made that choice of /usr/tmp for the fallback 10 or 20 years
ago, and have never had reason to revisit it. I have long forgotten why
I made that choice.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: Re: Re: Add "clone" support to lntree
From: Petr Baudis @ 2005-04-16 23:44 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0504161902380.30848-100000@iabervon.org>
Dear diary, on Sun, Apr 17, 2005 at 01:07:35AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > Actually, what about if git pull outside of repository did what git
> > clone does now? I'd kinda like clone instead of fork too.
>
> This seems like the best solution to me, too. Although that would make
> pull take a URL when making a new repository and not otherwise, which
> might be confusing. "init-remote" perhaps, or maybe just have "init" do it
> if given a URL?
Yes, init taking URL optionally sounds ideal. Thanks.
--
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: optimize gitdiff-do script
From: Petr Baudis @ 2005-04-16 23:43 UTC (permalink / raw)
To: Paul Jackson; +Cc: git
In-Reply-To: <20050416232810.23430.78712.sendpatchset@sam.engr.sgi.com>
Dear diary, on Sun, Apr 17, 2005 at 01:28:04AM CEST, I got a letter
where Paul Jackson <pj@sgi.com> told me that...
> Reduce number of subcommands execv'd by a
> third, by only calling 'rm' once, at end, not each
> loop.
The idea behind that was that diffing could take a significant portion
of disk space, especially when making large kernel diffs. Perhaps we
could make this a switch, but I would personally prefer defaulting to
the less space-consuming behaviour. I personally dislike applications
which like to pop 150M of nonsense to my /tmp.
Please don't reindent the scripts. It violates the current coding style
and the patch is unreviewable.
--
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: Storing permissions
From: Junio C Hamano @ 2005-04-16 23:42 UTC (permalink / raw)
To: Paul Jackson; +Cc: Martin Mares, git
In-Reply-To: <20050416161935.0d2cf3b0.pj@sgi.com>
>>>>> "PJ" == Paul Jackson <pj@sgi.com> writes:
PJ> That matches my experience - store 1 bit of mode state - executable or not.
Sounds like svn ;-).
^ permalink raw reply
* Re: fix mktemp (remove mktemp ;)
From: Petr Baudis @ 2005-04-16 23:37 UTC (permalink / raw)
To: Paul Jackson; +Cc: git, mj
In-Reply-To: <20050416232749.23430.93360.sendpatchset@sam.engr.sgi.com>
Dear diary, on Sun, Apr 17, 2005 at 01:27:43AM CEST, I got a letter
where Paul Jackson <pj@sgi.com> told me that...
> Remove mktemp usage - it doesn't work on
> some Mandrakes, nor on my SuSE 8.2 with
> mktemp-1.5-531.
>
> Replace with simple use of $$ (pid).
> I've been using this same pattern for
> 20 years on many production scripts;
> it's fast, solid and simple.
And racy. And not guaranteed to come up with fresh new files.
> More robust tmp file removal, using trap,
> so that scripts interrupted by signals
> HUP, INT, QUIT or PIPE will cleanup.
But I like this!
I'm deferring those changes to the introduction of a git shell library,
which several people volunteered to do so far, but noone sent me any
patches for (the last one was probably Martin Mares, only few hours ago
though).
--
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] fix mktemp (remove mktemp ;)
From: Jan-Benedict Glaw @ 2005-04-16 23:36 UTC (permalink / raw)
To: Paul Jackson; +Cc: git, Petr Baudis
In-Reply-To: <20050416232749.23430.93360.sendpatchset@sam.engr.sgi.com>
On Sat, 2005-04-16 16:27:43 -0700, Paul Jackson <pj@sgi.com>
wrote in message <20050416232749.23430.93360.sendpatchset@sam.engr.sgi.com>:
> Index: git-pasky-0.4/gitcommit.sh
> ===================================================================
> --- git-pasky-0.4.orig/gitcommit.sh 2005-04-12 10:39:14.000000000 -0700
> +++ git-pasky-0.4/gitcommit.sh 2005-04-16 13:17:49.000000000 -0700
> @@ -60,7 +60,9 @@ for file in $commitfiles; do
> echo $file;
> done
> echo "Enter commit message, terminated by ctrl-D on a separate line:"
> -LOGMSG=`mktemp -t gitci.XXXXXX`
> +t=${TMPDIR:-/usr/tmp}/gitapply.$$
/usr/tmp/ ??? Hey, /usr may be mounted read-only! Why not just use /tmp ?
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
^ permalink raw reply
* Re: Re: Re: Add "clone" support to lntree
From: Petr Baudis @ 2005-04-16 23:33 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0504152307050.30848-100000@iabervon.org>
Dear diary, on Sat, Apr 16, 2005 at 05:17:00AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> On Sat, 16 Apr 2005, Petr Baudis wrote:
>
> > Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter
> > where Petr Baudis <pasky@ucw.cz> told me that...
> > > git branch --- creates a branch from a given commit
> > > (when passed empty commit, creates a branch
> > > from the current commit and sets the working
> > > tree to that branch)
> > > Note that there is a bug in current git update - it will allow you to
> > > bring several of your trees to follow the same branch, or even a remote
> > > branch. This is not even supposed to work, and will be fixed when I get
> > > some sleep. You will be able to do git pull even on local branches, and
> > > the proper solution for this will be just tracking the branch you want
> > > to follow.
> >
> > I must admit that I'm not entirely decided yet, so I'd love to hear your
> > opinion.
> >
> > I'm wondering, whether each tree should be fixed to a certain branch.
> > That is, you decide a name when you do git fork, and then the tree
> > always follows that branch. (It always has to follow [be bound to]
> > *some* branch, and each branch can be followed by only a single tree at
> > a time.)
>
> I don't think I'm following the use of branches. Currently, what I do is
> have a git-pasky and a git-linus, and fork off a working directory from
> one of these for each thing I want to work on. I do some work, commit as I
> make progress, and then do a diff against the remote head to get a patch
> to send off. If I want to do a series of patches which depend on each
> other, I fork my next directory off of my previous one rather than off of
> a remote base. I haven't done much rebasing, so I haven't worked out how I
> would do that most effectively.
Yes. And that's exactly what the branches allow you to do. You just do
git fork myhttpclient ~/myhttpclientdir
then you do some hacking, and when you have something usable, you can
go back to your main working directory and do
git merge -b when_you_started myhttpclient
Since you consider the code perfect, you can now just rm -rf
~/myhttpclient.
Suddenly, you get a mail from mj pointing out some bugs, and it looks
like there are more to come. What to do?
git fork myhttpclient ~/myhttpclientdir
(Ok, this does not work, but that's a bug, will fix tomorrow.) This will
let you take off when you left in your work on the branch.
git update for seeking between commits is probably extremely important
for any kind of binary search when you are wondering when did this bug
appeared first, or when you are exploring how certain branch evolved
over time. Doing git fork for each successive iteration sounds horrible.
Now, what about git branch and git update for switching between
branches? I think this is the most controversial part; these are
basically just shortcuts for not having to do git fork, and I wouldn't
mind so much removing them, if you people really consider them too ugly
a wart for the soft clean git skin. I admit that they both come from a
hidden prejudice that git fork is going to be slow and eat a lot of
disk.
The idea for git branch is to mark a commit as "this is a branch but I
don't want to git fork" (because I'm lazy or short on disk space or
whatever). Let's say you are tracking a branch, do some local commits
and then want to untrack. This will get you back to HEAD.local, but you
want to keep a reference for your local commits, and possibly work on
them more later - so you mark them as a branch. But thinking about it, I
couldn't come up with another usage case than this, and I think that now
that we have git fork, I will modify git track behaviour heavily so that
tracking/untracking won't really switch you to the other branch
completely, but really only tell git pull that you want the pulled
updates applied. So git branch command will likely go.
The idea for git update for switching between branches is that
especially when you have two rather similar branches and mostly do stuff
on one of them, but sometimes you want to do something on the other one,
you can do just quick git update, do stuff, and git update back, without
any forking.
Note that this all is *absolutely* subject to change, provided you can
convince me about some better way. ;-) My mindset on this is pretty
open. This is just what seems to me as a pretty flexible and elegant to
do stuff, while giving you enough freedom to pick your own style.
> I think I can make this space efficient by hardlinking unmodified blobs to
> a directory of cached expanded blobs.
I don't know but I really feel *very* unsafe when doing that. What if
something screws up and corrupts my base... way too easy. And it gets
pretty inconvenient and even more dangerous when you get the idea to do
some modifications on your tree by something else than your favorite
editor (which you've already checked does the right thing).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [PATCH] show-diff -z option for machine readable output.
From: Junio C Hamano @ 2005-04-16 23:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This patch adds the -z option to the show-diff command,
primarily for use by scripts. The information emitted is
similar to that of -q option, but in a more machine readable
form. Records are terminated with NUL instead of LF, so that
the scripts can deal with pathnames with embedded newlines.
To be applied on top of my previous patch:
[PATCH] Optionally tell show-diff to show only named files.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
show-diff.c | 28 +++++++++++++++++++---------
1 files changed, 19 insertions(+), 9 deletions(-)
show-diff.c: 0c5fb1a381a6c6689dca3f52d0c66bb591cadb39
--- show-diff.c
+++ show-diff.c 2005-04-16 16:23:40.000000000 -0700
@@ -55,7 +55,7 @@
}
}
-static const char *show_diff_usage = "show-diff [-s] [-q] [paths...]";
+static const char *show_diff_usage = "show-diff [-s] [-q] [-z] [paths...]";
static int matches_pathspec(struct cache_entry *ce, char **spec, int cnt)
{
@@ -76,6 +76,7 @@
{
int silent = 0;
int silent_on_nonexisting_files = 0;
+ int machine_readable = 0;
int entries = read_cache();
int i;
@@ -84,6 +85,9 @@
silent_on_nonexisting_files = silent = 1;
else if (!strcmp(argv[1], "-q"))
silent_on_nonexisting_files = 1;
+ else if (!strcmp(argv[1], "-z")) {
+ machine_readable = 1;
+ }
else
usage(show_diff_usage);
argv++; argc--;
@@ -99,7 +103,7 @@
for (i = 0; i < entries; i++) {
struct stat st;
struct cache_entry *ce = active_cache[i];
- int n, changed;
+ int changed;
unsigned long size;
char type[20];
void *new;
@@ -111,18 +115,24 @@
if (stat(ce->name, &st) < 0) {
if (errno == ENOENT && silent_on_nonexisting_files)
continue;
- printf("%s: %s\n", ce->name, strerror(errno));
- if (errno == ENOENT)
- show_diff_empty(ce);
+ if (machine_readable)
+ printf("X %s%c", ce->name, 0);
+ else {
+ printf("%s: %s\n", ce->name, strerror(errno));
+ if (errno == ENOENT)
+ show_diff_empty(ce);
+ }
continue;
}
changed = cache_match_stat(ce, &st);
if (!changed)
continue;
- printf("%s: ", ce->name);
- for (n = 0; n < 20; n++)
- printf("%02x", ce->sha1[n]);
- printf("\n");
+ if (!machine_readable)
+ printf("%s: %s\n", ce->name, sha1_to_hex(ce->sha1));
+ else {
+ printf("%s %s%c", sha1_to_hex(ce->sha1), ce->name, 0);
+ continue;
+ }
fflush(stdout);
if (silent)
continue;
^ permalink raw reply
* [PATCH] missing mkdir -p flag in gitdiff-do
From: Paul Jackson @ 2005-04-16 23:27 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Paul Jackson
In-Reply-To: <20050416232749.23430.93360.sendpatchset@sam.engr.sgi.com>
First mkdir in gitdiff-do missing -p, so useless error
Signed-off-by: Paul Jackson <pj@sgi.com>
Index: git-pasky-0.4/gitdiff-do
===================================================================
--- git-pasky-0.4.orig/gitdiff-do 2005-04-16 13:18:29.000000000 -0700
+++ git-pasky-0.4/gitdiff-do 2005-04-16 13:19:07.000000000 -0700
@@ -37,7 +37,7 @@ trap 'rm -fr $t.?; trap 0; exit 0' 0 1 2
diffdir=$t.1
diffdir1="$diffdir/$id1"
diffdir2="$diffdir/$id2"
-mkdir "$diffdir1" "$diffdir2"
+mkdir -p "$diffdir1" "$diffdir2"
while [ "$1" ]; do
declare -a param
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* [PATCH] fix mktemp (remove mktemp ;)
From: Paul Jackson @ 2005-04-16 23:27 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Paul Jackson
Remove mktemp usage - it doesn't work on
some Mandrakes, nor on my SuSE 8.2 with
mktemp-1.5-531.
Replace with simple use of $$ (pid).
I've been using this same pattern for
20 years on many production scripts;
it's fast, solid and simple.
More robust tmp file removal, using trap,
so that scripts interrupted by signals
HUP, INT, QUIT or PIPE will cleanup.
Signed-off-by: Paul Jackson <pj@sgi.com>
Index: git-pasky-0.4/README
===================================================================
--- git-pasky-0.4.orig/README 2005-04-16 13:16:54.000000000 -0700
+++ git-pasky-0.4/README 2005-04-16 13:17:01.000000000 -0700
@@ -116,7 +116,6 @@ Software requirements:
C compiler
bash
basic shell environment (sed, gred, textutils, ...)
- mktemp 1.5+ (Mandrake users beware!)
diff, patch
Index: git-pasky-0.4/gitcommit.sh
===================================================================
--- git-pasky-0.4.orig/gitcommit.sh 2005-04-12 10:39:14.000000000 -0700
+++ git-pasky-0.4/gitcommit.sh 2005-04-16 13:17:49.000000000 -0700
@@ -60,7 +60,9 @@ for file in $commitfiles; do
echo $file;
done
echo "Enter commit message, terminated by ctrl-D on a separate line:"
-LOGMSG=`mktemp -t gitci.XXXXXX`
+t=${TMPDIR:-/usr/tmp}/gitapply.$$
+trap 'rm -f $t.?; trap 0; exit 0' 0 1 2 3 15
+LOGMSG=$t.1
if [ "$merged" ]; then
cat .git/merged | sed 's/^/Merging: /' >>$LOGMSG
cat .git/merged | sed 's/^/Merging: /'
@@ -86,7 +88,6 @@ if [ "$treeid" = "$(tree-id)" ] && [ ! "
fi
newhead=$(commit-tree $treeid $oldhead $merged <$LOGMSG)
-rm $LOGMSG
rm -f .git/add-queue .git/rm-queue .git/merged
if [ "$newhead" ]; then
Index: git-pasky-0.4/gitapply.sh
===================================================================
--- git-pasky-0.4.orig/gitapply.sh 2005-04-13 02:21:14.000000000 -0700
+++ git-pasky-0.4/gitapply.sh 2005-04-16 13:16:13.000000000 -0700
@@ -8,9 +8,11 @@
#
# Takes the diff on stdin.
-gonefile=$(mktemp -t gitapply.XXXXXX)
-todo=$(mktemp -t gitapply.XXXXXX)
-patchfifo=$(mktemp -t gitapply.XXXXXX)
+t=${TMPDIR:-/usr/tmp}/gitapply.$$
+trap 'rm -f $t.?; trap 0; exit 0' 0 1 2 3 15
+gonefile=$t.1
+todo=$t.2
+patchfifo=$t.3
rm $patchfifo && mkfifo -m 600 $patchfifo
show-files --deleted >$gonefile
@@ -74,4 +76,3 @@ while [ "$1" ]; do
done
'
-rm $pathfifo $todo $gonefile
Index: git-pasky-0.4/gitdiff-do
===================================================================
--- git-pasky-0.4.orig/gitdiff-do 2005-04-16 13:13:59.000000000 -0700
+++ git-pasky-0.4/gitdiff-do 2005-04-16 13:18:29.000000000 -0700
@@ -32,7 +32,9 @@ mkbanner () {
[ "$labelapp" ] && label="$label ($labelapp)"
}
-diffdir=$(mktemp -d -t gitdiff.XXXXXX)
+t=${TMPDIR:-/usr/tmp}/gitdiff.$$
+trap 'rm -fr $t.?; trap 0; exit 0' 0 1 2 3 15
+diffdir=$t.1
diffdir1="$diffdir/$id1"
diffdir2="$diffdir/$id2"
mkdir "$diffdir1" "$diffdir2"
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* [PATCH] optimize gitdiff-do script
From: Paul Jackson @ 2005-04-16 23:28 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Paul Jackson
In-Reply-To: <20050416232749.23430.93360.sendpatchset@sam.engr.sgi.com>
Rewrite gitdiff-do so that it works with arbitrary
whitespace (space, tab, newline, ...) in filenames.
Reduce number of subcommands execv'd by a
third, by only calling 'rm' once, at end, not each
loop.
Avoid using shell arrays; perhaps more portable.
Avoid 'echo -e' when displaying names; dont expand escape
sequences in names.
Use shell noglob (-f) to minimize getdents() calls.
Simplify argument parsing and tmp file management.
Comment the nastier shell patterns.
This reduces the time by about 1/3 of what it was.
Signed-off-by: Paul Jackson <pj@sgi.com>
Index: git-pasky-0.4/gitdiff-do
===================================================================
--- git-pasky-0.4.orig/gitdiff-do 2005-04-16 13:19:07.000000000 -0700
+++ git-pasky-0.4/gitdiff-do 2005-04-16 15:33:28.000000000 -0700
@@ -2,19 +2,22 @@
#
# Make a diff between two GIT trees.
# Copyright (c) Petr Baudis, 2005
+# Copyright (c) Paul Jackson, 2005
#
# Takes two parameters identifying the two trees/commits to compare.
# Empty string will be substitued to HEAD revision.
#
# Note that this is probably the most performance critical shell script
-# in the whole GIT suite. That's also why I resorted to bash builtin
-# features and stuff. -- pasky@ucw.cz
+# in the whole GIT suite.
#
# Outputs a diff converting the first tree to the second one.
+set -f # keep shell from scanning "." to expand wildcards
-id1=$1; shift
-id2=$1; shift
+t=${TMPDIR:-/usr/tmp}/gitdiff.$$
+trap 'set +f; rm -fr $t.?; trap 0; exit 0' 0 1 2 3 15
+
+id1=$1; id2=$2; shift 2
# Leaves the result in $label.
mkbanner () {
@@ -32,58 +35,55 @@ mkbanner () {
[ "$labelapp" ] && label="$label ($labelapp)"
}
-t=${TMPDIR:-/usr/tmp}/gitdiff.$$
-trap 'rm -fr $t.?; trap 0; exit 0' 0 1 2 3 15
-diffdir=$t.1
-diffdir1="$diffdir/$id1"
-diffdir2="$diffdir/$id2"
-mkdir -p "$diffdir1" "$diffdir2"
-
-while [ "$1" ]; do
- declare -a param
- param=($1);
- op=${param[0]:0:1}
- mode=${param[0]:1}
- type=${param[1]}
- sha=${param[2]}
- name=${param[3]}
-
- echo -e "Index: $name\n==================================================================="
-
- if [ "$type" = "tree" ]; then
- # diff-tree will kindly diff the subdirs for us
- # XXX: What about modes?
- shift; continue
- fi
-
- loc1="$diffdir1/$name"; dir1="${loc1%/*}"
- loc2="$diffdir2/$name"; dir2="${loc2%/*}"
- ([ -d "$dir1" ] && [ -d "$dir2" ]) || mkdir -p "$dir1" "$dir2"
-
- case $op in
- "+")
- mkbanner "$loc2" $id2 "$name" $mode $sha
- diff -L "/dev/null (tree:$id1)" -L "$label" -u /dev/null "$loc2"
- ;;
- "-")
- mkbanner "$loc1" $id1 "$name" $mode $sha
- diff -L "$label" -L "/dev/null (tree:$id2)" -u "$loc1" /dev/null
- ;;
- "*")
- modes=(${mode/->/ });
- mode1=${modes[0]}; mode2=${modes[1]}
- shas=(${sha/->/ });
- sha1=${shas[0]}; sha2=${shas[1]}
- mkbanner "$loc1" $id1 "$name" $mode1 $sha1; label1=$label
- mkbanner "$loc2" $id2 "$name" $mode2 $sha2; label2=$label
- diff -L "$label1" -L "$label2" -u "$loc1" "$loc2"
- ;;
- *)
- echo "Unknown operator $op, ignoring delta: $1";;
- esac
-
- rm -f "$loc1" "$loc2"
- shift
+for arg
+do
+ IFS=' '
+ set X$arg # X: don't let shell set see leading '+' in $arg
+ op="$1"
+ mode=${op#X?} # trim leading X? 1st two chars
+ type="$2"
+ sha="$3"
+ # if 4+ tabs, trim 1st 3 fields on 1st line with sed
+ case "$arg" in
+ *\ *\ *\ *\ *)
+ name=$(echo "$arg" |
+ /bin/sed '1s/[^ ]* [^ ]* [^ ]* //')
+ ;;
+ *)
+ name="$4"
+ ;;
+ esac
+
+ echo "Index: $name"
+ echo ===================================================================
+
+ test "$type" = "tree" && continue
+
+ loc1=$t.1
+ loc2=$t.2
+
+ case $op in
+ X+*)
+ mkbanner $loc2 $id2 "$name" $mode $sha
+ diff -L "/dev/null (tree:$id1)" -L "$label" -u /dev/null $loc2
+ ;;
+ X-*)
+ mkbanner $loc1 $id1 "$name" $mode $sha
+ diff -L "$label" -L "/dev/null (tree:$id2)" -u $loc1 /dev/null
+ ;;
+ X\**)
+ mode1=${mode%->*} # trim '->' and after
+ mode2=${mode#*->} # trim up to and including '->'
+ sha1=${sha%->*} # trim '->' and after
+ sha2=${sha#*->} # trim up to and including '->'
+
+ mkbanner $loc1 $id1 "$name" $mode1 $sha1; label1=$label
+ mkbanner $loc2 $id2 "$name" $mode2 $sha2; label2=$label
+ diff -L "$label1" -L "$label2" -u $loc1 $loc2
+ ;;
+ *)
+ badop=$(echo $op | sed 's/.\(.\).*/\1/')
+ echo "Unknown operator $badop, ignoring delta: $1"
+ ;;
+ esac
done
-
-rm -rf "$diffdir"
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: Storing permissions
From: Paul Jackson @ 2005-04-16 23:19 UTC (permalink / raw)
To: Martin Mares; +Cc: git
In-Reply-To: <20050416230058.GA10983@ucw.cz>
Martin wrote:
> Does it really make sense to store full permissions in the trees? I think
> that remembering the x-bit should be good enough for almost all purposes
> and the other permissions should be left to the local environment.
That matches my experience - store 1 bit of mode state - executable or not.
Let local environment determine read, write and umask permissions.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: SHA1 hash safety
From: Martin Mares @ 2005-04-16 23:18 UTC (permalink / raw)
To: Paul Jackson; +Cc: git
In-Reply-To: <20050416161153.534b47d5.pj@sgi.com>
Hi!
> We've already computed the chances of a random pure hash collision
> with SHA1 - it's something like an average of 1 collision every
> 10 billion years if we have 10,000 coders generating 1 new file
> version every minute, non-stop, 24 hours a day, 365 days a year.
GIT is safe even for the millions of monkeys writing Shakespeare :-)
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Homo homini lupus, frater fratri lupior, bohemus bohemo lupissimus.
^ permalink raw reply
* [PATCH] Optionally tell show-diff to show only named files
From: Junio C Hamano @ 2005-04-16 23:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
SCMs have ways to say "I want diff only this particular file",
or "I want diff files under this directory". This patch teaches
show-diff to do something similar. Without command line
arguments, it still examines everything in the dircache as
before.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
show-diff.c | 38 ++++++++++++++++++++++++++++++--------
1 files changed, 30 insertions(+), 8 deletions(-)
show-diff.c: 5f3d4699566843a5448260e5da286ed65d90e397
--- show-diff.c
+++ show-diff.c 2005-04-16 16:07:07.000000000 -0700
@@ -55,6 +55,23 @@
}
}
+static const char *show_diff_usage = "show-diff [-s] [-q] [paths...]";
+
+static int matches_pathspec(struct cache_entry *ce, char **spec, int cnt)
+{
+ int i;
+ int namelen = ce_namelen(ce);
+ for (i = 0; i < cnt; i++) {
+ int speclen = strlen(spec[i]);
+ if (! strncmp(spec[i], ce->name, speclen) &&
+ speclen <= namelen &&
+ (ce->name[speclen] == 0 ||
+ ce->name[speclen] == '/'))
+ return 1;
+ }
+ return 0;
+}
+
int main(int argc, char **argv)
{
int silent = 0;
@@ -62,18 +79,19 @@
int entries = read_cache();
int i;
- for (i = 1; i < argc; i++) {
- if (!strcmp(argv[i], "-s")) {
+ while (1 < argc && argv[1][0] == '-') {
+ if (!strcmp(argv[1], "-s"))
silent_on_nonexisting_files = silent = 1;
- continue;
- }
- if (!strcmp(argv[i], "-q")) {
+ else if (!strcmp(argv[1], "-q"))
silent_on_nonexisting_files = 1;
- continue;
- }
- usage("show-diff [-s] [-q]");
+ else
+ usage(show_diff_usage);
+ argv++; argc--;
}
+ /* At this point, if argc == 1, then we are doing everything.
+ * Otherwise argv[1] .. argv[argc-1] have the explicit paths.
+ */
if (entries < 0) {
perror("read_cache");
exit(1);
@@ -86,6 +104,10 @@
char type[20];
void *new;
+ if (1 <argc &&
+ ! matches_pathspec(ce, argv+1, argc-1))
+ continue;
+
if (stat(ce->name, &st) < 0) {
if (errno == ENOENT && silent_on_nonexisting_files)
continue;
^ permalink raw reply
* Re: SHA1 hash safety
From: Paul Jackson @ 2005-04-16 23:14 UTC (permalink / raw)
To: David Lang; +Cc: cscott, omb, mingo, git
In-Reply-To: <Pine.LNX.4.62.0504161543150.22652@qynat.qvtvafvgr.pbz>
> sysadmins realize that there are an infinante number of files that map to
Sysadmins know that there are an infinite ways for their
systems to crap out, and try to cover for the ones that
there is a snow balls chance in Hades of them seeing in
their lifetime.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: SHA1 hash safety
From: Paul Jackson @ 2005-04-16 23:11 UTC (permalink / raw)
To: David Lang; +Cc: cscott, pasky, omb, mingo, git
In-Reply-To: <Pine.LNX.4.62.0504161549410.22652@qynat.qvtvafvgr.pbz>
> what I'm talking about is the chance that somewhere, sometime there will
> be two different documents that end up with the same hash
I have vastly greater chance of a file colliding due to hardware or
software glitch than a random message digest collision of two legitimate
documents.
I've lost quite a few files in 25 years of computing to just
such glitches, sometimes without knowing it until months or years
later.
We've already computed the chances of a random pure hash collision
with SHA1 - it's something like an average of 1 collision every
10 billion years if we have 10,000 coders generating 1 new file
version every minute, non-stop, 24 hours a day, 365 days a year.
Get real. There are _many_ sources of random error in our
tools. When some sources are billions of billions times
more likely to occur, it makes sense to worry about them first.
Reminds me of the drunk looking under the lamp post for the
house keys he dropped - because that's where the light is.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: full kernel history, in patchset format
From: David Lang @ 2005-04-16 23:08 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Linus Torvalds, Ingo Molnar, git
In-Reply-To: <1113679421.28612.16.camel@tglx.tec.linutronix.de>
On Sat, 16 Apr 2005, Thomas Gleixner wrote:
> On Sat, 2005-04-16 at 10:04 -0700, Linus Torvalds wrote:
>
>> So I'd _almost_ suggest just starting from a clean slate after all.
>> Keeping the old history around, of course, but not necessarily putting it
>> into git now. It would just force everybody who is getting used to git in
>> the first place to work with a 3GB archive from day one, rather than
>> getting into it a bit more gradually.
>
> Sure. We can export the 2.6.12-rc2 version of the git'ed history tree
> and start from there. Then the first changeset has a parent, which just
> lives in a different place.
> Thats the only difference to your repository, but it would change the
> sha1 sums of all your changesets.
at least start with a full release. say 2.6.11
the history won't be blank, but it's far more likly that people will care
about the details between 2.6.11 and 2.6.12 and will want to go back
before -rc2
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* Re: Re: Add "clone" support to lntree
From: Daniel Barkalow @ 2005-04-16 23:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050416230000.GN19099@pasky.ji.cz>
On Sun, 17 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sat, Apr 16, 2005 at 05:06:54AM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
>
> > I think "fork" is as good as anything for describing the operation. I had
> > thought about "clone" because it seemed to fill the role that "bk
> > clone" had (although I never used BK, so I'm not sure). It doesn't seem
> > useful to me to try cloning multiple remote repositories, since you'd get
> > a copy of anything common from each; you just want to suck everything into
> > the same .git/objects and split off working directories.
>
> Actually, what about if git pull outside of repository did what git
> clone does now? I'd kinda like clone instead of fork too.
This seems like the best solution to me, too. Although that would make
pull take a URL when making a new repository and not otherwise, which
might be confusing. "init-remote" perhaps, or maybe just have "init" do it
if given a URL?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Re: Merge with git-pasky II.
From: David Lang @ 2005-04-16 23:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Simon Fowler, git
In-Reply-To: <Pine.LNX.4.58.0504160913180.7211@ppc970.osdl.org>
On Sat, 16 Apr 2005, Linus Torvalds wrote:
> Almost all attacks on sha1 will depend on _replacing_ a file with a bogus
> new one. So guys, instead of using sha256 or going overboard, just make
> sure that when you synchronize, you NEVER import a file you already have.
>
> It's really that simple. Add "--ignore-existing" to your rsync scripts,
> and you're pretty much done. That guarantees that a new evil blob by the
> next mad scientist out to take over the world will never touch your
> repository, and if we make this part of the _standard_ scripts, then
> dammit, security is in good _practices_ rather than just relying blindly
> on the hash being secure.
>
> In other words, I think we could have used md5's as the hash, if we just
> make sure we have good practices. And it wouldn't have been "insecure".
>
> The fact is, you don't merge with people you don't trust. If you don't
> trust them, they have a much easier time corrupting your repository by
> just creating bugs in the code and checking that thing in. Who cares about
> hash collisions, when you can generate a kernel root vulnerability by just
> adding a single line of code and use the _correct_ hash for it.
>
> So the sha1 hash does not replace _trust_. That comes from something else
> altogether.
What I am bringing up is not intended to be a trust thing, but instead a
safety thing, accidents, not evil intent. makeing the rsync scripts
--ignore-existing will avoid corrupting local data when pulling remotely,
but it won't solve the problem of running into a collision locally (and
won't do much to help you figure out what's wrong when you run into a
remote collision)
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* Storing permissions
From: Martin Mares @ 2005-04-16 23:00 UTC (permalink / raw)
To: git
Hi Linus et al.,
I'm trying to use git, but I frequenty run into problems with file permissions
-- some archives (including the master git archive) contain group-writable
files, but when I check them out, the permissions get trimmed by my umask
(quite sensibly) and update-cache complains that they need update.
Does it really make sense to store full permissions in the trees? I think
that remembering the x-bit should be good enough for almost all purposes
and the other permissions should be left to the local environment.
Another possibility is to keep the permissions in the trees, but just make
update-cache ignore differences in write permissions.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Man is the highest animal. Man does the classifying.
^ permalink raw reply
* Re: Re: Add "clone" support to lntree
From: Petr Baudis @ 2005-04-16 23:00 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0504152251300.30848-100000@iabervon.org>
Dear diary, on Sat, Apr 16, 2005 at 05:06:54AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> On Sat, 16 Apr 2005, Petr Baudis wrote:
> > I'm sorry but you are late, I added it about a hour and half ago or so.
> > :-) Check git fork. (I *want* separate command than git lntree. In fact,
> > I think I should make git lntree gitXlntree.sh instead, since it is
> > really internal command for git-tools and the user should probably never
> > need it for anything. git lntree is too lowlevel.)
>
> Have you not pushed since? I don't see it.
See my last mail. :-)
> I think "fork" is as good as anything for describing the operation. I had
> thought about "clone" because it seemed to fill the role that "bk
> clone" had (although I never used BK, so I'm not sure). It doesn't seem
> useful to me to try cloning multiple remote repositories, since you'd get
> a copy of anything common from each; you just want to suck everything into
> the same .git/objects and split off working directories.
Actually, what about if git pull outside of repository did what git
clone does now? I'd kinda like clone instead of fork too.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ 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