* Linus Torvalds torva...@linux-foundation.org wrote:
On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner t...@linutronix.de wrote:
It is spelled:
git notes add -m comment SHA1
Cool!
Don't use them for anything global.
Use them for local codeflow, but don't expect them to be
* 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?
* Linus Torvalds [EMAIL PROTECTED] wrote:
Yeah, yeah, it looks different from cvs update, but dammit, wouldn't
it be cool to just write cg-tabtab and see the command choices?
Or cg-uptab and get cg-update done for you..
add this line to your ~/.bashrc:
complete -W add addremote apply
* 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 the ocaml
* 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 changeset,
* 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 remote
* 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
as well use it to protect the DB against corruption.)
So
* 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 would be a large enough barrier
* 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 a
* 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 program failed
Pure stupidity of mine, I forgot to add
* 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 that
* 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 such command (maybe it got added meanwhile), so i'm
* 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 patch to be mistakenly matching a dangerous
* 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 able to detect
* 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 things
* 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 abbreviated, e.g. 'viro
* 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 the BK tree merge
information, but i'm not sure we want/need
* 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,
but the
* 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 of
.
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, st) 0
* 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 second thoughs about this one: active_cache
* 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 an
* 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 tree.
23 matches
Mail list logo
