'git describe' is very slow on development trees with lots of commits

(Cc:-ed the Git development list.) * David Ahern wrote: > PERF-VERSION-GEN and specifically the git commands are the > cause of more delay than the config checks, especially when > doing the build in a VM with the kernel source on an NFS > mount. Yes, I have noticed that too. So, the probl

Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE

* Linus Torvalds wrote: > On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner wrote: > >> > >> It is spelled: > >> > >> git notes add -m SHA1 > > > > Cool! > > Don't use them for anything global. > > Use them for local codeflow, but don't expect them to be > distributed. It's a separate "fl

Re: qgit-0.7

* Marco Costalba <[EMAIL PROTECTED]> wrote: > So I cannot reproduce the bug. [...] weird - i cannot reproduce it either anymore, and annotate works now as advertised - it's fast and accurate as far as i checked. But i synced to the latest tree meanwhile. Perhaps i had an inconsistent tree? (i

Re: qgit-0.7

* Marco Costalba <[EMAIL PROTECTED]> wrote: > Here is qgit-0.7, a GUI git viewer. > > you can download from: > > http://prdownloads.sourceforge.net/qgit/qgit-0.7.tar.gz?download > > > This time a small changelog, but a lot of work ;-) > > - rewrite of graph drawing > - start-up loading: swit

Re: git-viz tool for visualising commit trees

* Olivier Andrieu <[EMAIL PROTECTED]> wrote: > > - naming the boxes by key is quite meaningless. It would be more > > informative to see the author's email shortcuts in the boxes. Also, it > > would be nice to see some simple graphical feedback about the size and > > scope of a chang

Re: git-viz tool for visualising commit trees

is the 'diff with ancestor' feature supposed to work at this early stage? (it just does nothing when i click on it. It correctly offers two ancestors for merge points, but does nothing there either.) Ingo - To unsubscribe from this list: send the line "unsubscribe git" in the body of a

Re: git-viz tool for visualising commit trees

another thing, when i 'zoom out' of the graph far away (so that the whole graph becomes visible on the screen), i'm getting lots of such error messages: *** attempt to put segment in horiz list twice *** attempt to put segment in horiz list twice *** attempt to put segment in horiz list twic

Re: git-viz tool for visualising commit trees

* Olivier Andrieu <[EMAIL PROTECTED]> wrote: > Yes, git-viz uses the `dot' program from the graphviz package (it's in > Fedora Extra too I believe). ah - that resolved all issues and i'm now running git-viz without any problems. I just checked how the kernel repository looks like with it, and

Re: git-viz tool for visualising commit trees

* Olivier Andrieu <[EMAIL PROTECTED]> wrote: > > Preprocessor error > > make: *** [viz_style.cmx] Error 2 > > That's probably because the configure script didn't find camlp4. > Camlp4 is a preprocessor for ocaml, it's needed for compiling this > file (viz_style.ml). Camlp4 is built with th

Re: git-viz tool for visualising commit trees

* Olivier Andrieu <[EMAIL PROTECTED]> wrote: > There, here's a tarball : > http://oandrieu.nerim.net/monotone-viz/git-viz-0.1.tar.gz i'm trying to build it under Fedora Core 4 (devel), and there are two problems: - the build scripts seem to assume that "." is in PATH (or that the needed

Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes

* Linus Torvalds <[EMAIL PROTECTED]> wrote: > Yeah, yeah, it looks different from "cvs update", but dammit, wouldn't > it be cool to just write "cg-" and see the command choices? > Or "cg-up" and get cg-update done for you.. add this line to your ~/.bashrc: complete -W "add addremote apply

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

* Petr Baudis <[EMAIL PROTECTED]> wrote: > Dear diary, on Wed, Apr 20, 2005 at 09:01:57AM CEST, I got a letter > where Ingo Molnar <[EMAIL PROTECTED]> told me that... > > [...] > > fatal: unable to execute 'gitmerge-file.sh' > > fatal: merge

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

* Petr Baudis <[EMAIL PROTECTED]> wrote: > > yet another thing: what is the canonical 'pasky way' of simply nuking > > the current files and checking out the latest tree (according to > > .git/HEAD). Right now i'm using a script to: > > > > read-tree $(tree-id $(cat .git/HEAD)) > > checkou

Re: git-viz tool for visualising commit trees

* Petr Baudis <[EMAIL PROTECTED]> wrote: > Hi, > > just FYI, Olivier Andrieu was kind enough to port his monotone-viz > tool to git (http://oandrieu.nerim.net/monotone-viz/ - use the one > from the monotone repository). The tool visualizes the history flow > nicely; see > > http://

Re: WARNING! Object DB conversion (was Re: [PATCH] write-tree performance problems)

* Linus Torvalds <[EMAIL PROTECTED]> wrote: > So to convert your old git setup to a new git setup, do the following: > [...] did this for two repositories (git and kernel-git), it works as advertised. Ingo - To unsubscribe from this list: send the line "unsubscribe git" in the body of

Re: enforcing DB immutability

* Ingo Molnar <[EMAIL PROTECTED]> wrote: > > perhaps having a new 'immutable hardlink' feature in the Linux VFS > > would help? I.e. a hardlink that can only be readonly followed, and > > can be removed, but cannot be chmod-ed to a writeable hardlink. That i

Re: enforcing DB immutability

* Ingo Molnar <[EMAIL PROTECTED]> wrote: > perhaps having a new 'immutable hardlink' feature in the Linux VFS > would help? I.e. a hardlink that can only be readonly followed, and > can be removed, but cannot be chmod-ed to a writeable hardlink. That i > think wou

enforcing DB immutability

* Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Wed, 13 Apr 2005, Ingo Molnar wrote: > > > > well, the 'owned by another user' solution is valid though, and doesnt > > have this particular problem. (We've got a secure multiuser OS, so can &g

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

* Petr Baudis <[EMAIL PROTECTED]> wrote: > > I think pull is pull. If you are doing lots of local stuff and do not > > want it overwritten, it should have been in a forked branch. > > I disagree. This already forces you to have two branches (one to pull > from to get the data, mirroring the re

Re: [script] ge: export commits as patches

* Petr Baudis <[EMAIL PROTECTED]> wrote: > Dear diary, on Tue, Apr 19, 2005 at 03:48:43PM CEST, I got a letter > where Ingo Molnar <[EMAIL PROTECTED]> told me that... > > is there any 'export commit as patch' support in git-pasky? I didnt find > > any su

Re: missing: git api, reference, user manual and mission statement

* Kevin Smith <[EMAIL PROTECTED]> wrote: > Klaus Robert Suetterlin wrote: > > 1) There is no clear (e.g. by name) distinction between ``git as done > > by Linus'', which is a kind of content addressable database with added > > semantics, and ``git as done by the rest of You'', which is a kind of

Re: naive question

* David Woodhouse <[EMAIL PROTECTED]> wrote: > On Tue, 2005-04-19 at 23:00 +1000, Paul Mackerras wrote: > > Is there a way to check out a tree without changing the mtime of any > > files that you have already checked out and which are the same as the > > version you are checking out? It seems th

[script] ge: export commits as patches

is there any 'export commit as patch' support in git-pasky? I didnt find any such command (maybe it got added meanwhile), so i'm using the 'ge' hack below. e.g. i typically look at commits via 'git log', and then when i see something interesting, i look at the commit via the 'ge' script. E.g.

Re: [patch] git: fix 1-byte overflow in show-files.c

* Petr Baudis <[EMAIL PROTECTED]> wrote: > > will attempt to append a "/" string to the directory name - resulting in > > a 1-byte overflow (a zero byte is written to offset 4097, which is > > outside the array). > > The name ends precisely at offset 4095 with its NUL character: > > {PAT

Re: Re: Merge with git-pasky II.

* Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Sun, 17 Apr 2005, Ingo Molnar wrote: > > > > in fact, this attack cannot even be proven to be malicious, purely via > > the email from Malice: it could be incredible bad luck that caused that > > good-looking

Re: Re: Merge with git-pasky II.

* Ingo Molnar <[EMAIL PROTECTED]> wrote: > The compromise relies on you having reviewed something harmless, while > in reality what happened within the DB was far less harmless. And the > DB remains self-consistent: neither fsck, nor others importing your > tree will be

Re: Re: Merge with git-pasky II.

* Brad Roberts <[EMAIL PROTECTED]> wrote: > While I agree that a hash collision is bad and certainly worth > preventing during new object creation, for it to actually implant a > trojan in a build successfully it'd have to meet even more criteria > than you've layed out. It'd have to... > -

Re: Re: Merge with git-pasky II.

* Linus Torvalds <[EMAIL PROTECTED]> 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. here is a bit complex

Re: [PATCH] Use libcurl to use HTTP to get repositories

* Daniel Barkalow <[EMAIL PROTECTED]> wrote: > Still leaks a bit of memory due to bug copied from read-tree. Linus, should i resend the 18 fixes i sent the other day? (as a GIT repository perhaps?) I found roughly 6 common memory leaks, 8 theoretical memory leaks, 2 overflows and did a couple

Re: full kernel history, in patchset format

* Linus Torvalds <[EMAIL PROTECTED]> wrote: > > the history data starts at 2.4.0 and ends at 2.6.12-rc2. I've included a > > script that will apply all the patches in order and will create a > > pristine 2.6.12-rc2 tree. > > Hey, that's great. I got the CVS repo too, and I was looking at it,

Re: full kernel history, in patchset format

* David Mansfield <[EMAIL PROTECTED]> wrote: > Ingo Molnar wrote: > >* Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > >>the patches contain all the existing metadata, dates, log messages and > >>revision history. (What i think is missing is t

Re: full kernel history, in patchset format

* Ingo Molnar <[EMAIL PROTECTED]> wrote: > the patches contain all the existing metadata, dates, log messages and > revision history. (What i think is missing is the BK tree merge > information, but i'm not sure we want/need to convert them to GIT.) author names are abb

Re: using git directory cache code in darcs?

* David Roundy <[EMAIL PROTECTED]> wrote: > 2) Will a license be chosen soon for git? Or has one been chosen, and > I missed it? I can't really include git code in darcs without a > license. I'd prefer GPLv2 or later (since that's how darcs is > licensed), but as long as it's at least compabi

full kernel history, in patchset format

i've converted the Linux kernel CVS tree into 'flat patchset' format, which gave a series of 28237 separate patches. (Each patch represents a changeset, in the order they were applied. I've used the cvsps utility.) the history data starts at 2.4.0 and ends at 2.6.12-rc2. I've included a script

Re: SHA1 hash safety

* David Lang <[EMAIL PROTECTED]> wrote: > this issue was raised a few days ago in the context of someone > tampering with the files and it was decided that the extra checks were > good enough to prevent this (at least for now), but what about > accidental collisions? > > if I am understanding

Re: Merge with git-pasky II.

* David Woodhouse <[EMAIL PROTECTED]> wrote: > On Fri, 2005-04-15 at 11:36 +0200, Ingo Molnar wrote: > > do such cases occur frequently? In the kernel at least it's not too > > typical. > > Isn't it? I thought it was a fairly accurate representation of th

Re: Merge with git-pasky II.

* David Woodhouse <[EMAIL PROTECTED]> wrote: > Consider a simple repository which contains two files A and B. We > start off with the first version of each ('A1B1'), and the owner of > each file takes a branch and modifies their own file. There is > cross-pulling between the two, and then each

Re: another perspective on renames.

* Paul Jackson <[EMAIL PROTECTED]> wrote: > Scott wrote: > > Anyway, maybe it's worth thinking a little about an SCM in which this is a > > feature, instead of (or in addition to) automatically assuming this is a > > bug we need to add infrastructure to work around. > > Agreed. > > To me, the

Re: Handling renames.

* Linus Torvalds <[EMAIL PROTECTED]> wrote: > [...] Ie if you notice a rename, you first commit the rename (and you > can _see_ it's a rename, since the object didn't change, and the sha1 > stayed the same, which in git-speak means that it is the same object, > ie that _is_ a rename as far as

Re: Handling renames.

* David Woodhouse <[EMAIL PROTECTED]> wrote: > I've been looking at tracking file revisions. One proposed solution > was to have a separate revision history for individual files, with a > new kind of 'filecommit' object which parallels the existing 'commit', > referencing a blob instead of a t

Re: [patch] git: fix memory leak #2 in read-cache.c

* Linus Torvalds <[EMAIL PROTECTED]> wrote: > In other words, if the common case is that we update a couple of > entries in the active cache, we actually saved 1.6MB (+ malloc > overhead for the 17 _thousand_ allocations) by my approach. > > And the leak? There's none. We never actually update

[patch] git: fix memory leak #3 in update-cache.c

the patch below fixes a third memory leak in update-cache.c. (the mmap-ed file needs to be unmapped too) Ontop of the previous update-cache.c patches. Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- update-cache.c.orig +++ update-cache.c @@ -32,6 +32,8 @@ static int in

Re: [patch] git: fix memory leak #2 in read-cache.c

* Ingo Molnar <[EMAIL PROTECTED]> wrote: > this patch fixes a memory leak in read-cache.c: when there's cache > entry collision we should free the previous one. > + free(active_cache[pos]); > active_cache[pos] = ce; i'm having s

[patch] git: fix memory leak in write-tree.c

this patch fixes a memory leak in write-tree.c's write_tree() function - we didnt free the temporary output buffer. Depending on the size of the tree written out this could leak a significant amount of RAM. Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- write-

[patch] git: clean up add_file_to_cache() in update-cache.c

emory leak. Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- update-cache.c.orig +++ update-cache.c @@ -120,10 +120,17 @@ static int add_file_to_cache(char *path) ce->st_size = st.st_size; ce->namelen = namelen; - if (index_fd(path, namelen, ce, fd

[patch] git: fix memory leaks in update-cache.c

this patch fixes two memory leaks in update-cache.c: we didnt free the temporary input and output buffers used for compression. Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- update-cache.c.orig +++ update-cache.c @@ -23,13 +23,17 @@ static int index_fd(const char *pa

[patch] git: fix 1-byte overflow in show-files.c

"/", 2); will attempt to append a "/" string to the directory name - resulting in a 1-byte overflow (a zero byte is written to offset 4097, which is outside the array). Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- show-files.c.orig +++ show-files.c

[patch] git: fix memory leak #2 in read-cache.c

this patch fixes a memory leak in read-cache.c: when there's cache entry collision we should free the previous one. Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- read-cache.c.orig +++ read-cache.c @@ -369,6 +369,7 @@ int add_cache_entry(struct

[patch] git: fix memory leaks in read-cache.c

this patch fixes a common and a rare memory leak in read-cache.c. Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- read-cache.c.orig +++ read-cache.c @@ -226,8 +226,11 @@ int write_sha1_file(char *buf, unsigned SHA1_Update(&c, compressed, size); SHA1_

[patch] cleanup: read_sha1_file() -> malloc_read_sha1_file()

the previous patches i sent. Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- cat-file.c.orig +++ cat-file.c @@ -14,7 +14,7 @@ int main(int argc, char **argv) if (argc != 3 || get_sha1_hex(argv[2], sha1)) usage("cat-file [-t | tagname] &quo

[patch] git: fix overflow in update-cache.c

lled in from possibly hostile objects this is playing with fire.) hey, this might be the first true security fix for GIT? ;-) Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- update-cache.c.orig +++ update-cache.c @@ -139,7 +139,7 @@ static int compare_data(struct cache_ent

[patch] git: fix memory leak in show-diff.c

this patch fixes a memory leak in show-diff.c. Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- show-diff.c.orig +++ show-diff.c @@ -53,6 +53,7 @@ static void show_diff_empty(struct cache printf("\n");

[patch] git: report parse_commit() errors in rev-tree.c

make actual use of the parse_commit() return value and print a warning, instead of silently ignoring it. Should never trigger on a valid DB. (alternatively we might use a die() in the sanity check place and could remove all the return code handling?) Ingo Signed-off-by: Ingo Molnar

[patch] git: fix rare memory leak in rev-tree.c

this patch fixes a rare memory leak in rev-tree.c. Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- rev-tree.c.orig +++ rev-tree.c @@ -73,8 +73,11 @@ static int parse_commit(unsigned char *s rev->flags |= SEEN; buffer = bufptr = read_

[patch] git: fix memory leaks in read-tree.c

this patch fixes one common, and 4 rare memory leaks in read-tree.c. Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- read-tree.c.orig +++ read-tree.c @@ -23,23 +23,27 @@ static int read_one_entry(unsigned char static int read_tree(unsigned char *sha1, const char *bas

[patch] git: cleanup in ls-tree.c

xtends the utility to include a loop) the uncleanliness doesnt develop into a real memory leak.) Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- ls-tree.c.orig +++ ls-tree.c @@ -33,6 +33,8 @@ static int list(unsigned char *sha1) type = S_ISDIR(mode)

[patch] git: fix memory leak #2 in checkout-cache.c

this patch fixes another (very rare) memory leak in checkout-cache. Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- checkout-cache.c.orig +++ checkout-cache.c @@ -74,6 +74,8 @@ static int write_entry(struct cache_entr new = read_sha1_file(ce->sha1, ty

[patch] git: fix memory leak in checkout-cache.c

this patch fixes a memory leak in checkout-cache. Ingo Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- checkout-cache.c.orig +++ checkout-cache.c @@ -48,6 +48,7 @@ static void create_directories(const cha buf[len] = 0; mkdir(buf

cache-cold repository performance

* Ingo Molnar <[EMAIL PROTECTED]> wrote: > i'd be surprised if it was twice as fast - cache-cold linear checkouts > are _seek_ limited, and it doesnt matter whether after a 1-2 msec > track-to-track disk seek the DMA engine spends another 30 microseconds > DMA-in

Re: Index/hash order

* Linus Torvalds <[EMAIL PROTECTED]> wrote: > > I've run a few tests, just to get a few numbers of the overhead > > involved. I used the last ~8,000 changesets from the BKCVS kernel > > repository. With cold cache, a checkout from cold cache takes about > > 250 seconds on my laptop. I don't ha