* [PATCH] Fix off-by-one error in show-diff
From: Junio C Hamano @ 2005-04-17 5:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
The patch to introduce shell safety to show-diff has an
off-by-one error. Here is an fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
show-diff.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
show-diff.c: 8a24ff62b85a6e23469e3f0e7a20170dfe543ebf
--- show-diff.c
+++ show-diff.c 2005-04-16 22:53:11.000000000 -0700
@@ -27,8 +27,8 @@
int cnt, c;
char *cp;
- /* count single quote characters */
- for (cnt = 0, cp = src; *cp; cnt++, cp++)
+ /* count bytes needed to store the quoted string. */
+ for (cnt = 1, cp = src; *cp; cnt++, cp++)
if (*cp == '\'')
cnt += 3;
^ permalink raw reply
* [PATCH] update-cache --remove marks the path merged.
From: Junio C Hamano @ 2005-04-17 6:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
When update-cache --remove is run, resolve unmerged state for
the path. This is consistent with the update-cache --add
behaviour. Essentially, the user is telling us how he wants to
resolve the merge by running update-cache.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
read-cache.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
read-cache.c: e16c37403092e1e94c50b04685b6417405ffc724
--- read-cache.c
+++ read-cache.c 2005-04-16 22:43:55.000000000 -0700
@@ -368,7 +368,9 @@
int remove_file_from_cache(char *path)
{
int pos = cache_name_pos(path, strlen(path));
- if (pos >= 0)
+ if (pos < 0)
+ pos = -pos-1;
+ while (! strcmp(active_cache[pos]->name, path))
remove_entry_at(pos);
return 0;
}
^ permalink raw reply
* Re: Issues with higher-order stages in dircache
From: Junio C Hamano @ 2005-04-17 6:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504162228300.7211@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
>> - When merging two trees, i.e. "read-tree -m A B", shouldn't
>> we collapse identical stage-1/2 into stage-0?
LT> How do you actually intend to merge two trees?
How silly of me. *BLUSH*
^ permalink raw reply
* Re: Storing permissions
From: David A. Wheeler @ 2005-04-17 6:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Jackson, Morten Welinder, mj, git
In-Reply-To: <Pine.LNX.4.58.0504162138020.7211@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Sat, 16 Apr 2005, Paul Jackson wrote:
>
>>Morten wrote:
>>
>>>It makes some sense in principle, but without storing what they mean
>>>(i.e., group==?) it certainly makes no sense.
>>
>>There's no "they" there.
>>
>>I think Martin's proposal, to which I agreed, was to store a _single_
>>bit. If any of the execute permissions of the incoming file are set,
>>then the bit is stored ON, else it is stored OFF. On 'checkout', if the
>>bit is ON, then the file permission is set mode 0777 (modulo umask),
>>else it is set mode 0666 (modulo umask).
>
>
> I think I agree.
>
> Anybody willing to send me a patch? One issue is that if done the obvious
> way it's an incompatible change, and old tree objects won't be valid any
> more. It might be ok to just change the "compare cache" check to only care
> about a few bits, though: S_IXUSR and S_IFDIR.
There's a minor reason to write out ALL the perm bit data, but
only care about a few bits coming back in: Some people use
SCM systems as a generalized backup system, so you can back up
your system to an arbitrary known state in the past
(e.g., "Change my /etc files to the state I was at
just before I installed that &*#@ program!").
For more on this, see:
http://www.onlamp.com/pub/a/onlamp/2005/01/06/svn_homedir.html
If you store all the bits, then you CAN restore things
more exactly the way they were. This is imperfect, since
it doesn't cover more exotic permission
values from SELinux, xattrs, whatever. For some, that's enough.
Yeah, I know, not the main purpose of git. But what the heck,
I _like_ flexible infrastructures.
--- David A. Wheeler
^ permalink raw reply
* Parseable commit header
From: Stefan-W. Hahn @ 2005-04-17 6:22 UTC (permalink / raw)
To: git
Hi,
after playing a while with git-pasky it is a crap to interpret the date of
commit logs. Though it was a good idea to put the date in a parseable format
(seconds since), but the format of the commit itself is not good parseable.
For easy converting the commit log header in readable format it should be in
another format, perhaps like mail header:
- Every field should start al column zero wih filedname end up with a colon.
- Every fieldname starts with an upcase letter.
- The dates of author and committer should be fields of it own.
- The commit message itself is seperated by a blank line.
Example current log entry:
commit fe077e9d16819b72c275ea40b254f22b4d236f8b
tree 98b57b0310e0e2309fe4a6c24a6abea31a4d6c6d
parent f0adb6cf1bf603537afff5cf26b90e81321db225
author Petr Baudis <pasky@ucw.cz> 1113684324 +0200
committer Petr Baudis <xpasky@machine> 1113684324 +0200
s/me/commit/ in git log output.
Should be:
Commit: fe077e9d16819b72c275ea40b254f22b4d236f8b
Tree: 98b57b0310e0e2309fe4a6c24a6abea31a4d6c6d
Parent: f0adb6cf1bf603537afff5cf26b90e81321db225
Author: Petr Baudis <pasky@ucw.cz>
Author-Date: 1113684324 +0200
Committer: Petr Baudis <xpasky@machine>
Committer-Dater: 1113684324 +0200
s/me/commit/ in git log output.
This date entries are now easy parseable and convertable.
- Stefan
--
Stefan-W. Hahn It is easy to make things.
/ mailto:stefan.hahn@s-hahn.de / It is hard to make things simple.
^ permalink raw reply
* Re: Yet another base64 patch
From: David A. Wheeler @ 2005-04-17 6:38 UTC (permalink / raw)
To: Paul Jackson; +Cc: git
In-Reply-To: <20050416210513.1ba26967.pj@sgi.com>
Paul Jackson wrote:
> David wrote:
>
>>It's a trade-off, I know.
>
>
> So where do you recommend we make that trade-off?
I'd look at some of the more constraining, yet still
common cases, and make sure it worked reasonably
well without requiring magic. My list would be:
ext2, ext3, NFS, and Windows' NTFS (stupid short filenames,
case-insensitive/case-preserving). Samba shouldn't be
more constraining than NTFS, and I would expect ReiserFS
wouldn't be a constraining case. Bonus points if the
names lengths are inside POSIX guarantees, but I bet the
POSIX limits are so tiny as to be laughable. Bonus points for
CD-ROM format with the Rock Ridge extensions (I _think_ DVDs
and later use that format too, yes?), though if that
didn't work tar files are an easy workaround. Imagine a full
Linux kernel source repository, for 30+ (pick a number) years..
can the filesystems handle the number of objects in those cases?
If it works, your infrastructure should be sufficiently
portable to "just work" on others too.
Anyway, my two cents.
--- David A. Wheeler
^ permalink raw reply
* active_cache leaks
From: Brad Roberts @ 2005-04-17 7:07 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1071 bytes --]
Ok.. so there's been a couple attempts to patch the leak that were all
wrong due to mixed memory management for that array. Here's a seed for
discussion on how to plug that leak. Some would argue that it's not
leaking enough to fix, but for those that want to turn git into a library,
the lifetime of the cache could end up not being short any more, so it's
worth discussing how to fix it.
The q&d fix in this patch isn't elegant, but gets the job done. More
interesting could be to have the entry itself contain a state bit, though
that wastes storage space.
Two basic changes:
1) introduce a set_active_cache() api and change all 'active_cache[i] = ce'
calls to use it.
2) add a active_cache_malloced array to parallel the active_cache array.
I don't like #2, but see that q&d comment. :)
It's only lightly tested as I'm still trying to wrap my head around how to
actually use git and git-pasky.
I was tempted to add a get_cache_entry api as well, so that nothing
outside of read-cache.c touched active_cache directly, but that can come
next.
Later,
Brad
[-- Attachment #2: git-active-cache-leak.diff --]
[-- Type: TEXT/plain, Size: 2921 bytes --]
--- cache.h
+++ cache.h 2005-04-16 23:08:37.000000000 -0700
@@ -88,6 +88,7 @@
extern int read_cache(void);
extern int write_cache(int newfd, struct cache_entry **cache, int entries);
extern int cache_name_pos(const char *name, int namelen);
+extern int set_cache_entry(struct cache_entry *ce, int pos, int malloced_entry);
extern int add_cache_entry(struct cache_entry *ce, int ok_to_add);
extern int remove_file_from_cache(char *path);
extern int cache_match_stat(struct cache_entry *ce, struct stat *st);
--- read-cache.c
+++ read-cache.c 2005-04-16 23:32:34.000000000 -0700
@@ -8,6 +8,7 @@
const char *sha1_file_directory = NULL;
struct cache_entry **active_cache = NULL;
+static int * active_cache_malloced = NULL;
unsigned int active_nr = 0, active_alloc = 0;
void usage(const char *err)
@@ -381,6 +382,15 @@
return ce_namelen(b) == len && !memcmp(a->name, b->name, len);
}
+int set_cache_entry(struct cache_entry *ce, int pos, int malloced_entry)
+{
+ if (active_cache_malloced[pos])
+ free(active_cache[pos]);
+ active_cache[pos] = ce;
+ active_cache_malloced[pos] = malloced_entry;
+ return 0;
+}
+
int add_cache_entry(struct cache_entry *ce, int ok_to_add)
{
int pos;
@@ -389,7 +399,7 @@
/* existing match? Just replace it */
if (pos >= 0) {
- active_cache[pos] = ce;
+ set_cache_entry(ce, pos, 0);
return 0;
}
pos = -pos-1;
@@ -414,13 +424,16 @@
if (active_nr == active_alloc) {
active_alloc = alloc_nr(active_alloc);
active_cache = realloc(active_cache, active_alloc * sizeof(struct cache_entry *));
+ active_cache_malloced = realloc(active_cache, active_alloc * sizeof(int));
}
/* Add it in.. */
active_nr++;
- if (active_nr > pos)
+ if (active_nr > pos) {
memmove(active_cache + pos + 1, active_cache + pos, (active_nr - pos - 1) * sizeof(ce));
- active_cache[pos] = ce;
+ memmove(active_cache_malloced + pos + 1, active_cache_malloced + pos, (active_nr - pos - 1) * sizeof(int));
+ }
+ set_cache_entry(ce, pos, 1);
return 0;
}
@@ -482,12 +495,13 @@
active_nr = ntohl(hdr->hdr_entries);
active_alloc = alloc_nr(active_nr);
active_cache = calloc(active_alloc, sizeof(struct cache_entry *));
+ active_cache_malloced = calloc(active_alloc, sizeof(int));
offset = sizeof(*hdr);
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = map + offset;
offset = offset + ce_size(ce);
- active_cache[i] = ce;
+ set_cache_entry(ce, i, 0);
}
return active_nr;
--- update-cache.c
+++ update-cache.c 2005-04-16 23:33:28.000000000 -0700
@@ -199,11 +199,14 @@
struct cache_entry *ce = active_cache[i];
struct cache_entry *new = refresh_entry(ce);
+ if (new == ce)
+ continue;
+
if (!new) {
printf("%s: needs update\n", ce->name);
continue;
}
- active_cache[i] = new;
+ set_cache_entry(new, i, 1);
}
}
^ permalink raw reply
* Re: [PATCH] libgit
From: Brad Roberts @ 2005-04-17 7:30 UTC (permalink / raw)
To: git
> Converted git to libgit. Moved all the main() calls into a single
> multi-call binary - git-main.
> Made extern a bunch of functions that were static. Verified it at least
> still minimally worked.
> Note: this is only a first step towards creating a generic library.
> Figuring out what functions and variables *truly* need to be exported,
> renaming them to a git_<function> api, making it thread safe
> ... and not least of all, keeping up with everybody working out of the
> base tree... are problems that remain. Also - cleaning up the UI.
Why do all that static and main rearrangement? It would be a lot simpler
and cleaner to simply rename the main's in place and add the new
dispatcher by itself.
Later,
Brad
^ permalink raw reply
* [PATCH] Trivial typofix in file creation mode.
From: Junio C Hamano @ 2005-04-17 8:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This patch fixes an obvious typo whose consequence is rather
disastrous in the file creation mode. Relative to Linus HEAD
85dd8bdfbbc6b1431230ebadc7e0af2ca94fed9f.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
checkout-cache.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
checkout-cache.c: 3b4f2644861bbd74713c51ef8e612d2fc84941d3
--- checkout-cache.c
+++ checkout-cache.c 2005-04-17 00:55:34.000000000 -0700
@@ -54,7 +54,7 @@
{
int fd;
- mode = (mode & 0100) ? 777 : 666;
+ mode = (mode & 0100) ? 0777 : 0666;
fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
if (fd < 0) {
if (errno == ENOENT) {
^ permalink raw reply
* Re: [PATCH] libgit
From: Mike Taht @ 2005-04-17 8:08 UTC (permalink / raw)
To: Brad Roberts; +Cc: git
In-Reply-To: <Pine.LNX.4.44.0504170027500.2625-100000@bellevue.puremagic.com>
Brad Roberts wrote:
>>Converted git to libgit. Moved all the main() calls into a single
>>multi-call binary - git-main.
>>Made extern a bunch of functions that were static. Verified it at least
>>still minimally worked.
>>Note: this is only a first step towards creating a generic library.
>>Figuring out what functions and variables *truly* need to be exported,
>>renaming them to a git_<function> api, making it thread safe
>>... and not least of all, keeping up with everybody working out of the
>>base tree... are problems that remain. Also - cleaning up the UI.
>
>
> Why do all that static and main rearrangement? It would be a lot simpler
> and cleaner to simply rename the main's in place and add the new
> dispatcher by itself.
0) I like multi-call binaries.
1) I wanted to get a first pass at what functions needed to be exported,
and pulling out the mains was the fastest way to see what might be needed.
2) Agreed, about half of git-main.c needs to move back into the
libraries, but that depends on deciding on the API for the formentioned
functions... and leaving the mains parsing argv in the library itself
seemed silly. So I moved them out. See 1)
In particular gotta chose the prefix itself git_<function> or
cg_<_function> or cogito_<function>. I lean towards git_ myself -
it'short and unique-looking, though I haven't verified that
When the useful to export functions are clearly identified they have to
become named thus.
3) I'd really like to commonalize the UI and use longopts for the
argument parsing. Linus indicated a preference for a certain argument
order, longopts doesn't do that.
4) Like to make git thread safe (and ultimately, thread using - parallel
diff, merge, fsck) and that means eliminating the globals, where
appropriate. I've been thinking through the issues there (how about
(GIT_THREAD)->some_variable and (GIT-GLOBAL)->some_variable where those
define out when threads are disabled? Etc. There needs to be a git_init
that does things like correctly and universally setting up the defaults,
and atexit, etc, file locking needs to fixed...
5) I wanted to get something that still compiled, worked, and out for
comment before I went to bed. :)
my current plan is to break out git.h back into it's subject
"update-cache.h" etc, move all that into include/git, turn git.h into a
master lazy man's include, come up with a scheme for the globals, get
some sort of thread cleanliness and take a crack at making it shared.
and now to bed. All: Feel free to implement any of that....
>
> Later,
> Brad
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Mike Taht
"If you wait long enough, it will go away... after having done its
damage.
If it was bad, it will be back."
^ permalink raw reply
* Re: Storing permissions
From: Paul Jackson @ 2005-04-17 8:13 UTC (permalink / raw)
To: dwheeler; +Cc: torvalds, mwelinder, mj, git
In-Reply-To: <42620092.9040402@dwheeler.com>
David wrote:
> There's a minor reason to write out ALL the perm bit data, but
There's always the 'configurable option' approach.
Someone, I doubt Linus will have any interest in it, could volunteer to
make the masks of st_mode, used when storing and recovering file
permissions, be configurable by some environment variable settings,
which default to whatever Linus provided.
But, in general, if you want a generalized backup system, git is not it.
Git skips all files whose name begins with the dot '.' character, and
anything that is not a regular file or directory. Git makes no
concessions to working adequately on file systems lacking normal inode
numbers (such as smb, fat, vfat). Git obscures the archive format a
modest amount, for pure speed and to encourage use only via appropriate
wrappers. Git is tuned for blazing speed at the operations that Linus
needs, not for trivial recovery, using the most basic tools, under harsh
circumstances.
The basic idea of using such an 'object database' (though I dislike that
term -- too high falutin vague) of files stored by their hash is a
good one. But a different core implementation is needed for backups.
I have one that I use for my own backups, but it is written in Python,
and uses MD5, one or the other of which likely disqualifies it from
further consideration by half the readers of this list.
--
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
* [PATCH] Really honor umask when creating files
From: Junio C Hamano @ 2005-04-17 8:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
The stated plan was to create new files with either 0666 or 0777
and let the system take care of applying umask(). Running
fchmod afterwards defeats this plan, so drop it.
You still need to spell your octals with prefix in addition to
this patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
checkout-cache.c | 2 --
1 files changed, 2 deletions(-)
checkout-cache.c: a87022a97c4604ef42ae6c31d641dc749a076ca3
--- checkout-cache.c
+++ checkout-cache.c 2005-04-17 01:11:17.000000000 -0700
@@ -62,8 +62,6 @@
fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
}
}
- if (fd >= 0)
- fchmod(fd, mode);
return fd;
}
^ permalink raw reply
* Re: Yet another base64 patch
From: Paul Jackson @ 2005-04-17 8:16 UTC (permalink / raw)
To: dwheeler; +Cc: git
In-Reply-To: <42620452.4080809@dwheeler.com>
David wrote:
> My list would be:
> ext2, ext3, NFS, and Windows' NTFS (stupid short filenames,
> case-insensitive/case-preserving).
I'm no mind reader, but I'd bet a pretty penny that what you have in
mind and what Linus has in mind have no overlaps in their solution sets.
Happy coding ...
--
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
* [PATCH] Fix update-cache --remove fix.
From: Junio C Hamano @ 2005-04-17 8:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
There is a boundary case bug in the update-cache --remove fix I
sent earlier, which results in a segfault when trying to remove
a nonexistent name that sorts later than anything in the
dircache. Here is a fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
read-cache.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
read-cache.c: 60b8efb3201fbf0a67bef48775bd1c9a1ccae2ff
--- read-cache.c
+++ read-cache.c 2005-04-17 01:50:00.000000000 -0700
@@ -371,7 +371,8 @@
int pos = cache_name_pos(path, strlen(path));
if (pos < 0)
pos = -pos-1;
- while (! strcmp(active_cache[pos]->name, path))
+ while ((pos < active_nr) &&
+ ! strcmp(active_cache[pos]->name, path))
remove_entry_at(pos);
return 0;
}
^ permalink raw reply
* [PATCH] Better error message from checkout-cache for unmerged files.
From: Junio C Hamano @ 2005-04-17 9:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
The checkout-cache command says "file is not in the cache" when
an unmerged path is given. This patch adds code to distinguish
the unmerged and the nonexistent cases and gives an appropriate
error message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
checkout-cache.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
checkout-cache.c: e16619c9d099367c224fb485f5525d66267bbd92
--- checkout-cache.c
+++ checkout-cache.c 2005-04-17 01:49:01.000000000 -0700
@@ -121,8 +121,15 @@
{
int pos = cache_name_pos(name, strlen(name));
if (pos < 0) {
- if (!quiet)
- fprintf(stderr, "checkout-cache: %s is not in the cache\n", name);
+ if (!quiet) {
+ pos = -pos - 1;
+ fprintf(stderr,
+ "checkout-cache: %s is %s.\n",
+ name,
+ (pos < active_nr &&
+ !strcmp(active_cache[pos]->name, name)) ?
+ "unmerged" : "not in the cache");
+ }
return -1;
}
return checkout_entry(active_cache[pos]);
^ permalink raw reply
* Summary of "read-tree -m O A B" mechanism
From: Junio C Hamano @ 2005-04-17 10:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vll7i95u1.fsf_-_@assigned-by-dhcp.cox.net>
Earlier I wrote down a list of issues your recent "merge
stage" changes have introduced to the rest of the plumbing, with
a set of suggested adaptions. I think all of them are cleared
now (you have a pile of patches from me in your mailbox).
I do not know what percentage of people on this list are using
git without the Cogito part, but I suspect that the number might
be quite small. I also suspect, from the description Petr gave
us on how the merging in Cogito works, Cogito does not currently
use the "read-tree -m O A B" mechanism, and those majority who
do not deal with the low level tools themselves would not have
to know about the merge issues yet. But I think it is a good
time, now things have started to settle down, to summarize how
various commands work when they see those "funny" dircache
entries created after "read-tree -m O A B" has run. Of course,
people working on Cogito needs to know them, once they decide to
use the "reed-tree -m O A B" mechanism.
* read-tree -m O A B
- For description on how this works, the definitive reading
is [*R1*]. In short:
- unlike ordinary read-tree, "-m" form reads up to three
trees and creates paths that are "unmerged".
- trivial merges are done by read-tree itself. only
conflicting paths will be in unmerged state when
read-tree returns.
* write-tree
- write-tree refuses to give you a tree until all the
unmerged paths are resolved.
* show-files
- "show-files --unmerged" and "show-files --stage" can be
used to examine detailed information on unmerged paths.
For an unmerged path, instead of recording a single
mode/SHA1 pair, the dircache records up to three such
pairs; one from tree O in stage 1, A in stage 2, and B in
stage 3. This information can be used by the user (or
Cogito) to see what should eventually be recorded at the
path.
* update-cache
- An explicit "update-cache [--add] path" or "update-cache
[--add] --cacheinfo mode SHA1 path" tells the plumbing that
the user (or Cogito) wants to resolve it by storing
mode/SHA1 of the given working file or mode SHA1 specified
on the command line. The path ceases to be in unmerged
state after this happens.
Similarly, "update-cache --remove path" resolves the
unmerged state and the merge result is not having anything
at that path.
- "update-cache --refresh", in addition to the "needs update"
message people are now familiar with, says "needs merge"
for unmerged paths.
* show-diff
- show-diff on an unmerged path simply says "unmerged" (the
plumbing would not know what to diff with what among three
stages and the working file).
* checkout-cache
- "checkout-cache -a" warns about unmerged paths and checks
out only the merged paths.
- "checkout-cache [-f] path" on an unmerged path says
"Unmerged", just like the same command on non-existent path
says "not in the cache", and does not touch the working
file.
I hope the descriptions in this summary is correct enough to be
useful to somebody.
[Reference]
*R1* http://marc.theaimsgroup.com/?l=git&m=111363270608902&w=2
^ permalink raw reply
* [PATCH] Remove unused arguments from index_fd()
From: Junio C Hamano @ 2005-04-17 10:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
The function index_fd() in update-cache.c takes 5 arguments, but
two is not necessary and one that is a pointer to a structure
really needs to be a pointer to one member of that structure.
This patch cleans it up.
Also it removes printf() apparently left after initial
debugging.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
update-cache.c | 15 ++++++---------
1 files changed, 6 insertions(+), 9 deletions(-)
update-cache.c: 5afecd1a4fd90d2505753ce2d5044d780fe69a7f
--- update-cache.c
+++ update-cache.c 2005-04-17 03:22:39.000000000 -0700
@@ -14,13 +14,13 @@
*/
static int allow_add = 0, allow_remove = 0;
-static int index_fd(const char *path, int namelen, struct cache_entry *ce, int fd, struct stat *st)
+static int index_fd(unsigned char *sha1, int fd, struct stat *st)
{
z_stream stream;
unsigned long size = st->st_size;
- int max_out_bytes = namelen + size + 200;
+ int max_out_bytes = size + 200;
void *out = malloc(max_out_bytes);
- void *metadata = malloc(namelen + 200);
+ void *metadata = malloc(200);
void *in;
SHA_CTX c;
@@ -56,9 +56,9 @@
SHA1_Init(&c);
SHA1_Update(&c, out, stream.total_out);
- SHA1_Final(ce->sha1, &c);
+ SHA1_Final(sha1, &c);
- return write_sha1_buffer(ce->sha1, out, stream.total_out);
+ return write_sha1_buffer(sha1, out, stream.total_out);
}
/*
@@ -109,7 +109,7 @@
ce->ce_mode = create_ce_mode(st.st_mode);
ce->ce_flags = htons(namelen);
- if (index_fd(path, namelen, ce, fd, &st) < 0)
+ if (index_fd(ce->sha1, fd, &st) < 0)
return -1;
return add_cache_entry(ce, allow_add);
@@ -244,13 +244,10 @@
if (sscanf(arg1, "%o", &mode) != 1)
return -1;
- printf("got mode %o\n", mode);
if (get_sha1_hex(arg2, sha1))
return -1;
- printf("got sha1 %s\n", sha1_to_hex(sha1));
if (!verify_path(arg3))
return -1;
- printf("got path %s\n", arg3);
len = strlen(arg3);
size = cache_entry_size(len);
^ permalink raw reply
* [PATCH] use gcrypt instead of libssl for hash
From: Junichi Uekawa @ 2005-04-17 10:52 UTC (permalink / raw)
To: torvalds, git
[-- Attachment #1: Type: text/plain, Size: 4691 bytes --]
Hi,
This is the first time for me to send you a patch; be gentle.
the following patch allows for use of gcrypt.
libssl seems to have a restrictive licensing wrt GPL applications.
This patch adds a requirement for libgcrypt11, and
removes the requirement for libssl.
I hope I have not overlooked anything.
Signed-off-by: Junichi Uekawa <dancer@debian.org>
Makefile: 770595e02be4a9a55ff98910c53617c3b0f1e145
--- Makefile
+++ Makefile 2005-04-17 19:38:00.000000000 +0900
@@ -7,7 +7,7 @@
# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
# break unless your underlying filesystem supports those sub-second times
# (my ext3 doesn't).
-CFLAGS=-g -O3 -Wall
+CFLAGS=-g -O3 -Wall $(shell libgcrypt-config --cflags)
CC=gcc
@@ -21,7 +21,7 @@
install: $(PROG)
install $(PROG) $(HOME)/bin/
-LIBS= -lssl -lz
+LIBS= $(shell libgcrypt-config --libs) -lz
init-db: init-db.o
cache.h: 5948db759b3f6fb5ade3b027f202330f71a8cb6a
--- cache.h
+++ cache.h 2005-04-17 19:25:40.000000000 +0900
@@ -12,7 +12,7 @@
#include <sys/mman.h>
#include <netinet/in.h>
-#include <openssl/sha.h>
+#include <gcrypt.h>
#include <zlib.h>
/*
read-cache.c: 740ffcce7026b268bd4dfe1d0a773ad7e3a24f96
--- read-cache.c
+++ read-cache.c 2005-04-17 19:34:37.000000000 +0900
@@ -116,11 +116,14 @@
int check_sha1_signature(unsigned char *sha1, void *map, unsigned long size)
{
unsigned char real_sha1[20];
- SHA_CTX c;
+ gcry_md_hd_t c;
- SHA1_Init(&c);
- SHA1_Update(&c, map, size);
- SHA1_Final(real_sha1, &c);
+ gcry_md_open(&c, GCRY_MD_SHA1, 0);
+ gcry_md_write(c, map, size);
+ gcry_md_final(c);
+ memcpy(real_sha1, gcry_md_read(c, 0), 20);
+ gcry_md_close(c);
+
return memcmp(sha1, real_sha1, 20) ? -1 : 0;
}
@@ -203,7 +206,7 @@
char *compressed;
z_stream stream;
unsigned char sha1[20];
- SHA_CTX c;
+ gcry_md_hd_t c;
/* Set it up */
memset(&stream, 0, sizeof(stream));
@@ -222,9 +225,11 @@
size = stream.total_out;
/* Sha1.. */
- SHA1_Init(&c);
- SHA1_Update(&c, compressed, size);
- SHA1_Final(sha1, &c);
+ gcry_md_open(&c, GCRY_MD_SHA1, 0);
+ gcry_md_write(c, compressed, size);
+ gcry_md_final(c);
+ memcpy(sha1, gcry_md_read(c, 0), 20);
+ gcry_md_close(c);
if (write_sha1_buffer(sha1, compressed, size) < 0)
return -1;
@@ -425,17 +430,20 @@
static int verify_hdr(struct cache_header *hdr, unsigned long size)
{
- SHA_CTX c;
+ gcry_md_hd_t c;
unsigned char sha1[20];
if (hdr->hdr_signature != htonl(CACHE_SIGNATURE))
return error("bad signature");
if (hdr->hdr_version != htonl(1))
return error("bad version");
- SHA1_Init(&c);
- SHA1_Update(&c, hdr, offsetof(struct cache_header, sha1));
- SHA1_Update(&c, hdr+1, size - sizeof(*hdr));
- SHA1_Final(sha1, &c);
+ gcry_md_open(&c, GCRY_MD_SHA1, 0);
+ gcry_md_write(c, hdr, offsetof(struct cache_header, sha1));
+ gcry_md_write(c, hdr+1, size - sizeof(*hdr));
+ gcry_md_final(c);
+ memcpy(sha1, gcry_md_read(c, 0), 20);
+ gcry_md_close(c);
+
if (memcmp(sha1, hdr->sha1, 20))
return error("bad header sha1");
return 0;
@@ -498,7 +506,8 @@
int write_cache(int newfd, struct cache_entry **cache, int entries)
{
- SHA_CTX c;
+ gcry_md_hd_t c;
+
struct cache_header hdr;
int i;
@@ -506,14 +515,16 @@
hdr.hdr_version = htonl(1);
hdr.hdr_entries = htonl(entries);
- SHA1_Init(&c);
- SHA1_Update(&c, &hdr, offsetof(struct cache_header, sha1));
+ gcry_md_open(&c, GCRY_MD_SHA1, 0);
+ gcry_md_write(c, &hdr, offsetof(struct cache_header, sha1));
for (i = 0; i < entries; i++) {
struct cache_entry *ce = cache[i];
int size = ce_size(ce);
- SHA1_Update(&c, ce, size);
+ gcry_md_write(c, ce, size);
}
- SHA1_Final(hdr.sha1, &c);
+ gcry_md_final(c);
+ memcpy(hdr.sha1, gcry_md_read(c, 0), 20);
+ gcry_md_close(c);
if (write(newfd, &hdr, sizeof(hdr)) != sizeof(hdr))
return -1;
update-cache.c: 5afecd1a4fd90d2505753ce2d5044d780fe69a7f
--- update-cache.c
+++ update-cache.c 2005-04-17 19:36:40.000000000 +0900
@@ -22,7 +22,7 @@
void *out = malloc(max_out_bytes);
void *metadata = malloc(namelen + 200);
void *in;
- SHA_CTX c;
+ gcry_md_hd_t c;
in = "";
if (size)
@@ -54,9 +54,11 @@
deflateEnd(&stream);
- SHA1_Init(&c);
- SHA1_Update(&c, out, stream.total_out);
- SHA1_Final(ce->sha1, &c);
+ gcry_md_open(&c, GCRY_MD_SHA1, 0);
+ gcry_md_write(c, out, stream.total_out);
+ gcry_md_final(c);
+ memcpy(ce->sha1, gcry_md_read(c, 0), 20);
+ gcry_md_close(c);
return write_sha1_buffer(ce->sha1, out, stream.total_out);
}
write-tree.c: 34a351b20fb38ea588f34bd9634f101b9dc533cb
regards,
junichi
--
Junichi Uekawa, Debian Developer
17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
http://www.netfort.gr.jp/~dancer/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [patch] fix for memory leak in write-tree.c
From: Brad Roberts @ 2005-04-17 11:21 UTC (permalink / raw)
To: git
I've made my tree rsync'able:
rsync://gameboy2.puremagic.com/git
commit 1cdbc0a19b8d9b68f1f42735e2f14f1289823a63
tree 0e060fed0642337e675368913ec8d4f910a9f019
parent 11ed64c1b141c9ba397a1ca76aef2cd250976007
author Brad Roberts,,, <braddr@gameboy2> 1113736632 -0700
committer Brad Roberts,,, <braddr@gameboy2> 1113736632 -0700
Fix a memory leak in write-tree.c, not freeing the directory buffer.
Index: write-tree.c
===================================================================
--- 51b1bddbbc05e50d5bbf1f9662e503c2e85d5e96/write-tree.c (mode:100644 sha1:34a351b20fb38ea588f34bd9634f101b9dc533cb)
+++ 0e060fed0642337e675368913ec8d4f910a9f019/write-tree.c (mode:100644 sha1:fb046aa6ce6b9fce6a523a1e36ff43adab9bdd93)
@@ -93,10 +93,8 @@
i -= 5;
memcpy(buffer+i, "tree ", 5);
- buffer += i;
- offset -= i;
-
- write_sha1_file(buffer, offset, returnsha1);
+ write_sha1_file(buffer + i, offset - i, returnsha1);
+ free(buffer);
return nr;
}
^ permalink raw reply
* Re: fix for memory leak in write-tree.c
From: Petr Baudis @ 2005-04-17 11:23 UTC (permalink / raw)
To: Brad Roberts; +Cc: git
In-Reply-To: <Pine.LNX.4.44.0504170418390.2625-100000@bellevue.puremagic.com>
Dear diary, on Sun, Apr 17, 2005 at 01:21:56PM CEST, I got a letter
where Brad Roberts <braddr@puremagic.com> told me that...
> I've made my tree rsync'able:
>
> rsync://gameboy2.puremagic.com/git
>
>
> commit 1cdbc0a19b8d9b68f1f42735e2f14f1289823a63
> tree 0e060fed0642337e675368913ec8d4f910a9f019
> parent 11ed64c1b141c9ba397a1ca76aef2cd250976007
> author Brad Roberts,,, <braddr@gameboy2> 1113736632 -0700
> committer Brad Roberts,,, <braddr@gameboy2> 1113736632 -0700
If we are supposed to merge with you, it would be nice if you used a
real email address. (The commas are livable but if you can get rid of
them... ;-)
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
* [PATCH] Fix +x-related show-diff false positives
From: Petr Baudis @ 2005-04-17 11:44 UTC (permalink / raw)
To: torvalds; +Cc: git
Hi,
the following patch fixes show-diff listing all +x files as differring.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
--- read-cache.c
+++ read-cache.c 2005-04-17 13:42:13.322938268 +0200
@@ -306,7 +306,7 @@
ce->ce_gid != htonl(st->st_gid))
changed |= OWNER_CHANGED;
/* We consider only the owner x bit to be relevant for "mode changes" */
- if (0100 & (ntohs(ce->ce_mode) ^ st->st_mode))
+ if (0100 & (ntohl(ce->ce_mode) ^ st->st_mode))
changed |= MODE_CHANGED;
if (ce->ce_dev != htonl(st->st_dev) ||
ce->ce_ino != htonl(st->st_ino))
(It is against my tree, but I think it should apply cleanly to yours
too; perhaps with a tiny offset.)
Kind regards,
--
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] fork optional branch point normazilation
From: Brad Roberts @ 2005-04-17 12:04 UTC (permalink / raw)
To: git
(ok, author looks better, but committer doesn't obey the AUTHOR_ vars yet)
This might not be how you intended git fork to behave, but without doing
_something_ to protect the head parameter a bit, this is just asking for a
corrutped .git/HEAD file.
commit 76faec069dfeae59c3ce5faaad10bdcded0cc908
tree c291316b28eff4042c80850cd93445345a606835
parent 1cdbc0a19b8d9b68f1f42735e2f14f1289823a63
author Brad Roberts <braddr@puremagic.com> 1113738584 -0700
committer Brad Roberts,,, <braddr@gameboy2> 1113738584 -0700
gitfork needs to normalize the optional third parameter before using it.
Index: gitfork.sh
===================================================================
--- 51b1bddbbc05e50d5bbf1f9662e503c2e85d5e96/gitfork.sh (mode:100755 sha1:e5692ea9bdbc39b028fe1e1205381da632541bab)
+++ c291316b28eff4042c80850cd93445345a606835/gitfork.sh (mode:100755 sha1:386148ae9a99739d06a09742ff4157d0f7e4e223)
@@ -37,6 +37,7 @@
[ -e "$destdir" ] && die "$destdir already exists"
[ "$head" ] || head=$(commit-id)
+head=$(gitXnormid.sh -c $head)
git lntree "$destdir"
echo $head >.git/heads/$name
^ permalink raw reply
* Re: using git directory cache code in darcs?
From: David Roundy @ 2005-04-17 12:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, darcs-devel
In-Reply-To: <Pine.LNX.4.58.0504161531470.7211@ppc970.osdl.org>
On Sat, Apr 16, 2005 at 03:43:02PM -0700, Linus Torvalds wrote:
> On Sat, 16 Apr 2005, David Roundy wrote:
> > 1) Would this actually be a good idea? It seems good to me, but there may
> > be other considerations that I haven't thought of.
>
> I really don't know how well the git index file will work with darcs, and
> the main issue is that the index file names the "stable copy" using the
> sha1 hash. If darcs uses something else (and I imagine it does) you'd
> need to do a fair amount of surgery, and I suspect merging changes won't
> be very easy.
Oh, I'm starting to see (having just browsed the git code for another half
hour or so)... I had been under the (false) impression that the index file
stored the contents of the files themselves, which in retrospect doesn't
make any sense. So when you run update-cache --add, the file data itself
immediately goes into its final hashed location, and only the sha1 info
goes into the index.
That's all right. Darcs would only access the cached data through a
git-caching layer, and we've already got an abstraction layer over the
pristine cache. As long as the git layer can quickly retrieve the contents
of a given file, we should be fine.
The sha1 file and tree hashing isn't direcly useful for darcs, but people
will want to interoperate with git, and for that it would be nice to be
able to know what the hash of a given version is. I imagine something like
darcs tag --git
which would tag the current version with its git hash. Of course, to
implement that we only need to reproduce your algorithm for hashing trees,
which probably would be easier to do ourselves without using any git
code... but it would be far faster to recompute with the git backend, since
git stores the hashes of all the unmodified files, and since I also imagine
darcs record --git
which would record a change, and then tag the resulting tree with a git
hash, we might be recomputing the git hashes reasonably often, and we
certainly don't want to rehash the entire kernel each time! :)
> So it might well make sense to wait a bit, until the git thing has calmed
> down some more. For example, I made some rather large changes
> (conceptually, if not in layout of the physical file) to the index file
> just yesterday, since git now uses it for merging too.
>
> In git, the index file isn't just a speedup, it's the "work" file _and_
> the merge entity. It's not just a floor wax, it's a dessert topping too!
I think that sounds like a pretty reasonable match. In darcs, there are
internally two main datatypes. One is the Patch (as you might imagine),
and the other is called a "Slurpy", which is basically a tree lazily
"slurped" into memory.
The pristine cache is then just a way of storing the tree and so we can
"slurp" it again later to retrieve the current state. So in a sense we'd
be using only one side of the index file interface, the "working directory"
side, where you check files out and add files in--treating it as an
fast filesystem with a few extra-fancy features (like storing inodes of the
files in the working directory).
> I think libgit might make sense, but again, not quite yet. Maybe the new
> merge model was my last smart thought even on the subject of SCM's (I kind
> of hope so), but maybe it's not.
>
> My gut _feel_ is that the basic git low-level architecture is done, and
> you can certainly start looking around and see if it matches darcs at all.
Sounds good. That's sort of the feel I had gotten from other people's
responses as well. We'll definitely look into how we can use (and
interface with) git.
--
David Roundy
http://www.darcs.net
^ permalink raw reply
* Re: fork optional branch point normazilation
From: Petr Baudis @ 2005-04-17 12:25 UTC (permalink / raw)
To: Brad Roberts; +Cc: git
In-Reply-To: <Pine.LNX.4.44.0504170451030.2625-100000@bellevue.puremagic.com>
Dear diary, on Sun, Apr 17, 2005 at 02:04:16PM CEST, I got a letter
where Brad Roberts <braddr@puremagic.com> told me that...
> This might not be how you intended git fork to behave, but without doing
> _something_ to protect the head parameter a bit, this is just asking for a
> corrutped .git/HEAD file.
>
> commit 76faec069dfeae59c3ce5faaad10bdcded0cc908
> tree c291316b28eff4042c80850cd93445345a606835
> parent 1cdbc0a19b8d9b68f1f42735e2f14f1289823a63
> author Brad Roberts <braddr@puremagic.com> 1113738584 -0700
> committer Brad Roberts,,, <braddr@gameboy2> 1113738584 -0700
>
> gitfork needs to normalize the optional third parameter before using it.
>
> Index: gitfork.sh
> ===================================================================
> --- 51b1bddbbc05e50d5bbf1f9662e503c2e85d5e96/gitfork.sh (mode:100755 sha1:e5692ea9bdbc39b028fe1e1205381da632541bab)
> +++ c291316b28eff4042c80850cd93445345a606835/gitfork.sh (mode:100755 sha1:386148ae9a99739d06a09742ff4157d0f7e4e223)
> @@ -37,6 +37,7 @@
> [ -e "$destdir" ] && die "$destdir already exists"
>
> [ "$head" ] || head=$(commit-id)
> +head=$(gitXnormid.sh -c $head)
>
> git lntree "$destdir"
> echo $head >.git/heads/$name
commit-id always returns the normalized commit ID.
--
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: fork optional branch point normazilation
From: Brad Roberts @ 2005-04-17 12:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050417122534.GD1487@pasky.ji.cz>
> >
> > Index: gitfork.sh
> > ===================================================================
> > --- 51b1bddbbc05e50d5bbf1f9662e503c2e85d5e96/gitfork.sh (mode:100755 sha1:e5692ea9bdbc39b028fe1e1205381da632541bab)
> > +++ c291316b28eff4042c80850cd93445345a606835/gitfork.sh (mode:100755 sha1:386148ae9a99739d06a09742ff4157d0f7e4e223)
> > @@ -37,6 +37,7 @@
> > [ -e "$destdir" ] && die "$destdir already exists"
> >
> > [ "$head" ] || head=$(commit-id)
> > +head=$(gitXnormid.sh -c $head)
> >
> > git lntree "$destdir"
> > echo $head >.git/heads/$name
>
> commit-id always returns the normalized commit ID.
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
>
This feels better to me. Diffed against my previus commit. The problem
was that commit-id wasn't called if a branch point was specified nor was
that value checked for validity.
Index: gitfork.sh
===================================================================
--- c9ccaa172ccab8e56f2fe621ee24896bfddacf26/gitfork.sh (mode:100755 sha1:386148ae9a99739d06a09742ff4157d0f7e4e223)
+++ f9e06a309f63ac6858d019b51f2172283378d2ef/gitfork.sh (mode:100755 sha1:dbb508b8431368fc95cc9516eada52f5bf0f8bc1)
@@ -16,7 +16,7 @@
name=$1
destdir=$2
-head=$3
+head=$(gitXnormid.sh -c $3)
die () {
echo gitfork.sh: $@ >&2
@@ -36,9 +36,6 @@
[ -e "$destdir" ] && die "$destdir already exists"
-[ "$head" ] || head=$(commit-id)
-head=$(gitXnormid.sh -c $head)
-
git lntree "$destdir"
echo $head >.git/heads/$name
ln -s heads/$name "$destdir/.git/HEAD"
^ 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